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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <luke@dashjr.org>) id 1X742Y-0005gR-U1
for bitcoin-development@lists.sourceforge.net;
Tue, 15 Jul 2014 14:49:10 +0000
X-ACL-Warn:
Received: from zinan.dashjr.org ([192.3.11.21])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1X742X-0001F8-9l for bitcoin-development@lists.sourceforge.net;
Tue, 15 Jul 2014 14:49:10 +0000
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:be5f:f4ff:febf:4f76])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 0051F10803A5;
Tue, 15 Jul 2014 14:49:48 +0000 (UTC)
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Tue, 15 Jul 2014 14:48:55 +0000
User-Agent: KMail/1.13.7 (Linux/3.15.1-gentoo; KDE/4.12.5; x86_64; ; )
References: <CAJHLa0M7iEUQnJ9M4A3ev3EQqxUVQG85qucRamvMb0n-CztOFA@mail.gmail.com>
In-Reply-To: <CAJHLa0M7iEUQnJ9M4A3ev3EQqxUVQG85qucRamvMb0n-CztOFA@mail.gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201407151448.57223.luke@dashjr.org>
X-Spam-Score: -0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1X742X-0001F8-9l
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 14:49:11 -0000
On Tuesday, July 15, 2014 8:00:41 AM 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.
I agree this would be useful for the "permit" case, but not the "confirm" case
- it's important that transactions valid in block X also be equally valid in
block X+1 to avoid reorg issues.
> 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?]"?
This would force every wallet to keep an index of all TXOs ever.
> 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
Actually, I think this may make address reuse easier, as with base58 adding
data will make it impossible to tell at a glance when someone is reusing a key
with just a different expiration... I suppose something other than base58
*could* be used to resolve this, however.
> * Enable sites that generate lots of keys to rotate ancient keys off
> their core systems. (HD wallets mitigate this)
They can already do this. It's perfectly valid for wallets/services to ignore
(and not consider as payment) transactions using an address more than once.
There might be race attacks if this is implemented in an immediate fashon
(attacker transaction gets mined first to kill a payment), but should be
pretty safe after a few blocks.
Luke
|
