From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Tue, 15 Jul 2014 14:48:55 +0000
User-Agent: KMail/1.13.7 (Linux/3.15.1-gentoo; KDE/4.12.5; x86_64; ; )
References: <CAJHLa0M7iEUQnJ9M4A3ev3EQqxUVQG85qucRamvMb0n-CztOFA@mail.gmail.com>
In-Reply-To: <CAJHLa0M7iEUQnJ9M4A3ev3EQqxUVQG85qucRamvMb0n-CztOFA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201407151448.57223.luke@dashjr.org>
Subject: Re: [Bitcoin-development] Bitcoin address TTL & key expiration?
Precedence: list

On Tuesday, July 15, 2014 8:00:41 AM Jeff Garzik wrote:
> Proxying another's idea, from CoinSummit.
> 
> The request:   It would be useful to limit the lifetime of a bitcoin
> address.  Intentionally prevent (somehow) bitcoins being sent to a
> pubkey/pkh after the key expires.
> 
> You could append "don't ["permit"|confirm] after X [time|block]"  to
> the address I suppose.  The metadata would not be digitally signed,
> but it would be hash-sealed.  As "address" is a client-side notion,
> wallet clients would be the ones enforcing such a rule.

I agree this would be useful for the "permit" case, but not the "confirm" case 
- it's important that transactions valid in block X also be equally valid in 
block X+1 to avoid reorg issues.

> Bitcoin protocol of course knows about keys, and key expiration is a
> well known and useful concept in public key cryptography.  The best
> insertion point in the protocol for key expiration is an open
> question, if it's even a good idea at that level at all.  Some flag
> "no more TxOuts exactly like this [after X block?]"?

This would force every wallet to keep an index of all TXOs ever.

> I readily admit I don't have good answers, but it does seem valuable IMO to
> * Prevent users from accidentally sending to an "expired" TxOut/pkh.
> This happens in the field.
> * Discourage address reuse

Actually, I think this may make address reuse easier, as with base58 adding 
data will make it impossible to tell at a glance when someone is reusing a key 
with just a different expiration... I suppose something other than base58 
*could* be used to resolve this, however.

> * Enable sites that generate lots of keys to rotate ancient keys off
> their core systems.  (HD wallets mitigate this)

They can already do this. It's perfectly valid for wallets/services to ignore 
(and not consider as payment) transactions using an address more than once. 
There might be race attacks if this is implemented in an immediate fashon 
(attacker transaction gets mined first to kill a payment), but should be 
pretty safe after a few blocks.

Luke