Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2011-07-04 🗒️ Summary of this message: Bitcoin has ...
📅 Original date posted:2011-07-04
🗒️ Summary of this message: Bitcoin has backward-compatibility issues with wallet encryption, causing errors when attempting to read keypool, and suggestions for workarounds.
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110704/8cb262e3/attachment.sig>;
🗒️ Summary of this message: Bitcoin has backward-compatibility issues with wallet encryption, causing errors when attempting to read keypool, and suggestions for workarounds.
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110704/8cb262e3/attachment.sig>;