Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bitpay.com
	designates 74.125.82.50 as permitted sender)
	client-ip=74.125.82.50; envelope-from=jgarzik@bitpay.com;
	helo=mail-wg0-f50.google.com; 
MIME-Version: 1.0
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Tue, 15 Jul 2014 04:00:41 -0400
Message-ID: <CAJHLa0M7iEUQnJ9M4A3ev3EQqxUVQG85qucRamvMb0n-CztOFA@mail.gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
Subject: [Bitcoin-development] Bitcoin address TTL & key expiration?
Precedence: list

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.

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?]"?

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
* Enable sites that generate lots of keys to rotate ancient keys off
their core systems.  (HD wallets mitigate this)

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/