From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 ; 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 ; Mon, 4 Jul 2011 19:52:55 +0200 (CEST) From: Matt Corallo 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--