From: Matt Corallo <bitcoin-list@bluematt.me>
To: bitcoin-development@lists.sourceforge.net
Subject: [Bitcoin-development] Encrypted Wallet Backward Compatibility
Date: Mon, 04 Jul 2011 19:52:53 +0200 [thread overview]
Message-ID: <1309801974.3423.80.camel@Desktop666> (raw)
[-- Attachment #1: Type: text/plain, Size: 2395 bytes --]
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next reply other threads:[~2011-07-04 17:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-04 17:52 Matt Corallo [this message]
2011-07-04 18:20 ` [Bitcoin-development] Encrypted Wallet Backward Compatibility Luke-Jr
2011-07-04 18:23 ` Gavin Andresen
2011-07-04 20:39 ` Matt Corallo
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=1309801974.3423.80.camel@Desktop666 \
--to=bitcoin-list@bluematt.me \
--cc=bitcoin-development@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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