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.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--006a51241073e994b41acfe9ec718e94-->
<!--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-->
No conflicts as of last run.
<!--5faf32d7da4f0f540f40219e4f7537a3-->
Possible typos and grammar issues:
complaint hardware wallets -> compliant hardware wallets [“complaint” is the wrong word here; “compliant” is clearly intended]<sup>2026-10-06 16:20:35</sup>
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.
Following the Python wizard #36325, which exercises the actual setup flow, the contract for createMultisigDescriptor() is now concrete and has real consumers: the Python utility (#36325), the GUI, and potentially the createmultisig RPC.
It becomes a function that constructs ranged, multipath descriptors for bech32 and bech32m, as well as the unranged plain-key case createmultisig builds today.
This fits the multisig setup process better because the descriptor is built up front and becomes the source of truth, and bech32m falls out naturally. By contrast, createmultisig recovers its descriptor with InferDescriptor, which only sees the script: it always produces multi(...), since nothing in the script records that the keys were sorted, and its inputs are raw public keys, so there are no origins or ranges to express.
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 1 is #36325. CreateMultisigDescriptor() would be the first change step 2 asks for.
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.
In general it is, we want the GUI to be calling a utility function like this one to construct the descriptors for import.
We already have a createmultisig RPC, and it should be modernized to produce descriptors.
1.introduce a Python utility that helps the user construct and import a multisig descriptor
I think this is entirely unnecessary. The RPC already exists, it should be modernized and refactored such that the GUI can use it too.
createmultisig can delegate to CreateMultisigDescriptor() for key expressions and bech32m, while keeping its existing contract for hex pubkeys unchanged. That gives the GUI and the RPC one assembly function.
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.
Covered by unit tests in descriptor_tests.cpp.
Part of the multisig wizard backend tracked in #35645.
For taproot the key path is a MuSig2 aggregate of all n keys
rather than a fixed or variable NUMS point: it cannot bypass the
policy, since spending that way needs every signer, and it avoids
the fingerprinting that a well-known internal key would cause.
keys must be bare because derivation before aggregation cannot be
expressed in a BIP 388 policy