1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <roy@gnomon.org.uk>) id 1U91yj-0006rv-JB
for bitcoin-development@lists.sourceforge.net;
Fri, 22 Feb 2013 23:24:33 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gnomon.org.uk
designates 93.93.131.22 as permitted sender)
client-ip=93.93.131.22; envelope-from=roy@gnomon.org.uk;
helo=darla.gnomon.org.uk;
Received: from darla.gnomon.org.uk ([93.93.131.22])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1U91yg-0003CS-Np
for bitcoin-development@lists.sourceforge.net;
Fri, 22 Feb 2013 23:24:33 +0000
Received: from darla.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1])
by darla.gnomon.org.uk (8.14.3/8.14.3) with ESMTP id r1MN8p5X053740
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
for <bitcoin-development@lists.sourceforge.net>;
Fri, 22 Feb 2013 23:08:57 GMT (envelope-from roy@darla.gnomon.org.uk)
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.95.3 at darla.gnomon.org.uk
Received: (from roy@localhost)
by darla.gnomon.org.uk (8.14.3/8.14.1/Submit) id r1MN8pap053739
for bitcoin-development@lists.sourceforge.net;
Fri, 22 Feb 2013 23:08:51 GMT (envelope-from roy)
Date: Fri, 22 Feb 2013 23:08:51 +0000
From: Roy Badami <roy@gnomon.org.uk>
To: bitcoin-development@lists.sourceforge.net
Message-ID: <20130222230851.GO2030@giles.gnomon.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Spam-Score: -2.2 (--)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
-0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1U91yg-0003CS-Np
Subject: [Bitcoin-development] Key retirement and key compromise
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 22 Feb 2013 23:24:33 -0000
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
|
