From: Luke Dashjr <luke@dashjr•org>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Bitcoin address TTL & key expiration?
Date: Tue, 15 Jul 2014 14:48:55 +0000 [thread overview]
Message-ID: <201407151448.57223.luke@dashjr.org> (raw)
In-Reply-To: <CAJHLa0M7iEUQnJ9M4A3ev3EQqxUVQG85qucRamvMb0n-CztOFA@mail.gmail.com>
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
next prev parent reply other threads:[~2014-07-15 14:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-15 8:00 Jeff Garzik
2014-07-15 8:19 ` Wladimir
2014-07-15 8:23 ` Jeff Garzik
2014-07-15 8:31 ` Jeremy Spilman
2014-07-15 8:48 ` Wladimir
2014-07-15 8:20 ` Peter Todd
2014-07-15 10:25 ` Mike Hearn
2014-07-15 14:02 ` Jeff Garzik
2014-07-15 14:27 ` Mike Hearn
2014-07-15 14:48 ` Luke Dashjr [this message]
2014-07-15 15:11 ` Jeff Garzik
2014-07-15 15:18 ` Mike Hearn
2014-07-15 15:35 ` Jeff Garzik
2014-07-15 15:41 ` Luke Dashjr
2014-07-15 15:55 ` Jeff Garzik
2014-07-15 16:26 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201407151448.57223.luke@dashjr.org \
--to=luke@dashjr$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox