From: Roy Badami <roy@gnomon•org.uk>
To: bitcoin-development@lists•sourceforge.net
Subject: [Bitcoin-development] Key retirement and key compromise
Date: Fri, 22 Feb 2013 23:08:51 +0000 [thread overview]
Message-ID: <20130222230851.GO2030@giles.gnomon.org.uk> (raw)
Has anyone been thinking about providing tools to allow users to cope
with key compromise - or more generally, to manage key retirement etc?
atm, if you suspect that your keys may be liable to compromise then
what would you have to do? You'd have to create a new wallet (on a
new computer? or is it easy to have two coexisting installs on one
computer?) And then you'd have to make one or more payments from the
old wallet to the new wallet, to transfer the coins. It's a pain, and
you've lost your address book, your transaction history, etc. And
unless you keep the old wallet about, too, you're a bit stuck if
someone makes a payment to one of the old addresses. It's something
that most users would baulk at unless they're really sure they're at
significant risk.
Of course, there are a spectrum of scenarios, ranging from having an
unencrypted wallet stolen by someone who knows what it is, through to
deciding that the passphrase you used to use when you only had a few
dollars worth of BTC maybe isn't good enough now you've got tens of
thousands of dollars worth of coins. Or maybe you have no reason to
suspect there is a risk of compromise, but just have a corporate key
management policy that recommends retiring keys after a period of
time.
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.
I know deterministic wallets have many proponents - but personally I
like having a bag of keys - with the idea that over a period of time,
old keys will routinely be retired and their balances automatically
transfered to newly generated keys. If someone really manages to
crack the passphrase on that 10-year-old wallet backup they got hold
of, then if would be nice to minimise the damage they could do...
And, of course, I want a big panic button that allows me to
automatically transfer all my coins to new addresses ASAP if I
suddenly do something stupid, like accidentally type my passphrase
into my IRC window :-)
Thoughts? Is this functionality that there is any interest in
developing within the official client? If there is any interest in
this then obviously the first step would be to specify exactly what
functionality is wanted...
roy
next reply other threads:[~2013-02-22 23:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-22 23:08 Roy Badami [this message]
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
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=20130222230851.GO2030@giles.gnomon.org.uk \
--to=roy@gnomon$(echo .)org.uk \
--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