Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BA0472C for ; 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 ; Wed, 27 Sep 2017 19:35:34 +0000 (UTC) Received: by mail-io0-f178.google.com with SMTP id k101so16643488iod.0 for ; 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 Date: Wed, 27 Sep 2017 13:35:33 -0600 X-Google-Sender-Auth: TH0EI_7I703XG7te4wZlWgY7Rhw Message-ID: To: Peter Todd , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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.

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.

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<= br> sending funds to addresses whose private keys have been lost or stolen; the= re
are multiple examples of exchanges getting hacked, with users continuing to=
lose funds well after the actual hack has occured due to continuing deposit= s.
This also makes it difficult operationally to rotate private keys. I person= ally
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 ti= me
to the new BIP173 address format. Wallets would be expected to consider
addresses as invalid as a destination for funds after the expiration time i= s
reached.

Unfortunately, this proposal inevitably will raise a lot of UI and terminol= ogy
questions. Notably, the entire notion of addresses is flawed from a user po= int
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<= br> 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 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 maki= ng
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
least hour-level ensures we don't have any year 2038 problems.

Thoughts?

--
http= s://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--