diff options
author | Wladimir J. van der Laan <laanwj@gmail.com> | 2017-08-18 18:56:13 +0200 |
---|---|---|
committer | Wladimir J. van der Laan <laanwj@gmail.com> | 2017-08-18 18:56:49 +0200 |
commit | 262167393d05eb46b962cf0515a6dc73c4cec8ea (patch) | |
tree | ed1ff601de6191c4e0616691769f8f03ad3f0578 /doc | |
parent | 0e5b7486cb7f5fb4ffd50d210bac43c3f84c9dd2 (diff) | |
parent | e53615b443894fb96d5eb885b3812776c1b1033b (diff) |
Merge #10952: [wallet] Remove vchDefaultKey and have better first run detection
e53615b Remove vchDefaultKey and have better first run detection (Andrew Chow)
Pull request description:
Removes vchDefaultKey which was only used for first run detection. Improves wallet first run detection by checking to see if any keys were read from the database.
This also fixes a (rather contrived) case where an encrypted non-HD wallet has corruption such that the default key is no longer valid and is loaded into a Core version that supports HD wallets. This causes a runtime exception since a new hd master key is generated as the software believes the wallet file is newly created but cannot add the generated key to the wallet since it is encrypted. I was only able to replicate this error by creating a non-hd wallet, encrypting it, then editing the wallet using `db_dump` and `db_load` before loading the wallet with hd enabled. This problem has been reported by [two](https://bitcointalk.org/index.php?topic=1993244.0) [users](https://bitcointalk.org/index.php?topic=1746976.msg17511261#msg17511261) so it is something that can happen, although that raises the question of "what corrupted the default key".
~P.S. I don't know what's up with the whitespace changes. I think my text editor is doing something stupid but I don't think those are important enough to attempt undoing them.~ Undid those
Tree-SHA512: 63b485f356566e8ffa033ad9b7101f7f6b56372b29ec2a43b947b0eeb1ada4c2cfe24740515d013aedd5f51aa1890dfbe499d2c5c062fc1b5d272324728a7d55
Diffstat (limited to 'doc')
0 files changed, 0 insertions, 0 deletions