From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QduAY-0001V0-Gt for bitcoin-development@lists.sourceforge.net; Tue, 05 Jul 2011 01:11:18 +0000 Received-SPF: pass (sog-mx-3.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-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1QduAV-0002yq-9z for bitcoin-development@lists.sourceforge.net; Tue, 05 Jul 2011 01:11:18 +0000 Received: from smtpauth.rollernet.us (localhost [127.0.0.1]) by smtpauth.rollernet.us (Postfix) with ESMTP id 2B300594010 for ; Mon, 4 Jul 2011 18:10:54 -0700 (PDT) Received: from mail.bluematt.me (p579B4A6D.dip.t-dialin.net [87.155.74.109]) (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 18:10:53 -0700 (PDT) Received: from [10.232.3.2] (router.dmz.bluematt.me [10.232.4.1]) by mail.bluematt.me (Postfix) with ESMTPSA id B0CDAB344 for ; Tue, 5 Jul 2011 03:10:38 +0200 (CEST) From: Matt Corallo To: bitcoin-development@lists.sourceforge.net In-Reply-To: <1309811972.29355.19.camel@Desktop666> References: <1309801974.3423.80.camel@Desktop666> <1309811972.29355.19.camel@Desktop666> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-0z97IdIM9bXFfg0dmaja" Date: Tue, 05 Jul 2011 03:10:39 +0200 Message-ID: <1309828239.29355.28.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 14f8.4e12649d.d9c99.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: 1QduAV-0002yq-9z Subject: Re: [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: Tue, 05 Jul 2011 01:11:18 -0000 --=-0z97IdIM9bXFfg0dmaja Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Despite this being quick, I really want to get 0.3.24 out and rolling so that we have us much lead time on 0.4 as possible so that any solution to this problem that is better in 0.3.24 can be in as many hands as possible, and so that the network issues can be resolved. All that needs to happen for that is to agree on either https://github.com/bitcoin/bitcoin/pull/378 or https://github.com/bitcoin/bitcoin/pull/381 thus, I would ask that we get acks on those and then continue this discussion. Frankly, I prefer 378 as it is simpler and means that you dont have to keep track of what features you have or have not used in a wallet, but instead just write and let the keys take care of themselves. However, I'm game for either, I just want to get 0.3.24 out the door ASAP (ie preferably rc2 tomorrow and release by the end of the week). Matt On Mon, 2011-07-04 at 22:39 +0200, Matt Corallo wrote: > For some reason my mail client let me respond off-list here, didnt mean > to... >=20 > On Mon, 2011-07-04 at 14:23 -0400, Gavin Andresen wrote: > > RE: "You have some unencrypted keys, should I encrypt them for you?" > >=20 > > That re-opens an "attacker packs the keypool with keypairs that they > > know about" (if I can read/write wallet.dat, then I can delete > > encrypted keypool keys and insert a bunch of unencrypted keypool keys > > that I know how to spend, and rely on the user to click "OK" because > > users are trained to just click "OK"). > Not strictly true, if the keys are loaded, but not added to > mapAddressBook or setKeyPool, they wont be used for any new > transactions, or shown to the user, but the user is still able to > receive Bitcoins to those keys. > > RE: breaking backup scripts: if they use the backupwallet RPC > > command, then they will Just Work. > Not really, most backupwallet-based scripts will backup wallet.dat, > encrypt wallet.dat, upload wallet.dat. Now it backups up wallet.dat and > the encrypt part fails because there is no wallet.dat, only > wallet_e.dat. If we rename to wallet.dat on output, now the user's > restore might not work... > >=20 > > 0.4 and later could, on wallet encryption, create a wallet_e.dat > > (encrypted wallet). Then truncate wallet.dat and set its > > file-permissions to 000, so if old versions of bitcoin OR any dumb > > wallet backup scripts try to read it they fail. > True, but that is only a solution for Linux and Mac and then you are > back to unreadable error on Windows load and other unforeseeable errors > for odd scripts. >=20 > I suppose I just really dont like the idea of renaming wallet.dat, > everything knows the filename and is used to it. > >=20 > > RE: future-proofing: wallet.dat contains nFileVersion (version of > > bitcoin that last wrote the wallet). Adding a nMinVersion that > > specifies "you must be at least THIS version to read this file" seems > > like a good idea so if you have version 0.4 or later future wallet > > upgrades give you a reasonable message if you try to downgrade after > > an incompatible change. > Yep, just something simple that says, no reading this to old versions is > needed, IMO the older version should freak out if it sees keys that it > doesn't know about (as it could also indicate wallet corruption in some > rare cases), but nMinVersion works just as well, in any case this should > only very rarely be a problem...how often will we change the wallet > format? --=-0z97IdIM9bXFfg0dmaja 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) iQIcBAABAgAGBQJOEmSIAAoJEBrh01BD4I5UFWoP/3CdecGX5DFbJan8yYRRUW8o OkbaakmX6YvQ4vvdWWHaOpbRmStJ/YvtdZ5Oj7AbCT1wnJ2+sv8wiM8iWgEmiimq ecG4CCqOzH+aEElvt4ZkHU1f9HPww2qFUMdL8QevesfSalJMhNW8viDHhepd/b44 1TqziyGE5a6lKhDaJBorfzAl8GrV+xomCeeiUUBJFXlwllNqFNHBMKvzgN7Lrzyo RiFhgyNC06CdSkm9sLRCDAZcYGnqnVJBYdeOlcEKJa9iljTjK1gLmCewn6GJvFB6 vD4XwM79tLN9Q2XJBSZrGpN80mtcGsfVhpDUK1Nh35YVjohF4/YggdXBy2QlorRf PuNMNh5Ww/aI3w4WsFiQcIy+3wazxZ7OI5dKEkiqk3+z7iq64TtAoIYP7zlxXbe8 s9WOqPSNayf/Nsk1CvBGawfwh1SRI8b33kHsZ7DNTsjkwIPbdwgTXQ8E4FV1rnlV 4Vgb6Vk3vMpWtS8cfvscrBXIjnnoetii0+lnMwqZlWU96jCAO0hLdj9v736339ob KT/h18AuG01hakbKbZV/1p4DzZUP/pLlgo8WKsTxbIliJivBYxeXadRw66fsBsfd 8x2pI14wks0ouSictX9x5xqUjluOl1bz23Lz6FRZYkXuJu9MSKuYaAphnFIxKPuf yK7fbyfchRm2g0bKqiiA =0gT6 -----END PGP SIGNATURE----- --=-0z97IdIM9bXFfg0dmaja--