When restoring a backup, we should restore the wallet metadata. This moves some of it out of "comment" sections so that it can be sensibly handled by parsing tools.
(importwallet doesn't currently support it, but that's another matter to address)
When restoring a backup, we should restore the wallet metadata. This moves some of it out of "comment" sections so that it can be sensibly handled by parsing tools.
(importwallet doesn't currently support it, but that's another matter to address)
659 | @@ -660,19 +660,26 @@ UniValue dumpwallet(const JSONRPCRequest& request) 660 | std::string strAddr = CBitcoinAddress(keyid).ToString(); 661 | CKey key; 662 | if (pwallet->GetKey(keyid, key)) { 663 | + CKeyMetadata meta;
In this case how about:
CKeyMetadata meta = pwallet->mapKeyMetadata[keyid];
operator[] can also create map items. Even if this never occurs, it needs to generate code for it.
Right, off topic, but if above was changed to const CWallet * const pwallet then that would be false.
operator[] isn't valid at all on const maps AFAIK...?
Indeed! Sorry for the noise.
n.b. C++11 added std::map::at, but this isn't useful since we need to correctly handle the case where there is no metadata.
679 | file << "inactivehdmaster=1";
680 | } else {
681 | file << "change=1";
682 | }
683 | - file << strprintf(" # addr=%s%s\n", strAddr, (pwallet->mapKeyMetadata[keyid].hdKeypath.size() > 0 ? " hdkeypath="+pwallet->mapKeyMetadata[keyid].hdKeypath : ""));
684 | + file << strprintf(" # addr=%s%s\n", strAddr, (meta.hdKeypath.empty() ? "" : (" hdkeypath=" + meta.hdKeypath)));
Nit, partial unrelated change to what commit stands for.
Update test? Squash 2nd and 3rd commits?
680 | } else {
681 | file << "change=1";
682 | }
683 | - file << strprintf(" # addr=%s%s\n", strAddr, (pwallet->mapKeyMetadata[keyid].hdKeypath.size() > 0 ? " hdkeypath="+pwallet->mapKeyMetadata[keyid].hdKeypath : ""));
684 | + if (!meta.hdKeypath.empty()) {
685 | + file << " hdkeypath=" + meta.hdKeypath;
What is the reason to move this out of the comment section?
It's metadata that should be restored. (our importwallet doesn't support it, but that's another matter)
@luke-jr: can you please elaborate a little bit what situation this PR does improve?
@luke-jr Can you please answer @jonasschnelli 's question? There is no rationale in the OP at all.
Rebased
Tested ACK https://github.com/bitcoin/bitcoin/pull/11803/commits/17d609ce26a36e0b52917f277e2b50135e405649
This isn't really a bugfix because there is no bug in the codebase which is fixed right? But I agree its a sensible change.
Supporting it with importwallet is definitely something that needs to be done, ideally that should be done at the same time because they're mirror functions. But this doesn't break compatibility with the current importwallet so it should be ok to leave it for a future PR.
I think it's a bugfix because without it (and another fix to importwallet), dump/import will produce a wallet missing the key metadata. Isn't the goal of these RPCs to produce the same wallet?
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--174a7506f384e20aa4161008e828411d-->
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
This has been fixed as part of #14021 (not just for importmulti):
<img width="1099" alt="schermafbeelding 2019-02-15 om 16 03 23" src="https://user-images.githubusercontent.com/10217/52864874-75298e80-313b-11e9-97f4-8630694c1fa7.png">
It could still be useful to switch over to inferred descriptors, so we also get the origin info.
Just noticed that it's a seperate field now, but sill in the comment section, so we could move it to the left.
Rebased
859 | } else {
860 | file << "change=1";
861 | }
862 | - file << strprintf(" # addr=%s%s\n", strAddr, (pwallet->mapKeyMetadata[keyid].has_key_origin ? " hdkeypath="+WriteHDKeypath(pwallet->mapKeyMetadata[keyid].key_origin.path) : ""));
863 | + if (meta.has_key_origin) {
864 | + file << " hdkeypath=" + WriteHDKeypath(meta.key_origin.path);
We should also write out the master fingerprint here too (part of key_origin). I think instead of a separate field for that, we could instead write that in the same way descriptors and psbt do key origin information, i.e. fingerprint instead of m in the path.
Concept ACK
Concept ACK
Will try this today. Wallet with metadata is obviously better than wallet missing the key metadata.
This PR will complete 1337 days next week
Compiled and tried in POP!_OS with a new wallet (legacy / testnet). Diff for the dump files: https://ghostbin.com/paste/L2SXs. Observed the below things when comparing dump files for Master and PR branch:
hdseedid added for reserve=1 key type-cPUphC3iKWVx5HVcYimYKjvL1xn6uSHS2HKZdoLoKM1RzQkihNiD 2021-07-22T14:38:59Z reserve=1 # addr=tb1qp7m7nzhp9c4z7069m9rvrpp6tk6g4hqpj07t9l hdkeypath=m/0'/0'/8'
+cPUphC3iKWVx5HVcYimYKjvL1xn6uSHS2HKZdoLoKM1RzQkihNiD 2021-07-22T14:38:59Z reserve=1 hdkeypath=m/0'/0'/8' hdseedid=b01cf0b04e2799dab0a3658d7b59791a02c5ec86 # addr=tb1qp7m7nzhp9c4z7069m9rvrpp6tk6g4hqpj07t9l
hd master keycUEM9SuAS9z5z2bdYJhiwsmtCsq1UAwkP4nEv8i3BGK2SANwP51N 2021-07-22T14:38:59Z hdseed=1 # addr=tb1qsmkv2qs609vhhrt95wcd4xf8f6c0q89sag6fm2
script=1 key type00143802740190cd3720db8d1f06f4a32f6bafc7ffad 0 script=1 # addr=2MsFRrsqi61GSNEiQKwKUFGNmzbzAevUqE7
I think commits should be squashed.
Totally agree with prayank23: Wallet with metadata is obviously better than wallet missing the key metadata
This tests failed on my env though. Is it just me?
feature_backwards_compatibility.py --legacy-wallet | ✖ Failed | 1 s
feature_taproot.py --previous_release | ✖ Failed | 1 s
mempool_compatibility.py | ✖ Failed | 1 s
rpc_createmultisig.py --legacy-wallet | ✖ Failed | 103 s
rpc_signrawtransaction.py --descriptors | ✖ Failed | 105 s
wallet_upgradewallet.py --legacy-wallet | ✖ Failed | 1 s
This is exactly how I fetched the branch, compiled the binnaries and ran the tests.
git fetch core
git fetch core pull/11803/merge:pr11803
git switch pr11803
./autogen.sh
./configure -q --without-gui
make clean > /dev/null
make -j 4
python3 test/functional/test_runner.py
Checked my HEAD commit within my local PR copy and I'm getting 8642fbd04ce670cb76657580990d4073e41b0fe1 which differs from the last commit I see on the commit tab here, am I doing something wrong?
Tested on master for legacy wallets:
I get an extended private masterkey
Then a list of (private key, address, hdkeypath); although very out of order. Somewhere in there, is the hdseed
Master for descriptor wallets:
This type of wallet does not support this command (code -4)
Tested on 563dda4b52aca970189b757b7a86615adc442608:
Legacy:
Extended private master key.
Then list of (private key, hdkeypath, hdseedid, address). Changes are address is moved to the end of the list, and addition of hdseedid. The keys are still out of order, and the hdseed is also still randomly in the list.
Descriptor:
Unable to create descriptor wallet (either through the GUI or console), so unable to test.
Possible improvements?:
Work with descriptors
Maybe I was thinking of listdescriptors
<!--cf906140f33d8803c4a75a2196329ecb-->
🐙 This pull request conflicts with the target branch and needs rebase.
<sub>Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft".</sub>
<!--13523179cfe9479db18ec6c5d236f789-->There hasn't been much activity lately and the patch still needs rebase. What is the status here?
Closing this as it has not had any activity in a while. If you are interested in continuing work on this, please leave a comment so that it can be reopened.