Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[0.13] Create a new HD seed after encrypting the wallet #8389
@pstratem It reads to me as if the old
This WriteHDChain() function is used each time a new address is generated:
The original chain could be stored under a different database key if we need to keep it around somewhere.
@pstratem: CWalletDB and BDB is a key value storage as far as I know. Writing the same key at later stage should replace the current value. It may be possible to have the old K/V still stored in the database, though, CWalletDB/BDB needs to make sure the later write operation will result in the laster read/mem-map operation during load wallet.
But I agree we need to keep track of the older/replaced seed. Maybe we should add something to the CKeyMetadata in that case (or at least CAddressBook).
Pushed a commit that...
https://github.com/bitcoin/bitcoin/pull/8206/files would make use of this. It would show old/rewritten master keys in the dumped wallet.
referenced this pull request
Jul 22, 2016
I did this:
$ rm ~/.bitcoin/regtest/wallet.dat $ src/bitcoind -regtest -rpcport=1234 -daemon -usehd=1 Bitcoin server starting $ src/bitcoin-cli -regtest -rpcport=1234 dumpwallet "/tmp/dump_pre" $ src/bitcoin-cli -regtest -rpcport=1234 encryptwallet "pass" wallet encrypted; Bitcoin server stopping, restart to run with encrypted wallet. The keypool has been flushed, you need to make a new backup. $ src/bitcoind -regtest -rpcport=1234 -daemon -usehd=1 Bitcoin server starting $ src/bitcoin-cli -regtest -rpcport=1234 walletpassphrase "pass" 12345 $ src/bitcoin-cli -regtest -rpcport=1234 dumpwallet "/tmp/dump_post" $ src/bitcoin-cli -regtest -rpcport=1234 stop $ diff -du /tmp/dump_pre /tmp/dump_post
Looks OK to me. The old reserve keys have been demoted to "change", and there are new reserve keys in the keypool. These keys are different, suggesting a new master key was used to generate them.
The old master key was kept around as "oldhdmaster":
-cSoMD7tEsoJNfSS3cL6N3E9gXpuQh7wgs79RDUBE6NjTEWS6Ptda 2016-07-28T10:48:28Z hdmaster=1 # addr=msqHNkZcD6ybT7xdCkquN4esLPLmoRyk8b hdkeypath=m +cSoMD7tEsoJNfSS3cL6N3E9gXpuQh7wgs79RDUBE6NjTEWS6Ptda 2016-07-28T10:48:28Z inactivehdmaster=1 # addr=msqHNkZcD6ybT7xdCkquN4esLPLmoRyk8b hdkeypath=m
And a new one was added
+cRrbkixFuTz1esCbJTz3QqNGyEcPjFCjVyHRTy1JDxKDbHYXn9Qd 2016-07-28T10:48:43Z hdmaster=1 # addr=n3phnt6MDc2xUvKXrf8iW6ZiwtL2i7Rusm hdkeypath=m
The single key that is automatically generated (with empty label) at initialization stayed the same
cRj4c74AFYdH9W1vbM3UgnaCeGbwztu3qb11NgDReiudtS2Q1ZAr 2016-07-28T10:48:28Z label= # addr=mwR8SR9sfKk7Q8z99xpdcCUNtccq81iRup hdkeypath=m/0'/0'/0'
For the new reserve keys it starts counting again at
+cNRrj6BtSxcXySqU6WgWgGEHMARifd1VXCVECdsXx4ervHE7iS4t 2016-07-28T10:48:43Z reserve=1 # addr=moBwgfzRf8H4ZjweCbQcckuJbMC16jwtD1 hdkeypath=m/0'/0'/0'
I think everything is as expected. Tested ACK.