From: Roy Badami <roy@gnomon•org.uk>
To: Andrew Poelstra <asp11@sfu•ca>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Key retirement and key compromise
Date: Mon, 25 Mar 2013 20:49:11 +0000 [thread overview]
Message-ID: <20130325204911.GD65880@giles.gnomon.org.uk> (raw)
In-Reply-To: <20130225172353.GA7782@malakian.dd-wrt>
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
next prev parent reply other threads:[~2013-03-25 20:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-22 23:08 Roy Badami
2013-02-25 9:41 ` Jorge Timón
2013-02-25 19:44 ` Peter Vessenes
[not found] ` <20130225172353.GA7782@malakian.dd-wrt>
2013-03-25 20:49 ` Roy Badami [this message]
2013-03-25 21:10 ` Gregory Maxwell
2013-03-25 21:35 ` Roy Badami
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=20130325204911.GD65880@giles.gnomon.org.uk \
--to=roy@gnomon$(echo .)org.uk \
--cc=asp11@sfu$(echo .)ca \
--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