There will be a release candidate 6...
2 messages, 17 Nov 2011. Started by Gavin Andresen.
Gavin Andresen, Michael Offel
I got email from a tester who gave this feedback:
Quoted text (4 lines)
> I think that user behaviour: encrypt wallet -> backup -> do some activity -> > restore backup -> BOOM. Is perfectly natural user behaviour and it will > happen. For example when generating a wallet on a secure computer and then > moving it to an insecure one.
I agree that is likely to happen and, when it does, will be disastrous. So I'll be reworking the wallet encrypt/rewrite code today and creating a release candidate 6.
My previous attempt (encrypt, invalidating keypool, then unlock and write a new keypool) resulted in unencrypted private keys in the new wallet.
I think this will work, I'll implement and test today.
Invalidate all the old keypool keys in the old wallet.Write new keypool keys to the old wallet.Encrypt all the keys in the old wallet.Rewrite the old wallet to create a new wallet.Shutdown/restart. IF ANYBODY IS WILLING TO HELP:
There is still a mysterious problem with bdb throwing an exception when dbenv.close(0) is called during shutdown. If you can compile a -g version of bdb and then step through DbEnv::close in a debugger and tell me why it is throwing an exception that would be extremely helpful.
If you are going to support this use case, you should also notify the user on wallet changes that results in invalidated backup. For example whenever the key pool gets extended.
-----Original Message----- From: Gavin Andresen [mailto:gavinandresen@gmail.com] Sent: 17 November 2011 14:28 To: Bitcoin Dev Subject: [Bitcoin-development] There will be a release candidate 6...
I got email from a tester who gave this feedback:
Quoted text (4 lines)
> I think that user behaviour: encrypt wallet -> backup -> do some > activity -> restore backup -> BOOM. Is perfectly natural user > behaviour and it will happen. For example when generating a wallet on > a secure computer and then moving it to an insecure one.
I agree that is likely to happen and, when it does, will be disastrous. So I'll be reworking the wallet encrypt/rewrite code today and creating a release candidate 6.
My previous attempt (encrypt, invalidating keypool, then unlock and write a new keypool) resulted in unencrypted private keys in the new wallet.
I think this will work, I'll implement and test today.
Invalidate all the old keypool keys in the old wallet.Write new keypool keys to the old wallet.Encrypt all the keys in the old wallet.Rewrite the old wallet to create a new wallet.Shutdown/restart. IF ANYBODY IS WILLING TO HELP:
There is still a mysterious problem with bdb throwing an exception when dbenv.close(0) is called during shutdown. If you can compile a -g version of bdb and then step through DbEnv::close in a debugger and tell me why it is throwing an exception that would be extremely helpful.