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

From: Mark Friedenbach <mark@friedenbach•org>
To: Peter Todd <pete@petertodd•org>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Address expiration times should be added to BIP-173
Date: Wed, 27 Sep 2017 12:03:44 -0700	[thread overview]
Message-ID: <31968FFC-11BC-4331-B602-70B1F74AEEFC@friedenbach.org> (raw)
In-Reply-To: <20170927160654.GA12492@savin.petertodd.org>

While there is a lot that I would like to comment on, for the moment I will just mention that you should consider using the 17 bit relative time format used in CSV as an offset from the birthdate of the address, a field all addresses should also have.

This would also mean that addresses cannot last more than a year without user override, which might actually be a plus, but you could also extend the field by a few bits too if that was deemed not acceptable. An address should not be considered valid longer than anticipated lifetime of the underlying cryptosystem in any case, so every address should have an expiry.

> On Sep 27, 2017, at 9: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