Awesome multisig PR labyrinth guide

[Sjors]

@ryanofsky recently suggested that I should write an overview of how the various pull requests spread over different repositories relate to some bigger picture view.

See the multisig tutorial for how things currently work.

I typically have the following future multisig wallet in mind to guide my thinking:

1. a computer running Bitcoin Core holding one master key (key 1)
2. one or more hardware wallets with additional keys, via HWI (keys 2 ... n)
3. taproot keypath using n-of-n MuSig2
4. a fallback with fewer keys after some time elapsed
5. a GUI wizard to set this up (simple Python command line tool until then)

The descriptors for this could be hand crafted, but it would be nice to have:
6. Miniscript compiler that can generate this

What's Missing?

• Taproot support for external signers:
  • psbt: Taproot fields for PSBT #22558 (PSBT fields)
  • Add external signer taproot support  #23578 (External signer support)
• Timelock support for descriptors: this will be added along with full MiniScript support in Miniscript support in Output Descriptors #24148 & Signing support for Miniscript Descriptors #24149 (@darosior).
• Ability to handle descriptors for which we have 1-of-N keys. Descriptor wallets currently expect the wallet to be either watch-only and have no keys, or to have all the keys.
  • wallet: Add createwalletdescriptor and gethdkeys RPCs for adding new automatically generated descriptors #29130 makes it possible to create a wallet with a seed, but without any descriptors.
  • The user would grab an xpub from it (rpc: add path to gethdkey #22341,wallet: derivehdkey RPC to get xpub at arbitrary path #32784) to construct a multisig descriptor and then import that.
    • wallet: Add createwalletdescriptor and gethdkeys RPCs for adding new automatically generated descriptors #29130 added gethdkeys, helpful but doesn't support arbitrary derivation paths
• MuSig2 setup and signing support, which requires:
  • a BIP to specify new PSBT fields (tracked in MuSig2 support #23326)
  • psbt: MuSig2 Fields #31247
  • Bitcoin Core MuSig2 support: wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys #29675
  • At least one other (hardware) wallet to support it
    • Ledger app added support in 2025
    • ColdCard added support in 2026
  • HWI changes:
    • MuSig2 bitcoin-core/HWI#794
    • more thorough (draft) re-implementation: MuSig2 Sjors/async-hwi#2
• a simple Python setup wizard
  • right now Specter Desktop is by far the easiest way to setup a multisig wallet. But it's a huge dependency (including a bunch of NPM packages for their web interface). A simple Python script in contrib/ could call HWI to get a list of signers, ask what threshold to use, call createwallet to generate a blank wallet, fetch an xpub from it, and then call importdescriptors.
  • the script could use BIP 129 / BSMS (perhaps initially without encryption)
  • Specter doesn't set the external_signer wallet flag, so I have a trivial PR to do that manually: wallet: allow toggling external_signer flag #21928 (up for grabs)
• a GUI setup wizard: once we have an established work flow, we would implement that in the GUI

Misc

I have a PR that improves address display handling on the device:

• Improve display address handling for external signer #24313

Even better would be if we had a feature to ask the wallet for a signature to prove it has the private key (without passing that information to the outside world of course, see #24186). This requires BIP-322 support on our end (#24058), at least one hardware wallet to support it, and a new HWI signmessage command. Perhaps this can later be expanded to allow your device to prove that it (still) has the keys it needs as a co-signer.

Miniscript compilers currently doesn't support Taproot (e.g. to find the optimal tree structure), but I'm assuming you can still hand craft a leaf containing MiniScript.

[jonatack]

Thanks @Sjors, this is very helpful.

[laanwj]

Thanks! It's definitely good to have an umbrella issue here, how to get to the point where it's more or less easy to do multisig with bitcoin core.

[fanquake]

we would just add support new commands in the external signer command interface

Can you elaborate on your longer term plans for external signing / Boost Process.

Process is currently relatively poorly maintained; bugs are remaining unfixed for multiple Boost releases, the code and issue tracking is confusingly spread across multiple repositories (which have different versions of the code), no recent "modernization" (i.e no option use std::filesystme over boost::filesystem, like other Boost modules, which is why we no-longer support external signing on Windows). It's inclusion in our project is also a downside to our Boost consolidation / removal, i.e #24742.

If we continue to use it going forward, I think we need some sort of plan, addressing the above, rather than leaving it ignored while start accumulating workarounds in our own code to support it, and it's presence potentially blocks other goals.

Happy to split this out into a separate issue for discussion.

[Sjors]

Can you elaborate on your longer term plans for external signing / Boost Process.

Ideally replace it, but I have no idea with what. That hasn't changed since 2019. In the original PR #15382 (comment) Garzik pointed an alternative from a 2016 blog post. Interesting that repo does have some ongoing development: https://github.com/arun11299/cpp-subprocess

It doesn't support Windows (well) at the moment, but that might be acceptable since we already (temporally) Windows support anyway.

Happy to split this out into a separate issue for discussion.

Indeed seems better to have a separate issue. Swapping out the implementation of RunCommandParseJSON should have no impact on the rest of the architecture.

[Rspigler]

I too had some concerns with one of the original PRs (#21935 (comment)) re: external signers. Revisiting this I think could be good. I typically build with ./configure --disable-external-signer

That being said, my main goal is setting up (offline) multisig with Bitcoin Core, and I think it is many other people's goals to set up a wallet as you described in the OP - so thank you for setting up this umbrella issue Sjors! We are getting closer and closer to the final goal!

I think some other PRs that could be good to add to the above tasklist would be:

For Taproot support for external signers: (Besides the already linked #22558 in the OP):

• Add external signer taproot support  #23578
  There's also an issue created in HWI repo to track Taproot support:
• Taproot support bitcoin-core/HWI#501

Additional Miniscript PRs:

• Miniscript integration follow-ups #24860
• Miniscript corpus for descriptor_parse bitcoin-core/qa-assets#86
• Miniscript updates bitcoin-core/qa-assets#89
• miniscript: avoid wasteful computation, prevent memory blowup when fuzzing #25540
• Initial corpus for the miniscript_random target bitcoin-core/qa-assets#87

Descriptors

• descriptors: Be able to specify change and receiving in a single descriptor string #22838
• Descriptor unit tests and simplifications #24361
• descriptor_parse: extend coverage with Miniscript Descriptors inputs bitcoin-core/qa-assets#92

The GUI probably should be built with the new QML based fork? (https://github.com/bitcoin-core/gui-qml) @jarolrod @hebasto @Bosch-0

GUI:

• QR Code scanner #9913 QR Code scanner bitcoin-core/gui#670
  Possibly out of scope (but nice to have):
• Point out position of invalid characters in Bech32 addresses bitcoin-core/gui#537
• Warn when sending to already-used Bitcoin addresses bitcoin-core/gui#562

BIPs to be supported:

• https://github.com/bitcoin/bips/blob/master/bip-0087.mediawiki
  BIP 87 Is fulfilled by rpc, wallet: addhdseed, infer seed when importing descriptor with xpub  #23544
• https://github.com/bitcoin/bips/blob/master/bip-0129.mediawiki

I had set a $1,500 bounty for a GUI in Bitcoin Core that allows for the setting up of an (offline) multisignature wallet (here: #21071). Since then, there's been further work and standardization on this project. I am raising this bounty to $10,000, to be paid out in bitcoin. Payments will be made in part as individual tasklists are completed; to be divided up to developers who worked on the code and helped review it; at my discretion. This bounty update overrules and succeeds completely the original $1,500 bounty.

Bounty_Signed.txt

Also:

Addition:

• The GetExternalSigner changes that will be needed as discussed here

Also, ultimately:

• FROST BlockstreamResearch/secp256k1-zkp#138

So that threshold spends can be implemented privately

Edit: Damn formatting

[Bosch-0]

Thanks for putting this together Sjors, mulitisg in core would be great.

As @Rspigler mentioned, the QML project aims to be a more modern, user friendly version of the current GUI. Would be great for the GUI component of this effort was put towards the new QML framework. Imo putting a feature freeze on the widgets GUI and slowly moving towards QML as the project develops would prevent a lot of technical debt - something we don't have a lot of room for.

Tagging others on the project for visibility @GBKS @promag @Mogashni.

If you are looking ahead as to how an app like this would function, Nunchuk is a great example and imo easier to use than Specter. @hugohn

[Rspigler]

Also, ultimately:
- [ ] BlockstreamResearch/secp256k1-zkp#138

So that threshold spends can be implemented privately

Placed in my original post here

[Rspigler]

@Sjors Can you update the title to show the bounty? Thanks.

[Bosch-0]

Should also add this to https://bitcoinbounties.org/ 👀

[Rspigler]

Submitted!

[Sjors]

Don't know about changing the title. I'll add a link to that site to the PR description once its added.

[Rspigler]

@Sjors #22558 can be checked off 🥳