public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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



  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 [Bitcoin-development] Bitcoin address TTL & key expiration? 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.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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