This is an unsafe proof of concept. It runs on a test network, in a simulator, with money that is worth nothing. It is a look at where multisig is going, not something to move your savings into. Nothing here has been audited.
What multisig is for, and what it costs you
A multisig wallet needs more than one key to spend. Two of three, three of five, whatever you choose. One key can be lost, one device can break, one person can be coerced, and the money is still safe. It is the best answer we have to holding bitcoin without a single point of failure.
It has always come with a bill attached. A classic multisig announces itself. Every time you spend, the chain records the whole arrangement: that it was a multisig, how many keys exist, how many were needed, and a public key for each one. That record is permanent and anyone can read it. It tells a thief that this address is worth studying, it tells a chain analyst how you organise your money, and it never goes away.
You also pay for it in fees, every spend, forever, because several signatures and the script describing them all have to go on chain.
What MuSig2 changes
MuSig2 (BIP-327) lets several keys produce a single signature. Not several signatures collected together: one signature, mathematically indistinguishable from one made by one key.
So the chain sees an ordinary single-key wallet. One key, one 64-byte signature. It cannot tell your 2-of-3 from a phone wallet, and neither can anyone reading the chain later. That is the privacy unlock, and it is a big one: your security arrangement stops being public information.
The fee saving comes with it. This spend was 111 vB, the same as a single-key payment, where a classic 2-of-3 would be roughly twice that.
This part is not new and we did not invent it. Nunchuk shipped a taproot MuSig2 multisig in beta in December 2024. Ledger added MuSig2 signing to its Bitcoin app in April 2025. BitGo has run it in production since 2023. You can use MuSig2 today.
World first
An airgapped MuSig2 multisig
Proved · Bitsaga Signet, blocks 109068 and 109071
The part nobody has solved
MuSig2 signing happens in two rounds. Round one: every signer commits to a random number (a nonce). Round two: every signer signs. Between the two, each signer is holding a secret, and that secret has one absolute rule. Use it for two different signatures and anyone who sees both can work out your private key and take everything.
Because of that rule, every implementation keeps the secret in memory and nowhere else. Writing it down is worse than useless: a copy of the file is a copy of the secret, and no software can tell a copy from the original.
Which leaves a signer that cannot be switched off. Not "should not". Cannot. Pull the power between the two rounds and the signing is dead, and you start again from the beginning. The Bitcoin Core discussion of MuSig2 wallet support says it plainly: every machine involved has to keep running with the wallet loaded throughout, and for keys kept in different places that means leaving a node running unattended in each one.
So in practice a MuSig2 spend means two visits to every signer, with the device kept alive in between. A classic multisig needs one visit each and the device can be off the rest of the time. That is a real step backwards, and it is the reason MuSig2 has not swept multisig away already.
MuSig2 today
MuSig2 on a card
What we did
We gave the secret (the nonce) to a smartcard.
A card can do the thing software cannot: hand something back exactly once and refuse ever after. So the secret leaves the signer sealed, travels inside the transaction, and the card opens it in round two. Copy the transaction, copy the card's backup, copy the whole disk: none of it produces a second signature, because the card has already said no.
The signer can now be switched off between the rounds. Put it in a drawer, come back tomorrow, finish the signature.
And once the card is making these secrets anyway, it can make a few extra and leave them in the transaction on its way out. Round one does not depend on the transaction, so it can be done before the transaction exists. The next spend arrives with round one already finished, and each signer only has to sign.
Side by side
| Classic multisig | MuSig2 today | MuSig2 on a card | |
|---|---|---|---|
| What the chain sees | The whole policy, forever | A single-key wallet | A single-key wallet |
| Size of this spend | Roughly 200 vB | 111 vB | 111 vB |
| Visits per signer | 1 | 2 | 1, after the first spend |
| Signer may be switched off | Yes | No | Yes |
| Signers must be available together | No | In effect, yes | No |
| A copied backup can be replayed | Not applicable | Not applicable | No, the card refuses |
The "1, after the first spend" needs a word of honesty. The first spend of a wallet has no secrets in reserve yet, so it costs three visits across two signers. Every spend after that costs two, one each, which is the floor: two people have to sign, so two visits is as low as it goes.
What it looks like
Three cosigners, each a different seed loaded on the device and exported. Two of the three also keep their seed on their own smartcard, and those are the two that can be switched off mid-signing.
Both spends, on chain
On Bitsaga Signet, a private test network. The coins are not real. Each link is a proof you can check against the chain yourself, header and merkle branch included, without trusting this page.
| Spend | Visits | Transaction | Block | Size |
|---|---|---|---|---|
| First | 3 | dcfabb9ad664…3bfabf39 | 109068 | 111 vB |
| Second | 2 | 769624fae62a…078ac4a8 | 109071 | 111 vB |
What is standard here
Almost all of it. None of the following is our invention, and every one of them is a published specification other people wrote:
- BIP-327, MuSig2 itself: how several keys make one signature.
- BIP-373: how the participants, the public commitments and the partial signatures travel in a transaction.
- BIP-390: the
musig()descriptor that describes the wallet. - BIP-328: how the shared key is derived from the individual ones.
- BIP-341, taproot, and BIP-174, the transaction format everything moves in.
- Bitcoin Core, unmodified, can combine every round of this. We checked that rather than assuming it.
What is not
- The secret goes on a smartcard that opens it once. BIP-373 assumes a signer keeps it in memory between the rounds. A signer that powers off cannot, so ours travels sealed and the card is the only thing that can unseal it.
- Two private fields in the transaction to carry it. BIP-174 sets aside
0xFCfor exactly this, so it is a private extension rather than a change to the format. Bitcoin Core carries both through untouched, which we also checked. - Secrets prepared before there is anything to sign. Not a new idea in itself: FROST has a preprocessing stage, and Cryptnox sell a card that makes these secrets in advance. What is here is pairing that with a card that will not open the same secret twice, so every signer is allowed to lose power, not just one.
That last distinction matters. BIP-327 already has a way for exactly one signer, usually the hardware wallet, to avoid holding a secret between rounds. It does not extend to the others.
Where the code is
The firmware is a fork of SeedSigner: bitsagarob/seedsigner. The browser simulator, the coordinator that builds the transactions and the checks against Bitcoin Core are in bitsagarob/seedsigner-simulator. Everything on this page was produced by an end-to-end test in that repository, which builds the wallet, takes coins from a faucet and spends them back, driving the simulated device one button press at a time.
The honest limits
- Unsafe by design, for now. A proof of concept on a test network. Not audited, not reviewed, not for real money.
- Only a signer with a card can be switched off. One without keeps its secret in memory like everyone else, and costs the extra visit every time.
- The saving is per signer. If only one of the two has a secret in reserve, only that one saves a visit.
- A prepared secret is used up when it is handed out, not when a signature comes back, because an abandoned transaction has still published it. Abandoning spends works through the reserve.
- In this demo the reserve lives in a browser tab. Reload the page and it is gone. A real coordinator would keep it; this one does not yet.
- The device and the cards are simulated. Real firmware, real cryptography, a real chain, simulated hardware. Proving it on a physical device is the next step.