wallet: rpc to add automatically generated descriptors #25907
Conversation
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. ConflictsReviewers, 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. |
|
I would expect |
The wallet version isn't modified by this. Also this allows for much more granulated control of what is added. While this can be used for upgrading a wallet to support a new kind of descriptor, it's not strictly just an upgrade function as it can also be used on blank wallets and after rotating the hd key. So I didn't think it was appropriate for |
|
Concept ACK |
91dbc85 to
b6b99e0
Compare
|
The GUI receive address type dropdown is not updated after calling this. |
a07a8a0 to
f2c3389
Compare
2d96c52 to
d20948a
Compare
We often need to construct a CExtKey given an CExtPubKey and CKey, so implement a constructor that does that for us.
Best reviewed with `git show -w`
70a8266 to
29ce197
Compare
…ster The test creates a wallet on master, downgrades and encrypts the wallet. Then, it tries to open it again on master.
We will need access to a function that sets up a singular DescriptorSPKM, so refactor this out of the multiple DescriptorSPKM setup function.
29ce197 to
8123f93
Compare
|
Superseded by #29130 I don't think there's a reason to come back to this design, but the branch won't be deleted so we can reopen if desired. |
It is useful to have a RPC that can create and add the automatically generated descriptors (that are normally made during creation) to a wallet. This is especially useful when a new default descriptor has been implemented as it allows wallets created before that time to quickly and easily add that type of descriptor.
In particular, descriptor wallets created before Taproot was implemented can use the new
createwalletdescriptorRPC in order to get a Taproot descriptor.Furthermore, to keep the newly generated descriptor in line with the existing descriptors, this PR uses #26728 as it exposes a "wallet extended key" for us (in addition to upgrading wallets implemented prior to have a wallet xpub). The newly generated descriptors will use the "wallet extended key" stored in
CWalletthat PR adds.createwalletdescriptoris generic and so it can also be used with the other address types. Of course, it given the same wallet extended key, address type, and internal-ness, it will create the same descriptor. So some refactoring has been done in order to detect that the same descriptor is about to be created, and to avoid overwriting any existing descriptors.