diff options
| author | Peter Todd <pete@petertodd.org> | 2014-07-15 04:20:20 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-07-15 08:20:38 +0000 |
| commit | d0a312c4289a13662af3300aeb02d1cc3000f013 (patch) | |
| tree | a4fe2a8f1474794c691efedd0db3d1078a6c78b5 | |
| parent | a34d24ee7446ecc1c95aefa913741ecb456ff61a (diff) | |
| download | pi-bitcoindev-d0a312c4289a13662af3300aeb02d1cc3000f013.tar.gz pi-bitcoindev-d0a312c4289a13662af3300aeb02d1cc3000f013.zip | |
Re: [Bitcoin-development] Bitcoin address TTL & key expiration?
| -rw-r--r-- | 66/8e9a62da5cffa26f1cfc4c204e3ab512e84f1b | 152 |
1 files changed, 152 insertions, 0 deletions
diff --git a/66/8e9a62da5cffa26f1cfc4c204e3ab512e84f1b b/66/8e9a62da5cffa26f1cfc4c204e3ab512e84f1b new file mode 100644 index 000000000..a05f15469 --- /dev/null +++ b/66/8e9a62da5cffa26f1cfc4c204e3ab512e84f1b @@ -0,0 +1,152 @@ +Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] + helo=mx.sourceforge.net) + by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <pete@petertodd.org>) id 1X6xyY-0000pP-0s + for bitcoin-development@lists.sourceforge.net; + Tue, 15 Jul 2014 08:20:38 +0000 +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; +Received: from outmail148102.authsmtp.net ([62.13.148.102]) + by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) + id 1X6xyW-0003t5-GG for bitcoin-development@lists.sourceforge.net; + Tue, 15 Jul 2014 08:20:37 +0000 +Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) + by punt14.authsmtp.com (8.14.2/8.14.2) with ESMTP id s6F8KTra012511; + Tue, 15 Jul 2014 09:20:29 +0100 (BST) +Received: from petertodd.org (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) + (authenticated bits=128) + by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s6F8KK23087939 + (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); + Tue, 15 Jul 2014 09:20:23 +0100 (BST) +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) +X-Server-Quench: de3a8b2e-0bf8-11e4-9f74-002590a135d3 +X-AuthReport-Spam: If SPAM / abuse - report it at: + http://www.authsmtp.com/abuse +X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR + aAdMdwcUEkAYAgsB AmIbW11eUl17W2A7 bAxPbAVDY01GQQRq + WVdMSlVNFUsrB2oJ fWUcURl6cAxFcTBx Z0BmXD4PCUcrfRR/ + F1NURzsOeGZhPWQC WRZfcx5UcAFPdx8U a1N6AHBDAzANdhES + HhM4ODE3eDlSNilR RRkIIFQOdA4hHyI3 QBEEVTwjEVcIXD57 + EyACYhBUH0sAekgi KVo7UE4ZNBlFYgAA +X-Authentic-SMTP: 61633532353630.1024:706 +X-AuthFastPath: 0 (Was 255) +X-AuthSMTP-Origin: 76.10.178.109/587 +X-AuthVirus-Status: No virus detected - but ensure you scan with your own + anti-virus system. +X-Spam-Score: -1.5 (-) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + -0.0 SPF_PASS SPF: sender matches SPF record +X-Headers-End: 1X6xyW-0003t5-GG +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Bitcoin address TTL & key expiration? +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Tue, 15 Jul 2014 08:20:38 -0000 + + +--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-- + + |