Bitcoin multisig explained

Multisig (multi-signature) means coins can only be spent when m of n keys sign, for example any 2 of 3. The keys are usually held on separate devices or by separate people, so losing one key or having one stolen doesn't lose the funds. Bitcoin has supported multisig since 2012 through P2SH, later through SegWit's P2WSH, and since Taproot also through Tapscript and MuSig2 aggregate keys.

Updated 2026-10-20 · 8 min read

What is multisig?

A normal single-signature wallet has one private key. Whoever holds it can spend. A multisig wallet replaces that with a policy written as m-of-n: there are n public keys, and any m matching signatures are needed to spend.

Common setups:

• 2-of-3: three keys, any two spend. One key can be lost or compromised without losing the funds.
• 2-of-2: two keys, both needed. Lightning channels, for example, are built on 2-of-2 outputs.
• 3-of-5 and larger: for companies, funds and families who want more people involved.

The key holders don't need to trust each other's devices. Each signs on its own, and the signatures are combined. The PSBT format exists largely to make that hand-off work between different wallets.

Why use multisig?

BIP 11, Gavin Andresen's 2011 proposal that made multisig a standard transaction type, gave two examples that still describe the main uses:

• Protection against a compromised device. A 2-of-2 between your computer and a separate service or device means malware on one can't spend alone.
• Escrow. A 2-of-3 between buyer, seller and a dispute agent lets any two settle the payment.

Today the most common reasons are removing the single point of failure in a backup, sharing control of company or family funds, and planning for inheritance. Multisig adds complexity in return: more devices, more backups, and a setup that every cosigner has to get right.

How multisig works on-chain

The original multisig script uses the OP_CHECKMULTISIG opcode:

2 <pubkey1> <pubkey2> <pubkey3> 3 OP_CHECKMULTISIG

To spend, you provide two signatures in the same order as their keys. Because of a bug in the original implementation, OP_CHECKMULTISIG removes one extra item from the stack, so every spend has to include a dummy value first. BIP 147 (NULLDUMMY), deployed together with SegWit, requires that dummy to be empty, closing a way for third parties to alter transactions.

A short history of multisig in the BIPs

Years are when each BIP was written. Consensus changes took effect later: P2SH in April 2012, SegWit in August 2017 and Taproot in November 2021.

P2SH: multisig behind a short address

Bare multisig put every public key in the output, so the sender paid for a large script and needed to know it. P2SH (BIP 16) changed this: the sender pays to a 20-byte hash, and the full script (the redeem script) is revealed only when spending. That gave multisig wallets ordinary-looking addresses starting with 3.

BIP 67: one address for one set of keys

The same keys can be listed in any order, and each order gives a different script and address. BIP 67, by Thomas Kerin, Jean-Pierre Rupp and Ruben de Vries, solves this by sorting the compressed public keys lexicographically before building the script. Every compliant wallet then derives the same address from the same keys and threshold. The sortedmulti() descriptor does exactly this.

SegWit multisig: P2WSH

SegWit (BIP 141) added P2WSH, which commits to the SHA-256 hash of the script and moves the signatures and script into the discounted witness. Addresses start with bc1q and are 62 characters long. BIP 141 notes two advantages over P2SH: the 32-byte hash is more resistant to collision attacks, and scripts can be up to 10,000 bytes instead of 520. In practice, BIP 383 lists the limits for multi(): 3 keys bare, 15 compressed keys inside P2SH, and 20 inside P2WSH.

During the transition, many wallets used P2SH-P2WSH (nested SegWit multisig), which wraps P2WSH inside a 3 address so older software could pay it.

Taproot multisig: three approaches

Taproot changed what multisig can look like. BIP 342 disables OP_CHECKMULTISIG inside Tapscript and adds OP_CHECKSIGADD, which supports batch verification, and lists several ways to build a k-of-n policy.

1. A script-path multisig (multi_a). A Tapscript leaf counts valid signatures:

<A> OP_CHECKSIG <B> OP_CHECKSIGADD <C> OP_CHECKSIGADD 2 OP_NUMEQUAL

BIP 387 describes this as multi_a() and sortedmulti_a() descriptors, with up to 999 keys. It works like classic multisig, but only the leaf that is used is revealed.

