1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
|
Return-Path: <cryptaxe@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 76DA0B12
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Sep 2017 20:28:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f181.google.com (mail-pf0-f181.google.com
[209.85.192.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8A70B43A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Sep 2017 20:27:59 +0000 (UTC)
Received: by mail-pf0-f181.google.com with SMTP id y29so7822060pff.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Sep 2017 13:27:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to:content-language;
bh=+MWJh6FetZOXC5Ye2e0BLsriyef5TbFuroUiswGaFac=;
b=dWoSnehex6ANGh1SdrFLALNEdR9RLfJYt2yL951ZEMhJTQSxcsF8y/+2ocYTCAKa5O
GdvpAYiffczGIUmQmvehoBp3/eXDgm1lIeu1RRgrwRl5gs7BWkAk6dQuG65Gl/oVGPv8
/iqxQminKQG4ChZ1DNyywkjf75DtLcnBcsXq7R3cHqmSDzvgecsA6R/pcouRaFDTYvXZ
6DNqU8cYIU0FeGQB4CYmBSGIAEWbYItrRSzThwpgsjtDkEX6JU9NbrgCbWxePxE5Rq3H
dL3Z9QD630w+cZmWd1xtiRfbMoIPaNUdjXviM8+ooU+m6Wdh1ibT8L/k2JSMUIjrKyrH
szVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-language;
bh=+MWJh6FetZOXC5Ye2e0BLsriyef5TbFuroUiswGaFac=;
b=G/s+EyxZ+FF2y+iRYMuchj+O3m2xSBzZEYznoLde0KLhxMCo6vIBOM/I3UMHnjpBMS
xFp7DxzWyco8zmSvKtRJO/4owllYeGRISRZz6i4L+SqCRmHrO/l3UaUYy8yBDZ6nS+hQ
Og3rNH6F5J3M7pgyAwg5MrKM5P1Uycmq7J8147BUvMHJNMk2D5fMtmrTQu1TO8H5Nk39
fWC1NP4osUVVnJJOMRJJ4OT2Q6sS4j9yoDaBa5SGFit7DVIinp4bQdzPEoGOASxLqlvC
wxnyjw7V0zHaxJIxwJhD8RI0Nm8EaIw0zqkGlNpTOUINh3qPAg6vev1X20e86oH0kxj1
4uDw==
X-Gm-Message-State: AHPjjUhqJPzE1uEHhUahPxbaxvy973MxHD2QYrtcRgErucgM8GCYahEi
hZqgjF9P4gfNYUemxlm/tbDd1/gp
X-Google-Smtp-Source: AOwi7QA1pTpOhJn03SWcPgH+AtWByHMIqz3FL6+klnm/9HPUmzjgkBSX++xaLbleZXyIEiFsvkk5bQ==
X-Received: by 10.98.61.142 with SMTP id x14mr2282789pfj.258.1506544078763;
Wed, 27 Sep 2017 13:27:58 -0700 (PDT)
Received: from [192.168.1.3] (c-73-240-125-172.hsd1.or.comcast.net.
[73.240.125.172]) by smtp.gmail.com with ESMTPSA id
g68sm21217189pfk.136.2017.09.27.13.27.57
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 27 Sep 2017 13:27:57 -0700 (PDT)
To: bitcoin-dev@lists.linuxfoundation.org
References: <20170927160654.GA12492@savin.petertodd.org>
<CAAcC9yvdw4Yphs-prpckaouzaU21D=kGRqK+gG9SbPr-=27z9w@mail.gmail.com>
<CY4PR12MB139977628660D809B611D8ACC8780@CY4PR12MB1399.namprd12.prod.outlook.com>
From: CryptAxe <cryptaxe@gmail.com>
Message-ID: <12c4295c-9546-ba0a-5bd4-4e7e9282daf1@gmail.com>
Date: Wed, 27 Sep 2017 13:19:48 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CY4PR12MB139977628660D809B611D8ACC8780@CY4PR12MB1399.namprd12.prod.outlook.com>
Content-Type: multipart/alternative;
boundary="------------2928BE756E3B160221CA471F"
Content-Language: en-US
X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 28 Sep 2017 12:51:39 +0000
Subject: Re: [bitcoin-dev] Address expiration times should be added to
BIP-173
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Sep 2017 20:28:00 -0000
This is a multi-part message in MIME format.
--------------2928BE756E3B160221CA471F
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
I do agree with you to a degree, but address reuse is actually not even
supposed to work (it is a bug). Peter Todd is suggesting only to make
expiration a part of a new address format, and we could have a GUI
warning (but no protocol change) for the existing formats. What do you
think about that?
On 09/27/2017 01:23 PM, Nick Pudar via bitcoin-dev wrote:
>
> As a long term silent reader of this list, I felt compelled to comment
> on this address expiration topic. I don't believe that address
> expiration should be part of the protocol. I think instead that the
> "sending" feature should by default offer guidance to request a fresh
> address from the recipient. Also allow the receiver of funds to be
> able to generate an "invoice" that the sender acts on.
>
>
> I also think that re-directs are fraught with privacy issues. At the
> end of the day, the ultimate burden is on the sender (with much self
> interest from the receiver) that the correct address is being used.
>
>
>
> ------------------------------------------------------------------------
> *From:* bitcoin-dev-bounces@lists.linuxfoundation.org
> <bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf of Chris
> Priest via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> *Sent:* Wednesday, September 27, 2017 3:35 PM
> *To:* Peter Todd; Bitcoin Protocol Discussion
> *Subject:* Re: [bitcoin-dev] Address expiration times should be added
> to BIP-173
>
> A better solution is to just have the sending wallet check to see if
> the address you are about to send to has been used before. If it's a
> fresh address, it sends it through without any popup alert. If the
> address has history going back a certain amount of time, then a popup
> comes up and notifies the sender that they are sending to a non-fresh
> address that may no longer be controlled by the receiver anymore.
>
> Also, an even better idea is to set up an "address expiration
> service". When you delete a wallet, you first send off an "expiration
> notice" which is just a message (signed with the private key) saying
> "I am about to delete this address, here is my new address". When
> someone tries to send to that address, they first consult the address
> expiration service, and the service will either tell them "this
> address is not expired, proceed", or "this address has been expired,
> please send to this other address instead...". Basically like a 301
> redirect, but for addresses. I don't think address expiration should
> be part of the protocol.
>
> On Wed, Sep 27, 2017 at 10:06 AM, Peter Todd via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> Re-use of old addresses is a major problem, not only for privacy,
> but also
> operationally: services like exchanges frequently have problems
> with users
> sending funds to addresses whose private keys have been lost or
> stolen; there
> are multiple examples of exchanges getting hacked, with users
> continuing to
> lose funds well after the actual hack has occured due to
> continuing deposits.
> This also makes it difficult operationally to rotate private keys.
> I personally
> have even lost funds in the past due to people sending me BTC to
> addresses that
> I gave them long ago for different reasons, rather than asking me
> for fresh
> one.
>
> To help combat this problem, I suggest that we add a UI-level
> expiration time
> to the new BIP173 address format. Wallets would be expected to
> consider
> addresses as invalid as a destination for funds after the
> expiration time is
> reached.
>
> Unfortunately, this proposal inevitably will raise a lot of UI and
> terminology
> questions. Notably, the entire notion of addresses is flawed from
> a user point
> of view: their experience with them should be more like "payment
> codes", with a
> code being valid for payment for a short period of time; wallets
> should not be
> displaying addresses as actually associated with specific funds. I
> suspect
> we'll see users thinking that an expired address risks the funds
> themselves;
> some thought needs to be put into terminology.
>
> Being just an expiration time, seconds-level resolution is
> unnecessary, and
> may give the wrong impression. I'd suggest either:
>
> 1) Hour resolution - 2^24 hours = 1914 years
> 2) Month resolution - 2^16 months = 5458 years
>
> Both options have the advantage of working well at the UI level
> regardless of
> timezone: the former is sufficiently short that UI's can simply
> display an
> "exact" time (though note different leap second interpretations),
> while the
> latter is long enough that rounding off to the nearest day in the
> local
> timezone is fine.
>
> Supporting hour-level (or just seconds) precision has the
> advantage of making
> it easy for services like exchanges to use addresses with
> relatively short
> validity periods, to reduce the risks of losses after a hack.
> Also, using at
> least hour-level ensures we don't have any year 2038 problems.
>
> Thoughts?
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> <http://petertodd.org>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
>
>
> --
> Chris Priest
> 786-531-5938
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--------------2928BE756E3B160221CA471F
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>I do agree with you to a degree, but address reuse is actually
not even supposed to work (it is a bug). Peter Todd is suggesting
only to make expiration a part of a new address format, and we
could have a GUI warning (but no protocol change) for the existing
formats. What do you think about that?<br>
</p>
<br>
<div class="moz-cite-prefix">On 09/27/2017 01:23 PM, Nick Pudar via
bitcoin-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CY4PR12MB139977628660D809B611D8ACC8780@CY4PR12MB1399.namprd12.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper" style="font-size: 12pt; color:
rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif,
EmojiFont, "Apple Color Emoji", "Segoe UI
Emoji", NotoColorEmoji, "Segoe UI Symbol",
"Android Emoji", EmojiSymbols;" dir="ltr">
<p>As a long term silent reader of this list, I felt compelled
to comment on this address expiration topic. I don't believe
that address expiration should be part of the protocol. I
think instead that the "sending" feature should by default
offer guidance to request a fresh address from the recipient.
Also allow the receiver of funds to be able to generate an
"invoice" that the sender acts on.<br>
</p>
<p><br>
</p>
<p>I also think that re-directs are fraught with privacy
issues. At the end of the day, the ultimate burden is on the
sender (with much self interest from the receiver) that the
correct address is being used.</p>
<br>
<br>
<div style="color: rgb(0, 0, 0);">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
color="#000000" face="Calibri, sans-serif"><b>From:</b>
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev-bounces@lists.linuxfoundation.org">bitcoin-dev-bounces@lists.linuxfoundation.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:bitcoin-dev-bounces@lists.linuxfoundation.org"><bitcoin-dev-bounces@lists.linuxfoundation.org></a> on
behalf of Chris Priest via bitcoin-dev
<a class="moz-txt-link-rfc2396E" href="mailto:bitcoin-dev@lists.linuxfoundation.org"><bitcoin-dev@lists.linuxfoundation.org></a><br>
<b>Sent:</b> Wednesday, September 27, 2017 3:35 PM<br>
<b>To:</b> Peter Todd; Bitcoin Protocol Discussion<br>
<b>Subject:</b> Re: [bitcoin-dev] Address expiration times
should be added to BIP-173</font>
<div> </div>
</div>
<div>
<div dir="ltr">A better solution is to just have the sending
wallet check to see if the address you are about to send
to has been used before. If it's a fresh address, it sends
it through without any popup alert. If the address has
history going back a certain amount of time, then a popup
comes up and notifies the sender that they are sending to
a non-fresh address that may no longer be controlled by
the receiver anymore.
<div><br>
</div>
<div>Also, an even better idea is to set up an "address
expiration service". When you delete a wallet, you first
send off an "expiration notice" which is just a message
(signed with the private key) saying "I am about to
delete this address, here is my new address". When
someone tries to send to that address, they first
consult the address expiration service, and the service
will either tell them "this address is not expired,
proceed", or "this address has been expired, please send
to this other address instead...". Basically like a 301
redirect, but for addresses. I don't think address
expiration should be part of the protocol.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Sep 27, 2017 at 10:06 AM,
Peter Todd via bitcoin-dev
<span dir="ltr"><<a
href="mailto:bitcoin-dev@lists.linuxfoundation.org"
target="_blank" moz-do-not-send="true">bitcoin-dev@lists.linuxfoundation.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex; border-left:1px #ccc solid; padding-left:1ex">
Re-use of old addresses is a major problem, not only
for privacy, but also<br>
operationally: services like exchanges frequently have
problems with users<br>
sending funds to addresses whose private keys have
been lost or stolen; there<br>
are multiple examples of exchanges getting hacked,
with users continuing to<br>
lose funds well after the actual hack has occured due
to continuing deposits.<br>
This also makes it difficult operationally to rotate
private keys. I personally<br>
have even lost funds in the past due to people sending
me BTC to addresses that<br>
I gave them long ago for different reasons, rather
than asking me for fresh<br>
one.<br>
<br>
To help combat this problem, I suggest that we add a
UI-level expiration time<br>
to the new BIP173 address format. Wallets would be
expected to consider<br>
addresses as invalid as a destination for funds after
the expiration time is<br>
reached.<br>
<br>
Unfortunately, this proposal inevitably will raise a
lot of UI and terminology<br>
questions. Notably, the entire notion of addresses is
flawed from a user point<br>
of view: their experience with them should be more
like "payment codes", with a<br>
code being valid for payment for a short period of
time; wallets should not be<br>
displaying addresses as actually associated with
specific funds. I suspect<br>
we'll see users thinking that an expired address risks
the funds themselves;<br>
some thought needs to be put into terminology.<br>
<br>
Being just an expiration time, seconds-level
resolution is unnecessary, and<br>
may give the wrong impression. I'd suggest either:<br>
<br>
1) Hour resolution - 2^24 hours = 1914 years<br>
2) Month resolution - 2^16 months = 5458 years<br>
<br>
Both options have the advantage of working well at the
UI level regardless of<br>
timezone: the former is sufficiently short that UI's
can simply display an<br>
"exact" time (though note different leap second
interpretations), while the<br>
latter is long enough that rounding off to the nearest
day in the local<br>
timezone is fine.<br>
<br>
Supporting hour-level (or just seconds) precision has
the advantage of making<br>
it easy for services like exchanges to use addresses
with relatively short<br>
validity periods, to reduce the risks of losses after
a hack. Also, using at<br>
least hour-level ensures we don't have any year 2038
problems.<br>
<br>
Thoughts?<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
<a href="https://petertodd.org" rel="noreferrer"
target="_blank" moz-do-not-send="true">https://petertodd.org</a>
'peter'[:-1]@<a href="http://petertodd.org"
rel="noreferrer" target="_blank"
moz-do-not-send="true">petertodd.org</a><br>
</font></span><br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org"
moz-do-not-send="true">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<a
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature">
<div dir="ltr">Chris Priest
<div>786-531-5938</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------2928BE756E3B160221CA471F--
|
