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; 
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
Subject: [Bitcoin-development] Encrypted Wallet Backward Compatibility
Precedence: list


--=-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--