Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.210.47 as permitted sender)
	client-ip=209.85.210.47; envelope-from=gavinandresen@gmail.com;
	helo=mail-pz0-f47.google.com; 
MIME-Version: 1.0
In-Reply-To: <1309801974.3423.80.camel@Desktop666>
References: <1309801974.3423.80.camel@Desktop666>
Date: Mon, 4 Jul 2011 14:23:53 -0400
Message-ID: <CABsx9T31ZuQHKwcNnb9-NpaCA6c43PXVZ+Tc+GZ=2Wkz08enHw@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Matt Corallo <bitcoin-list@bluematt.me>
Content-Type: text/plain; charset=ISO-8859-1
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Encrypted Wallet Backward Compatibility
Precedence: list

RE: "You have some unencrypted keys, should I encrypt them for you?"

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").

RE: breaking backup scripts:  if they use the backupwallet  RPC
command, then they will Just Work.

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.

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.

-- 
--
Gavin Andresen