Re: [bitcoin-dev] Address expiration times should be added to BIP-173

[CryptAxe <cryptaxe@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5918 bytes --]

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
> <mailto: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
>     <http://petertodd.org>
>
>     _______________________________________________
>     bitcoin-dev mailing list
>     bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>     <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


[-- Attachment #2: Type: text/html, Size: 10739 bytes --]