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
|
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 A8D109C0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Sep 2017 18:23:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f49.google.com (mail-pg0-f49.google.com [74.125.83.49])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2FFFA367
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Sep 2017 18:23:32 +0000 (UTC)
Received: by mail-pg0-f49.google.com with SMTP id v23so8224452pgc.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Sep 2017 11:23:32 -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=BWgioKGMxcDYfqpf0MBVh3FJFviP4zrsMkmOXhqIc4U=;
b=rxozI3Hvr4CAdnIAl97DAVTdqeXdfJDnTZqK9HJJwps1MgfiuiXNM8ZUsZfwRLxD26
AYp/R5kD6PcKc4KiIZ+5tDh0443QbiUn5oHZ1Rilfn5TIr7FwoWW3KX0hGR+cW/ZtBXF
YIqdxUIswXA2+2rFvUVNfWETbpSFz/h4Z+U5R0HVT0GzauD2WYfBW1tRt6Zcw5UWPYHY
avAxSqtMm/EhP5SAtGwnIG7jnbaIgW4VfPQjJUCbGMaQ6LcRG5lK2U1Xvnl8xn0rSH7E
pYISz6maSB5fmnsCRBHPFcXivSQWkTiOHuOfv9PwpOAhslmX65hogafwKTHKPa/N2O+3
P64Q==
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=BWgioKGMxcDYfqpf0MBVh3FJFviP4zrsMkmOXhqIc4U=;
b=sLzaCmmKOL4a7E2FMZ+szwix2w1/GrEKvqere8lG5z9nxhl3K90jQjpfO6niDZTZHm
h99KvMRF2iLWznnHUg7YbX1lbb+T3Gc7oDQyN06ZNQ8HVh5GXFa+fzB0fS6jPFkq4R27
Q6WClCkCV5qAZLEZT+IiLzjzkZ7NDjNSf0nwLR3yEO+GhOXidvhirBavqNLa9jKO6DPG
pInFCZ2n72vXfkjkfGymD3Sw6/FJhgP2OTzLucMpRR4PX7ySIDUYoIFA4aRbfv/Rf25M
KR+o5vIhXwCnKHF86UkgU5yYDcASLMMAjQILIWFez6rcfL0rZlxv6Kg0HV7yDyRkzQmY
/0SA==
X-Gm-Message-State: AHPjjUgUizJfmp7LloiaBqI7e5NopUehtHTESqtpUmlFgQOvsd4EypJr
9r4Hswdtf7MYvx6xwQizOMRnNHSp
X-Google-Smtp-Source: AOwi7QDZ65HAo5dh4Nnva3g4xBTaqwpQdHN9X99H1tdrA1Olipo0o97BtJjxuMYXtreCQuPxFp0XFQ==
X-Received: by 10.84.132.129 with SMTP id e1mr1949598ple.444.1506536611227;
Wed, 27 Sep 2017 11:23:31 -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
p85sm21677744pfj.47.2017.09.27.11.23.29
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 27 Sep 2017 11:23:30 -0700 (PDT)
To: bitcoin-dev@lists.linuxfoundation.org
References: <20170927160654.GA12492@savin.petertodd.org>
From: CryptAxe <cryptaxe@gmail.com>
Message-ID: <f7ee0056-5fd3-e72a-9f9a-776c0f877ab1@gmail.com>
Date: Wed, 27 Sep 2017 11:15:20 -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: <20170927160654.GA12492@savin.petertodd.org>
Content-Type: multipart/alternative;
boundary="------------D680DB84B4B46B9BB11EB50A"
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: Wed, 27 Sep 2017 18:25:44 +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 18:23:32 -0000
This is a multi-part message in MIME format.
--------------D680DB84B4B46B9BB11EB50A
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
I think we need something like this. Hour resolution seems like the
correct choice to me.
Please someone steal whatever code you can from this PR when
implementing the UI for BIP173 expiration:
https://github.com/bitcoin/bitcoin/pull/9722
I have a rebased version as well if anyone wants it.
On 09/27/2017 09:06 AM, Peter Todd via bitcoin-dev wrote:
> Re-use of old addresses is a major problem, not only for privacy, but a=
lso
> operationally: services like exchanges frequently have problems with us=
ers
> sending funds to addresses whose private keys have been lost or stolen;=
there
> are multiple examples of exchanges getting hacked, with users continuin=
g to
> lose funds well after the actual hack has occured due to continuing dep=
osits.
> This also makes it difficult operationally to rotate private keys. I pe=
rsonally
> have even lost funds in the past due to people sending me BTC to addres=
ses that
> I gave them long ago for different reasons, rather than asking me for f=
resh
> one.
>
> To help combat this problem, I suggest that we add a UI-level expiratio=
n time
> to the new BIP173 address format. Wallets would be expected to consider=
> addresses as invalid as a destination for funds after the expiration ti=
me is
> reached.
>
> Unfortunately, this proposal inevitably will raise a lot of UI and term=
inology
> questions. Notably, the entire notion of addresses is flawed from a use=
r 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 susp=
ect
> we'll see users thinking that an expired address risks the funds themse=
lves;
> 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 =3D 1914 years
> 2) Month resolution - 2^16 months =3D 5458 years
>
> Both options have the advantage of working well at the UI level regardl=
ess 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 sh=
ort
> validity periods, to reduce the risks of losses after a hack. Also, usi=
ng at
> least hour-level ensures we don't have any year 2038 problems.
>
> Thoughts?
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--------------D680DB84B4B46B9BB11EB50A
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 think we need something like this. Hour resolution seems like
the correct choice to me.</p>
<p>Please someone steal whatever code you can from this PR when
implementing the UI for BIP173 expiration:</p>
<p><a class="moz-txt-link-freetext" href="https://github.com/bitcoin/bitcoin/pull/9722">https://github.com/bitcoin/bitcoin/pull/9722</a> <br>
</p>
<p>I have a rebased version as well if anyone wants it.<br>
</p>
<br>
<div class="moz-cite-prefix">On 09/27/2017 09:06 AM, Peter Todd via
bitcoin-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:20170927160654.GA12492@savin.petertodd.org">
<pre wrap="">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?
</pre>
<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>
--------------D680DB84B4B46B9BB11EB50A--
|
