Re: [Bitcoin-development] Key retirement and key compromise

[Roy Badami <roy@gnomon.org.uk>]

On Fri, Feb 22, 2013 at 11:08:51PM +0000, I wrote:

> What would be really nice is for bitcoin to have a big key compromise
> button, which would automatically transfer all coins to newly
> generated addresses (optionally with a pause between generation and
> transaction - to allow for a new wallet backup).  Optionally, too, the
> compromised/retired addresses could be marked with a flag such that if
> someone sends coins to that address bitcoind immediately generates a
> transaction to transfer the coins to address(es) which are good.

On Mon, Feb 25, 2013 at 09:23:53AM -0800, Andrew Poelstra wrote:

> The problem with automatic transactions would be: by repeatedly sending
> money to an address and seeing if it always moves quickly, an attacker
> can identify (a) that an address is in use, (b) which public key it has
> (if this isn't already public), and (c) that the key is believed to be
> compromised.

I realise on reflection that what I really want is not automatic
transmissions, but a means to revoke an address.

The problem is that after transfering the coins from the compromised
addresses to a new, hopefully safe address, what to do about the fact
that third parties might still try to send me coins to an old,
compromised address.  So what I think I'm suggesting is that there
should be an address revocation protocol, such that clients will give
an error if their user tries to send coins to a revoked address.

Unless we think that direct payments to addresses will become
completely obsolete once the payment protocol is in use, in which case
(maybe) this functionality belongs in the payment protocol instead -
but I remain unconvinced of that.

I'm not envisaging something as drastic as changing the rules to make
transactions to revoked addresses invalid - just an overlay protocol.
Although to be useful such a protocol would have to be pretty much
universally implemented by clients.

Thoughts?

roy