2. A key-path MuSig2 aggregate. MuSig2 (BIP 327), by Jonas Nick, Tim Ruffing and Elliott Jin, combines n public keys into one aggregate key. The signers cooperate over two communication rounds to produce a single ordinary Schnorr signature. On-chain, the output and the spend look exactly like single-signature Taproot, which is cheaper and more private. BIP 327 is explicit about the trade-off: MuSig2 is an n-of-n scheme, not a threshold scheme, so every signer must take part, and signing is interactive.

3. Both together. One design puts the most likely signing group in the key path as a MuSig2 aggregate, and the other combinations in script leaves, either as multi_a scripts or as one aggregate key per combination. Day-to-day spends use the cheap key path; the scripts are only revealed if a backup combination is needed. BIP 342 also mentions native Schnorr threshold signatures as a further option, at the cost of an interactive setup.

Supporting standards for MuSig2 include BIP 328 (deriving child keys from an aggregate key), BIP 390 (the musig() descriptor) and BIP 373 (PSBT fields for MuSig2 nonces and partial signatures). BIP 340 vs BIP 327 compares Schnorr signatures with MuSig2.

Which multisig type costs the least to spend?

Approximate size of one input spending a 2-of-3 multisig, assuming compressed keys and typical signature sizes:

The MuSig2 key path is the same size as a single-signature Taproot spend, because it is one key and one signature. The transaction size calculator lets you compare other setups.

Derivation paths for multisig

Each cosigner derives their multisig key from their own seed. Three BIPs define where:

• BIP 45: m/45'/cosigner_index/change/address_index, for P2SH only.
• BIP 48: m/48'/coin_type'/account'/script_type'/change/address_index, with script type 1' for P2SH-P2WSH and 2' for P2WSH. It documents a scheme several wallets already used, and uses BIP 67 key sorting.
• BIP 87: m/87'/coin_type'/account'/change/address_index, which leaves the script type to the output descriptor.

The derivation paths guide explains these levels in detail.

Setting up a multisig wallet safely

The riskiest moment in a multisig wallet's life is its creation. If an attacker can swap one of the xpubs during setup, every address the wallet generates may be partly theirs. BIP 129, Bitcoin Secure Multisig Setup (BSMS), by Hugo Nguyen, Peter Gray, Marko Bencun, Aaron Chen and Rodolfo Novak, defines a two-round process:

1. A Coordinator starts a session, chooses the policy (m, n and script type) and can share an encryption token with each Signer.
2. Each Signer sends a key record: its xpub with key origin, signed with the corresponding private key, optionally encrypted.
3. The Coordinator checks every record and signature, then builds a descriptor record: the descriptor, any path restrictions and the wallet's first address.
4. Each Signer checks that its own key is included, verifies the wallet's first address, and shows that address with m and n on its screen. The cosigners then compare these confirmations with each other.

On hardware signers, BIP 388 wallet policies serve a similar goal: the device shows the full policy on its own screen once, and afterwards can check that change outputs go back to the same multisig. Whatever tools you use, verify receive addresses on more than one signing device before depositing large amounts.

Spending from a multisig wallet

Spending uses PSBTs (BIP 174). One wallet creates the unsigned transaction and adds each input's script and the derivation paths of the keys involved. Each signer checks the transaction on its screen and adds its partial signature. A combiner merges the signed copies, and a finalizer assembles the witness once enough signatures are present. BIP 174 includes a worked 2-of-3 multisig example. For MuSig2, BIP 373 adds the extra round for nonces.

What you must back up for multisig recovery

This is where multisig differs most from single-signature wallets: seeds alone are not enough.

To spend from a 2-of-3 wallet, you need two signatures, but you also need to rebuild the exact script, and that needs all three public keys in the right form. If you have two seeds but have lost the third cosigner's xpub, you can't compute the addresses or the script, so you can't find or spend the coins.

A complete backup has:

1. Each seed phrase (and passphrase, if used), stored separately.
2. The wallet descriptor (or every cosigner's xpub with its fingerprint and derivation path), plus the threshold and script type. A wsh(sortedmulti(2,...)) descriptor captures all of this in one line.
3. A copy of the descriptor with every seed backup, so any m backups are enough on their own.
4. A test recovery, ideally with only m of the backups, before relying on the setup.

The descriptor doesn't let anyone spend, but it reveals the wallet's addresses and balance, so treat it as private.