From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 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: In-Reply-To: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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