Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.102 as permitted sender)
	client-ip=62.13.148.102; envelope-from=pete@petertodd.org;
	helo=outmail148102.authsmtp.net; 
Date: Tue, 15 Jul 2014 04:20:20 -0400
From: Peter Todd <pete@petertodd.org>
To: Jeff Garzik <jgarzik@bitpay.com>
Message-ID: <20140715082020.GA22936@petertodd.org>
References: <CAJHLa0M7iEUQnJ9M4A3ev3EQqxUVQG85qucRamvMb0n-CztOFA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8"
Content-Disposition: inline
In-Reply-To: <CAJHLa0M7iEUQnJ9M4A3ev3EQqxUVQG85qucRamvMb0n-CztOFA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bitcoin address TTL & key expiration?
Precedence: list


--MGYHOYXEY6WxJCY8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 15, 2014 at 04:00:41AM -0400, Jeff Garzik wrote:
> Proxying another's idea, from CoinSummit.
>=20
> 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.
>=20
> 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?]"?
>=20
> 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.

--=20
'peter'[:-1]@petertodd.org
000000000000000032d9d8942fe9461cce9db22a6cd86eacb5c18b415ebb649d

--MGYHOYXEY6WxJCY8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQGrBAEBCACVBQJTxORAXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxYTQ1NDA5OGQ3ZmEzMjdjODIxNGE1ODZjNDQ0NDM3MDRi
MzQ4NWVlYmE4NDYzMzMvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuxxwf/ZQEeRNmbpR4aZh7tuw3yQqX8
UbzIgMwEHxLdyC24VsEIF0W9WjPVOBOMmqlW5I1AjZd3nwWnZQ2yxsHoAgjIfVX1
hiIR5i6iB4MXb4MapYNxnL6pmo6JE5yCjEtxn0I+Z9CMrJpbt4+1FvrEmzrCCD3Z
koR9lDk77+JOItgzCSmhRkcBAdKO8FlnZ9Dsc4t5K8Nm9eofrgd62L+Galqzxu1X
XQiTBD2nwQv2pJzbuHG2LtjrxRIXCMXoURpxZCAMKzYM10jhbow7VnzENQtauZkU
DXuq3kYvAEI31brCkbjMUumtRnhrVW6DwHSSvECWE2WOuSYjA4DlaOumLGI3XQ==
=LXh9
-----END PGP SIGNATURE-----

--MGYHOYXEY6WxJCY8--