diff options
| author | Chris Priest <cp368202@ohiou.edu> | 2017-09-27 13:35:33 -0600 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-09-27 19:35:35 +0000 |
| commit | a80cde2309f8e444818fdcb71ecce54cc813d4ee (patch) | |
| tree | 571837ef7e93aa00020993f6cba9e217affd95ed | |
| parent | 26b4e0b85e35fc1f18ed0ba2556551cfe6812110 (diff) | |
| download | pi-bitcoindev-a80cde2309f8e444818fdcb71ecce54cc813d4ee.tar.gz pi-bitcoindev-a80cde2309f8e444818fdcb71ecce54cc813d4ee.zip | |
Re: [bitcoin-dev] Address expiration times should be added to BIP-173
| -rw-r--r-- | cc/938a10b1316793f7275e5bd78cb3d098da8ec5 | 274 |
1 files changed, 274 insertions, 0 deletions
diff --git a/cc/938a10b1316793f7275e5bd78cb3d098da8ec5 b/cc/938a10b1316793f7275e5bd78cb3d098da8ec5 new file mode 100644 index 000000000..0d02eabd9 --- /dev/null +++ b/cc/938a10b1316793f7275e5bd78cb3d098da8ec5 @@ -0,0 +1,274 @@ +Return-Path: <nbvfour@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id BA0472C + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 27 Sep 2017 19:35:35 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-io0-f178.google.com (mail-io0-f178.google.com + [209.85.223.178]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F005217E + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 27 Sep 2017 19:35:34 +0000 (UTC) +Received: by mail-io0-f178.google.com with SMTP id k101so16643488iod.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 27 Sep 2017 12:35:34 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=mime-version:sender:in-reply-to:references:from:date:message-id + :subject:to; bh=+IFSPu9TsaZxkQNzErLg5afC72Q3UPCv5nOYuUQl35s=; + b=TbvkmpoYNG1ot+NEKB15/Knqp+MKzvv1e+0A+qV6AH24An/vsYo2lhzXddAyXlTx9P + HW2yuE2ZJKrdVxbD3kElEsE0KTWXXLV45f4cQv/vVvBooURgYPlVekV1PRqSCKdhcbRh + uIvUcDXsYoDLIRPwDLxgJ72Rv6BhlHlBN1PJGaM8SA/xo+oTRJUbCI5XOICDBATcwI3I + OuR0oo3EAikRd9e9ab2MYilGZgUlqj4bhj+2pRVQbG+2UGgXVcIfyLRr/CQj0kCOBT7u + yIsPihFlli4h2j4IYLRJDZVXe3vL0ZS0Is7bu5aT93xqV5FA1yZ2ZFP1mHTfpEZcTJci + +aLw== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:sender:in-reply-to:references:from + :date:message-id:subject:to; + bh=+IFSPu9TsaZxkQNzErLg5afC72Q3UPCv5nOYuUQl35s=; + b=dSDDor+lr6HH63XN5hSP3PxGllnXV/QlJdd3Il0BmOIEeaPBbX8B6iemYn8bhiOeK+ + e5UBffxzPgL5Ck87SdX5NxMSekukGyD2U3hKy05cYgJg3fog9q/IjAT7lJrX6/wyoCJV + LSZ272D3jmR4BSbpGU8dfV2U8OxYqi75JCiQF0Zjms5OBiHvJqX1IMXLGlp2y9DbhJiv + 6AbgPqxiuohh3Z2oqOIr3rBNgvWhFuWHHYQHImw974kmjlUU+/GjGuqFxIqRyuSGfbdd + trU2+53OxxEuNeYbopIVxtNGtawy8s7wdCa62fzZsWkBq8Cak8V6ih/jY+xoRkh1hrf7 + mbxg== +X-Gm-Message-State: AMCzsaUl61nyxUy40H3HFjdFW40cTt6GngWVf0uSZC5PaALxa0MNzNuD + 6jR2it4ObaqIhad7jAEszfZpiyMFmG11W/U0+VI= +X-Google-Smtp-Source: AOwi7QBzh4k2ywN/lGl4YP9uZ2UlUjWEiLs3ZyNjLHdvg7ggjug5sGIZ/NCUgiGt1rQS5QAALB7k5qWDIdte0YsRgZs= +X-Received: by 10.107.78.6 with SMTP id c6mr3768880iob.128.1506540934160; Wed, + 27 Sep 2017 12:35:34 -0700 (PDT) +MIME-Version: 1.0 +Sender: nbvfour@gmail.com +Received: by 10.79.138.3 with HTTP; Wed, 27 Sep 2017 12:35:33 -0700 (PDT) +In-Reply-To: <20170927160654.GA12492@savin.petertodd.org> +References: <20170927160654.GA12492@savin.petertodd.org> +From: Chris Priest <cp368202@ohiou.edu> +Date: Wed, 27 Sep 2017 13:35:33 -0600 +X-Google-Sender-Auth: TH0EI_7I703XG7te4wZlWgY7Rhw +Message-ID: <CAAcC9yvdw4Yphs-prpckaouzaU21D=kGRqK+gG9SbPr-=27z9w@mail.gmail.com> +To: Peter Todd <pete@petertodd.org>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="f403043ccee03867ad055a30e50d" +X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, + 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 20:09:53 +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 19:35:35 -0000 + +--f403043ccee03867ad055a30e50d +Content-Type: text/plain; charset="UTF-8" + +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> 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 +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> +> + + +-- +Chris Priest +786-531-5938 + +--f403043ccee03867ad055a30e50d +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"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 come= +s up and notifies the sender that they are sending to a non-fresh address t= +hat 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 no= +tice" which is just a message (signed with the private key) saying &qu= +ot;I am about to delete this address, here is my new address". When so= +meone tries to send to that address, they first consult the address expirat= +ion service, and the service will either tell them "this address is no= +t expired, proceed", or "this address has been expired, please se= +nd to this other address instead...". Basically like a 301 redirect, b= +ut for addresses. I don't think address expiration should be part of th= +e protocol.</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_q= +uote">On Wed, Sep 27, 2017 at 10:06 AM, Peter Todd via bitcoin-dev <span di= +r=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ= +et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<b= +r><blockquote class=3D"gmail_quote" style=3D"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; the= +re<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 deposit= +s.<br> +This also makes it difficult operationally to rotate private keys. I person= +ally<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 ti= +me<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 i= +s<br> +reached.<br> +<br> +Unfortunately, this proposal inevitably will raise a lot of UI and terminol= +ogy<br> +questions. Notably, the entire notion of addresses is flawed from a user po= +int<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 themse= +lves;<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 =3D 1914 years<br> +2) Month resolution - 2^16 months =3D 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 maki= +ng<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 a= +t<br> +least hour-level ensures we don't have any year 2038 problems.<br> +<br> +Thoughts?<br> +<span class=3D"HOEnZb"><font color=3D"#888888"><br> +--<br> +<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http= +s://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org"= + rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br> +</font></span><br>______________________________<wbr>_________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= +<wbr>linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org= +/mailman/listinfo/bitcoin-<wbr>dev</a><br> +<br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div cla= +ss=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">= +Chris Priest<div>786-531-5938</div></div></div> +</div> + +--f403043ccee03867ad055a30e50d-- + |