1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
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--
|
