From: Matt Corallo <bitcoin-list@bluematt•me>
To: bitcoin-development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Encrypted Wallet Backward Compatibility
Date: Mon, 04 Jul 2011 22:39:32 +0200 [thread overview]
Message-ID: <1309811972.29355.19.camel@Desktop666> (raw)
In-Reply-To: <CABsx9T31ZuQHKwcNnb9-NpaCA6c43PXVZ+Tc+GZ=2Wkz08enHw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2456 bytes --]
For some reason my mail client let me respond off-list here, didnt mean
to...
On Mon, 2011-07-04 at 14:23 -0400, Gavin Andresen wrote:
> 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").
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...
>
> 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.
I suppose I just really dont like the idea of renaming wallet.dat,
everything knows the filename and is used to it.
>
> 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?
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2011-07-04 20:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-04 17:52 Matt Corallo
2011-07-04 18:20 ` Luke-Jr
2011-07-04 18:23 ` Gavin Andresen
2011-07-04 20:39 ` Matt Corallo [this message]
2011-07-05 1:10 ` Matt Corallo
2011-07-05 2:26 ` Gavin Andresen
2011-07-05 2:45 ` Jeff Garzik
2011-07-10 14:21 ` Matt Corallo
2011-07-10 19:10 ` Pieter Wuille
2011-07-05 11:03 ` Matt Corallo
2011-07-04 20:59 ` Gregory Maxwell
2011-07-04 21:18 ` Douglas Huff
2011-07-04 22:30 ` Gregory Maxwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1309811972.29355.19.camel@Desktop666 \
--to=bitcoin-list@bluematt$(echo .)me \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox