-
Notifications
You must be signed in to change notification settings - Fork 37.7k
rpc: add path to gethdkey #22341
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rpc: add path to gethdkey #22341
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. |
Thanks for working on this! |
Thanks so much for continuing to work on this! Love the use of BIP 87 :)
Yes, important to check the xpub also, not just the fingerprint, which is easy to spoof
I agree that the above 3 encompasses all use cases/needs for Bitcoin Core being a coordinator and a signer in a multisig setup.
Can you explain this to me more? As for the blank wallets, why do we need to be working from blank wallets, and if xprivs are derived from seeds, how can a blank wallet have a seed? |
It depends on how we want to define If a wallet has a seed and you call |
Thank you, makes a lot of sense! And what about sibling descriptors? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review ACK 1ff7a25
Concept ACK I'll be sure to update the tests/docs in #22067 to use this when this PR gets merged |
Concept ACK |
1 similar comment
Concept ACK |
1ff7a25
to
bfdf045
Compare
I managed to reconstruct the master extended private key, by combining the key part of the descriptor |
Best reviewed with `git show -w`
…ster The test creates a wallet on master, downgrades and encrypts the wallet. Then, it tries to open it again on master.
60361ee
to
aebbcd4
Compare
I plan to re-work this on top of #29130 with a similar interface to Initially I'll make a separate PR. If #26728 is closed in favor of the new approach in #29130 then this PR can be closed too. |
It seems like you could just rebase this on top of #29130, since the description of the PR and new commits aren't going to change that much, they will just be based on #29130 instead of #26728. Either way seems fine, though. |
@ryanofsky building on #29130 introduces a new argument to specify which master key you intend to use. |
🐙 This pull request conflicts with the target branch and needs rebase. |
This seems more involved than a simple rebase. #29130 changes I probably won't have time for this in the near future, so I'm closing this as up for grabs. |
…k to closed PR 3cd24aa doc: remove obsolete mention and link to closed PR (Marnix) Pull request description: Remove the mention and link as the PR (#22341) is closed and the description is wrong/outdated anyway. ACKs for top commit: BrandonOdiwuor: ACK 3cd24aa tdb3: ACK 3cd24aa Tree-SHA512: 5cd97029337f0cdfe81b6be9401adc4fe51ae2868f8fcadcb03828531a38380a587c32840850a924b6428f62df7d20a1e16ef7414d4078e7bb2c4e359b1fae40
Depends on #26728.
This PR expands the wallet RPC
gethdkey
introduced in #26728. It takes a BIP32 path as argument and returns the xpub, along with the master key fingerprint.To test this PR:
getxpub m/86h/0h/0h
listdescriptors
, compare the xpub in thetr()
descriptor with the previous stepBigger picture
This paves the way for using Bitcoin Core as one signer in a multisig setup. It simplifies the proposed flow in #22067.
The eventual flow would be:
active
, so they don't get used when callinggetnewaddress
).getxpub m/87h/0h/0h
(as suggested in BIP 87)importdescriptors
which will allow the import if its own fingerprint is recognized (and after checking the xpub)getnewaddress
,send
andwalletprocesspsbt
(and their GUI equivalents)This PR makes step (2) possible.
Step (1) would require a followup, because blank wallets currently can't have a seed. Step 4 would also require a followup, so that
importdescriptors
treats anxpub
as if it was anxpriv
, after checking that it can derive the xpub from the seed (that matches the fingerprint)On the GUI side a wizard could perform the above steps and guide the user, where they either: