The multisig setup flows need to assemble a descriptor from collected cosigner keys without hand-crafting the descriptor string, which today means bash interpolation with no validation of key forms, duplicates, or threshold.
CreateMultisigDescriptor() takes a threshold, a list of key expressions with origin info, and an output type, and returns a ranged, multipath wsh(sortedmulti(...)) descriptor with checksum.
Part of the multisig wizard tracking issue #35645.
The multisig setup flows need to assemble a descriptor from collected
cosigner keys without hand-crafting the descriptor string, which today
means bash interpolation with no validation of key forms, duplicates, or
threshold.
CreateMultisigDescriptor() takes a threshold, a list of key expressions
with origin info, and an output type, and returns a ranged, multipath
wsh(sortedmulti(...)) descriptor with checksum.
Parsing is done by the existing internal ParsePubkey(); the setup-specific
policy is applied here on top of it. Private key, missing origin
info, keys that already carry a derivation, and duplicate keys are all
rejected. The /<0;1>/* suffix is appended internally, so callers supply
bare account xpubs only.
P2TR is deferred pending a decision on the taproot internal key. Other
output types return an error.
Covered by unit tests in descriptor_tests.cpp.
Part of the multisig wizard backend tracked in #35645.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--006a51241073e994b41acfe9ec718e94-->
For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/36143.
<!--021abf342d371248e50ceaed478a90ca-->
See the guideline and AI policy for information on the review process.
| Type | Reviewers |
|---|---|
| Concept NACK | Sjors |
If your review is incorrectly listed, please copy-paste <code><!--meta-tag:bot-skip--></code> into the comment that the bot should ignore.
<!--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.
<!--5faf32d7da4f0f540f40219e4f7537a3-->
Hardcodes `xpub661MyMwAqRbcEYS8w7XLSVeEsBXy79zSzH1J8vCdxAZnin`
`gWLdN3zgtU6QgnecKFpJFPpdzxKrwoaZoV44qAJewsc4kX9vGaCaBExuvJH57`
as unspendable internal key since an xpub will work better with
hardware signers than an xonly NUMS_H point.
Although using a hardcoded internal key raises the possibility of
fingerprinting
Concept NACK, unless this is part of a larger end-to-end implementation (with some buy-in), like a GUI or RPC that actually uses this new method.
But I also think that's premature. Wallet setup is a one-off thing, and it's not obvious what the best approach is. A Python utility is more flexible. A full c++ implementation is also likely to need a huge stack of commits, see e.g. https://github.com/Sjors/bitcoin/pull/91 which only implements spending from an existing multisig wallet.
So I think the better sequence is:
1.introduce a Python utility that helps the user construct and import a multisig descriptor 2. gradually improve / add RPC methods to simplify that utility and eventually make it unnecessary
Step (2) is where changes like this may be useful.
So I think the better sequence is:
1.introduce a Python utility that helps the user construct and import a multisig descriptor 2. gradually improve / add RPC methods to simplify that utility and eventually make it unnecessary
That sequencing makes sense. Would exposing this via an RPC in the same PR address the "nothing uses it" concern, or do you specifically want the Python flow to exist first so the RPC surface is shaped by what that flow needs?
Would exposing this via an RPC in the same PR address the "nothing uses it" concern
Yes, but.
do you specifically want the Python flow to exist first so the RPC surface is shaped by what that flow needs?
I think that's the better yes.