938a10b1316793f7275e5bd78cb3d098da8ec5
1 Return-Path: <nbvfour@gmail.com> 2 Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org 3 [172.17.192.35]) 4 by mail.linuxfoundation.org (Postfix) with ESMTPS id BA0472C 5 for <bitcoin-dev@lists.linuxfoundation.org>; 6 Wed, 27 Sep 2017 19:35:35 +0000 (UTC) 7 X-Greylist: whitelisted by SQLgrey-1.7.6 8 Received: from mail-io0-f178.google.com (mail-io0-f178.google.com 9 [209.85.223.178]) 10 by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F005217E 11 for <bitcoin-dev@lists.linuxfoundation.org>; 12 Wed, 27 Sep 2017 19:35:34 +0000 (UTC) 13 Received: by mail-io0-f178.google.com with SMTP id k101so16643488iod.0 14 for <bitcoin-dev@lists.linuxfoundation.org>; 15 Wed, 27 Sep 2017 12:35:34 -0700 (PDT) 16 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; 17 h=mime-version:sender:in-reply-to:references:from:date:message-id 18 :subject:to; bh=+IFSPu9TsaZxkQNzErLg5afC72Q3UPCv5nOYuUQl35s=; 19 b=TbvkmpoYNG1ot+NEKB15/Knqp+MKzvv1e+0A+qV6AH24An/vsYo2lhzXddAyXlTx9P 20 HW2yuE2ZJKrdVxbD3kElEsE0KTWXXLV45f4cQv/vVvBooURgYPlVekV1PRqSCKdhcbRh 21 uIvUcDXsYoDLIRPwDLxgJ72Rv6BhlHlBN1PJGaM8SA/xo+oTRJUbCI5XOICDBATcwI3I 22 OuR0oo3EAikRd9e9ab2MYilGZgUlqj4bhj+2pRVQbG+2UGgXVcIfyLRr/CQj0kCOBT7u 23 yIsPihFlli4h2j4IYLRJDZVXe3vL0ZS0Is7bu5aT93xqV5FA1yZ2ZFP1mHTfpEZcTJci 24 +aLw== 25 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 26 d=1e100.net; s=20161025; 27 h=x-gm-message-state:mime-version:sender:in-reply-to:references:from 28 :date:message-id:subject:to; 29 bh=+IFSPu9TsaZxkQNzErLg5afC72Q3UPCv5nOYuUQl35s=; 30 b=dSDDor+lr6HH63XN5hSP3PxGllnXV/QlJdd3Il0BmOIEeaPBbX8B6iemYn8bhiOeK+ 31 e5UBffxzPgL5Ck87SdX5NxMSekukGyD2U3hKy05cYgJg3fog9q/IjAT7lJrX6/wyoCJV 32 LSZ272D3jmR4BSbpGU8dfV2U8OxYqi75JCiQF0Zjms5OBiHvJqX1IMXLGlp2y9DbhJiv 33 6AbgPqxiuohh3Z2oqOIr3rBNgvWhFuWHHYQHImw974kmjlUU+/GjGuqFxIqRyuSGfbdd 34 trU2+53OxxEuNeYbopIVxtNGtawy8s7wdCa62fzZsWkBq8Cak8V6ih/jY+xoRkh1hrf7 35 mbxg== 36 X-Gm-Message-State: AMCzsaUl61nyxUy40H3HFjdFW40cTt6GngWVf0uSZC5PaALxa0MNzNuD 37 6jR2it4ObaqIhad7jAEszfZpiyMFmG11W/U0+VI= 38 X-Google-Smtp-Source: AOwi7QBzh4k2ywN/lGl4YP9uZ2UlUjWEiLs3ZyNjLHdvg7ggjug5sGIZ/NCUgiGt1rQS5QAALB7k5qWDIdte0YsRgZs= 39 X-Received: by 10.107.78.6 with SMTP id c6mr3768880iob.128.1506540934160; Wed, 40 27 Sep 2017 12:35:34 -0700 (PDT) 41 MIME-Version: 1.0 42 Sender: nbvfour@gmail.com 43 Received: by 10.79.138.3 with HTTP; Wed, 27 Sep 2017 12:35:33 -0700 (PDT) 44 In-Reply-To: <20170927160654.GA12492@savin.petertodd.org> 45 References: <20170927160654.GA12492@savin.petertodd.org> 46 From: Chris Priest <cp368202@ohiou.edu> 47 Date: Wed, 27 Sep 2017 13:35:33 -0600 48 X-Google-Sender-Auth: TH0EI_7I703XG7te4wZlWgY7Rhw 49 Message-ID: <CAAcC9yvdw4Yphs-prpckaouzaU21D=kGRqK+gG9SbPr-=27z9w@mail.gmail.com> 50 To: Peter Todd <pete@petertodd.org>, 51 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> 52 Content-Type: multipart/alternative; boundary="f403043ccee03867ad055a30e50d" 53 X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, 54 FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM 55 autolearn=disabled version=3.3.1 56 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on 57 smtp1.linux-foundation.org 58 X-Mailman-Approved-At: Wed, 27 Sep 2017 20:09:53 +0000 59 Subject: Re: [bitcoin-dev] Address expiration times should be added to 60 BIP-173 61 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org 62 X-Mailman-Version: 2.1.12 63 Precedence: list 64 List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> 65 List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 66 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> 67 List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> 68 List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> 69 List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> 70 List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 71 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> 72 X-List-Received-Date: Wed, 27 Sep 2017 19:35:35 -0000 73 74 --f403043ccee03867ad055a30e50d 75 Content-Type: text/plain; charset="UTF-8" 76 77 A better solution is to just have the sending wallet check to see if the 78 address you are about to send to has been used before. If it's a fresh 79 address, it sends it through without any popup alert. If the address has 80 history going back a certain amount of time, then a popup comes up and 81 notifies the sender that they are sending to a non-fresh address that may 82 no longer be controlled by the receiver anymore. 83 84 Also, an even better idea is to set up an "address expiration service". 85 When you delete a wallet, you first send off an "expiration notice" which 86 is just a message (signed with the private key) saying "I am about to 87 delete this address, here is my new address". When someone tries to send to 88 that address, they first consult the address expiration service, and the 89 service will either tell them "this address is not expired, proceed", or 90 "this address has been expired, please send to this other address 91 instead...". Basically like a 301 redirect, but for addresses. I don't 92 think address expiration should be part of the protocol. 93 94 On Wed, Sep 27, 2017 at 10:06 AM, Peter Todd via bitcoin-dev < 95 bitcoin-dev@lists.linuxfoundation.org> wrote: 96 97 > Re-use of old addresses is a major problem, not only for privacy, but also 98 > operationally: services like exchanges frequently have problems with users 99 > sending funds to addresses whose private keys have been lost or stolen; 100 > there 101 > are multiple examples of exchanges getting hacked, with users continuing to 102 > lose funds well after the actual hack has occured due to continuing 103 > deposits. 104 > This also makes it difficult operationally to rotate private keys. I 105 > personally 106 > have even lost funds in the past due to people sending me BTC to addresses 107 > that 108 > I gave them long ago for different reasons, rather than asking me for fresh 109 > one. 110 > 111 > To help combat this problem, I suggest that we add a UI-level expiration 112 > time 113 > to the new BIP173 address format. Wallets would be expected to consider 114 > addresses as invalid as a destination for funds after the expiration time 115 > is 116 > reached. 117 > 118 > Unfortunately, this proposal inevitably will raise a lot of UI and 119 > terminology 120 > questions. Notably, the entire notion of addresses is flawed from a user 121 > point 122 > of view: their experience with them should be more like "payment codes", 123 > with a 124 > code being valid for payment for a short period of time; wallets should 125 > not be 126 > displaying addresses as actually associated with specific funds. I suspect 127 > we'll see users thinking that an expired address risks the funds 128 > themselves; 129 > some thought needs to be put into terminology. 130 > 131 > Being just an expiration time, seconds-level resolution is unnecessary, and 132 > may give the wrong impression. I'd suggest either: 133 > 134 > 1) Hour resolution - 2^24 hours = 1914 years 135 > 2) Month resolution - 2^16 months = 5458 years 136 > 137 > Both options have the advantage of working well at the UI level regardless 138 > of 139 > timezone: the former is sufficiently short that UI's can simply display an 140 > "exact" time (though note different leap second interpretations), while the 141 > latter is long enough that rounding off to the nearest day in the local 142 > timezone is fine. 143 > 144 > Supporting hour-level (or just seconds) precision has the advantage of 145 > making 146 > it easy for services like exchanges to use addresses with relatively short 147 > validity periods, to reduce the risks of losses after a hack. Also, using 148 > at 149 > least hour-level ensures we don't have any year 2038 problems. 150 > 151 > Thoughts? 152 > 153 > -- 154 > https://petertodd.org 'peter'[:-1]@petertodd.org 155 > 156 > _______________________________________________ 157 > bitcoin-dev mailing list 158 > bitcoin-dev@lists.linuxfoundation.org 159 > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 160 > 161 > 162 163 164 -- 165 Chris Priest 166 786-531-5938 167 168 --f403043ccee03867ad055a30e50d 169 Content-Type: text/html; charset="UTF-8" 170 Content-Transfer-Encoding: quoted-printable 171 172 <div dir=3D"ltr">A better solution is to just have the sending wallet check= 173 to see if the address you are about to send to has been used before. If it= 174 's a fresh address, it sends it through without any popup alert. If the= 175 address has history going back a certain amount of time, then a popup come= 176 s up and notifies the sender that they are sending to a non-fresh address t= 177 hat may no longer be controlled by the receiver anymore.<div><br></div><div= 178 >Also, an even better idea is to set up an "address expiration service= 179 ". When you delete a wallet, you first send off an "expiration no= 180 tice" which is just a message (signed with the private key) saying &qu= 181 ot;I am about to delete this address, here is my new address". When so= 182 meone tries to send to that address, they first consult the address expirat= 183 ion service, and the service will either tell them "this address is no= 184 t expired, proceed", or "this address has been expired, please se= 185 nd to this other address instead...". Basically like a 301 redirect, b= 186 ut for addresses. I don't think address expiration should be part of th= 187 e protocol.</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_q= 188 uote">On Wed, Sep 27, 2017 at 10:06 AM, Peter Todd via bitcoin-dev <span di= 189 r=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ= 190 et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<b= 191 r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:= 192 1px #ccc solid;padding-left:1ex">Re-use of old addresses is a major problem= 193 , not only for privacy, but also<br> 194 operationally: services like exchanges frequently have problems with users<= 195 br> 196 sending funds to addresses whose private keys have been lost or stolen; the= 197 re<br> 198 are multiple examples of exchanges getting hacked, with users continuing to= 199 <br> 200 lose funds well after the actual hack has occured due to continuing deposit= 201 s.<br> 202 This also makes it difficult operationally to rotate private keys. I person= 203 ally<br> 204 have even lost funds in the past due to people sending me BTC to addresses = 205 that<br> 206 I gave them long ago for different reasons, rather than asking me for fresh= 207 <br> 208 one.<br> 209 <br> 210 To help combat this problem, I suggest that we add a UI-level expiration ti= 211 me<br> 212 to the new BIP173 address format. Wallets would be expected to consider<br> 213 addresses as invalid as a destination for funds after the expiration time i= 214 s<br> 215 reached.<br> 216 <br> 217 Unfortunately, this proposal inevitably will raise a lot of UI and terminol= 218 ogy<br> 219 questions. Notably, the entire notion of addresses is flawed from a user po= 220 int<br> 221 of view: their experience with them should be more like "payment codes= 222 ", with a<br> 223 code being valid for payment for a short period of time; wallets should not= 224 be<br> 225 displaying addresses as actually associated with specific funds. I suspect<= 226 br> 227 we'll see users thinking that an expired address risks the funds themse= 228 lves;<br> 229 some thought needs to be put into terminology.<br> 230 <br> 231 Being just an expiration time, seconds-level resolution is unnecessary, and= 232 <br> 233 may give the wrong impression. I'd suggest either:<br> 234 <br> 235 1) Hour resolution - 2^24 hours =3D 1914 years<br> 236 2) Month resolution - 2^16 months =3D 5458 years<br> 237 <br> 238 Both options have the advantage of working well at the UI level regardless = 239 of<br> 240 timezone: the former is sufficiently short that UI's can simply display= 241 an<br> 242 "exact" time (though note different leap second interpretations),= 243 while the<br> 244 latter is long enough that rounding off to the nearest day in the local<br> 245 timezone is fine.<br> 246 <br> 247 Supporting hour-level (or just seconds) precision has the advantage of maki= 248 ng<br> 249 it easy for services like exchanges to use addresses with relatively short<= 250 br> 251 validity periods, to reduce the risks of losses after a hack. Also, using a= 252 t<br> 253 least hour-level ensures we don't have any year 2038 problems.<br> 254 <br> 255 Thoughts?<br> 256 <span class=3D"HOEnZb"><font color=3D"#888888"><br> 257 --<br> 258 <a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http= 259 s://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org"= 260 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br> 261 </font></span><br>______________________________<wbr>_________________<br> 262 bitcoin-dev mailing list<br> 263 <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= 264 <wbr>linuxfoundation.org</a><br> 265 <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = 266 rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org= 267 /mailman/listinfo/bitcoin-<wbr>dev</a><br> 268 <br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div cla= 269 ss=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">= 270 Chris Priest<div>786-531-5938</div></div></div> 271 </div> 272 273 --f403043ccee03867ad055a30e50d-- 274