[Bitcoin-development] Bitcoin address TTL & key expiration?
pete at petertodd.org
Tue Jul 15 08:20:20 UTC 2014
On Tue, Jul 15, 2014 at 04:00:41AM -0400, 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.
Note that "digitally signed" has no value here without some kind of
PKI/WoT/something else to know what key is doing the signing. I believe
Jeff is really referring to the checksum by "hash-sealed" here, which is
as good as is worth getting.
> 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)
A few months ago I looked into what low-level details it'd take to add
Bitcoin addresses to OpenPGP keys a few months ago; one of the
requirements we came up with was to make sure the standard OpenPGP
expiration machinery would still work. Basically in that model the
Bitcoin address - most likely a stealth address for privacy - is added
to the key as signed data. All signatures in OpenPGP have optional
expiration times, and additionally they can be revoked after the fact if
needed as well.
Of course, such ideas aren't limited to OpenPGP - all payment protocols
should consider adopting them.
As for protocol level hacks, keep in mind that anything that makes a
transaction invalid because of the presence of a specific scriptPubKey
in a txout has the potential to make a whole chain of transactions
become invalid during a reorg. Adding such protection in the form of
IsStandard() policy would be ok, but as a protocol rule it'd be pretty
dangerous. IMO much better to just solve the problem at the UI level.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 685 bytes
Desc: Digital signature
More information about the bitcoin-dev