From: Peter Todd <pete@petertodd•org>
To: Jeff Garzik <jgarzik@bitpay•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Bitcoin address TTL & key expiration?
Date: Tue, 15 Jul 2014 04:20:20 -0400 [thread overview]
Message-ID: <20140715082020.GA22936@petertodd.org> (raw)
In-Reply-To: <CAJHLa0M7iEUQnJ9M4A3ev3EQqxUVQG85qucRamvMb0n-CztOFA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2630 bytes --]
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.
--
'peter'[:-1]@petertodd.org
000000000000000032d9d8942fe9461cce9db22a6cd86eacb5c18b415ebb649d
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
next prev parent reply other threads:[~2014-07-15 8:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-15 8:00 Jeff Garzik
2014-07-15 8:19 ` Wladimir
2014-07-15 8:23 ` Jeff Garzik
2014-07-15 8:31 ` Jeremy Spilman
2014-07-15 8:48 ` Wladimir
2014-07-15 8:20 ` Peter Todd [this message]
2014-07-15 10:25 ` Mike Hearn
2014-07-15 14:02 ` Jeff Garzik
2014-07-15 14:27 ` Mike Hearn
2014-07-15 14:48 ` Luke Dashjr
2014-07-15 15:11 ` Jeff Garzik
2014-07-15 15:18 ` Mike Hearn
2014-07-15 15:35 ` Jeff Garzik
2014-07-15 15:41 ` Luke Dashjr
2014-07-15 15:55 ` Jeff Garzik
2014-07-15 16:26 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140715082020.GA22936@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jgarzik@bitpay$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox