Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 76DA0B12 for ; 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 ; Wed, 27 Sep 2017 20:27:59 +0000 (UTC) Received: by mail-pf0-f181.google.com with SMTP id y29so7822060pff.0 for ; 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 (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> From: CryptAxe 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > on behalf of Chris > Priest via bitcoin-dev > *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 > > 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 > > > _______________________________________________ > 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

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> 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


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--------------2928BE756E3B160221CA471F--