summaryrefslogtreecommitdiff
path: root/ae/f0ba8ff03edae5b8eff623f9dcd4410f60e493
blob: 7c4406906d8300cf6f608a33ad1cf7b2f5db6691 (plain)
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
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <bitcoin-list@bluematt.me>) id 1QdnKY-0001eY-Fg
	for bitcoin-development@lists.sourceforge.net;
	Mon, 04 Jul 2011 17:53:10 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bluematt.me
	designates 208.79.240.5 as permitted sender)
	client-ip=208.79.240.5; envelope-from=bitcoin-list@bluematt.me;
	helo=smtpauth.rollernet.us; 
Received: from smtpauth.rollernet.us ([208.79.240.5])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1QdnKV-0007QS-7q
	for bitcoin-development@lists.sourceforge.net;
	Mon, 04 Jul 2011 17:53:10 +0000
Received: from smtpauth.rollernet.us (localhost [127.0.0.1])
	by smtpauth.rollernet.us (Postfix) with ESMTP id 820F3594014
	for <bitcoin-development@lists.sourceforge.net>;
	Mon,  4 Jul 2011 10:52:45 -0700 (PDT)
Received: from mail.bluematt.me (unknown
	[IPv6:2001:470:9ff2:2:20c:29ff:fe16:f239])
	(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: @bluematt.me)
	by smtpauth.rollernet.us (Postfix) with ESMTPSA
	for <bitcoin-development@lists.sourceforge.net>;
	Mon,  4 Jul 2011 10:52:45 -0700 (PDT)
Received: from [IPv6:2001:470:9ff2:1:2c0:caff:fe33:858b] (unknown
	[IPv6:2001:470:9ff2:1:2c0:caff:fe33:858b])
	by mail.bluematt.me (Postfix) with ESMTPSA id 6D5955095
	for <bitcoin-development@lists.sourceforge.net>;
	Mon,  4 Jul 2011 19:52:55 +0200 (CEST)
From: Matt Corallo <bitcoin-list@bluematt.me>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/signed; micalg="pgp-sha1";
	protocol="application/pgp-signature";
	boundary="=-7FeW1JlPeh9js0K2KinF"
Date: Mon, 04 Jul 2011 19:52:53 +0200
Message-ID: <1309801974.3423.80.camel@Desktop666>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.2 
X-Rollernet-Abuse: Processed by Roller Network Mail Services. Contact
	abuse@rollernet.us to report violations. Abuse policy:
	http://rollernet.us/abuse.php
X-Rollernet-Submit: Submit ID f16.4e11fded.2f8a5.0
X-Spam-Score: -1.5 (-)
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
X-Headers-End: 1QdnKV-0007QS-7q
Subject: [Bitcoin-development] Encrypted Wallet Backward Compatibility
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: Mon, 04 Jul 2011 17:53:10 -0000


--=-7FeW1JlPeh9js0K2KinF
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

joric rightly points out that there are currently backward-compatibility
issues with Wallet encryption. As it stands now:
In version 0.3.23, Bitcoin dies with "ReserveKeyFromKeyPool() : unknown
key in key pool" after writing one unencrypted private key to the
(otherwise) encrypted wallet.
In version 0.3.22 (and I'd assume prior versions as well), Bitcoin opens
fine and displays transactions, however shows a total balance of what is
help only in unencrypted keys (of which it also writes a minimum of one
before opening), and each transaction shows only confirmation count,
date, no description, and a debit/credit of 0.00.  When you try to
perform any action which attempts to read keypool, you get the
"ReserveKeyFromKeyPool() : unknown key in key pool" error.

So, the question is how best to work around Bitcoin's overwillingness to
load wallets with keys that it has no clue about.

There were several suggestions of renaming wallet.dat for encrypted
wallets.  Obviously this has many advantages and disadvantages.  It
breaks backup scripts, old clients will now create a new wallet instead
of using the old one, potentially causing users to (wrongfully) assume
their wallet is encrypted if they accidentally start opening an old
version.  Im not a huge fan of this one, mostly because if a user opens
an old version, they will get a blank transactionless wallet which IMO
is worse than an odd error message.  "My wallet is gone, Ive lost
everything, wtf???" vs "My wallet got corrupted, crap need see what I
can recover from it, I hope I dont lose much"

Another option is to simply do nothing, and let old clients get mad.  If
a user goes back to an old client, it cant spend coins using the
encrypted keys no matter what is done.  If the new client handles
multiple key types gracefully, however, it can simply say "Hey, I see
you have a mix of key types here, can I have your password to encrypt
the unencrypted ones?" and move on with no harm done.  IMO, I would much
prefer old users see error messages and be unable to use their wallet,
then accidentally create multiple wallets, and give them a screen making
them think their coins are all gone.  Comments?

PS. to prevent this in the future, Bitcoin really shouldn't continue on
as if nothing had happened when faced with unknown keys:
https://github.com/bitcoin/bitcoin/pull/378

Matt

--=-7FeW1JlPeh9js0K2KinF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAABAgAGBQJOEf3qAAoJEBrh01BD4I5UhBMP/04PKvy7vTUR4lYHi3RsSs3L
5mOu1SNVaEDkbu5cHnSKgm5UyYB1db4BeYofYjfJxjl334uIsMfg6HVRB/yqavcn
MxdDDWG96MCD6NgJbuwEmhP67VB0XR2ecBuroXbiZJSLHkpgJDnlbSq2hMMJYuJ3
ZLorsMEpd9k4bNLMTuDXG5TcVFXTePRFIXUaWX7EIjI1qaH7RfeqpIV48cr6/PZP
TTp+ohkdp23zktAJgTbrqaVpGdUw0f/OQtfJ0qyD5F8TjDjjOu67jzZX0KZ4QIQZ
29jjDbm6Flib9jrDZ+UAtU7AT1nUsgWlCgL7EzyJKkRonyu8X3+ajhxZ1/0kL3jm
dn773uCd/n3HNqLvZGJQq0TOMRnKeaw6/G+xWh+CjTECb3sNj3ZFDddyPmyRT4Vs
xubjqSJ3b2NNA0noDVXRhCMZb8K31p2NZ70s0Oo6uI2HK6qsip7bB1VJJ4crp7wM
In22An2KUITqyKRHBnYCVqZazTRySSMeQdv5MjN0rLlPfdPilJ0xbVmvBy7Hz0mg
iuOChACtFe9FKwCSs1zfWQsO3ttw/iRMBpIDBTzcMDoaXk/MrNLOLe4Q5aicpMXp
+l0/fG1o2plkzQjdrTUNBCcaVBH+at06ZJ7mS2sTuDE/+xumI6o6bcZa37mc1qDq
oggMmmFa8XlAWupRVFNl
=FNrC
-----END PGP SIGNATURE-----

--=-7FeW1JlPeh9js0K2KinF--