LearnBitcoin

Glossary

Multisig

A wallet setup where spending requires signatures from more than one key (M-of-N, such as 2-of-3), so no single key or key holder can move the funds alone.

Three keys. Any two sign. Lose one and you still spend. Steal one and you still can't.

Multisig is a wallet structure where the output requires multiple signatures to spend, not just one. The script encodes "M of N cosigners must sign" - you might have 3 cosigner keys (N=3) and require any 2 of them to sign for a spend to be valid (M=2). That's the classic 2-of-3.

The point is to remove the single-point-of-failure problem of a normal single-sig wallet. With one seed, anyone who finds or copies it can drain you. With 2-of-3 multisig spread across three locations or three devices, an attacker has to compromise two of the three keys, which is a much harder bar. The two don't have to fall at the same time. A key stolen months earlier still counts unless you move the funds to new keys first.

Common patterns:

  • 2-of-3 personal custody. One key on a hardware wallet at home, one with a custody service or in a safe deposit box, one with a trusted family member or attorney. Survives loss of any one. Steal one and you still can't spend. The sweet spot for serious personal holdings.
  • 3-of-5 for groups and companies. Survives loss of two, requires three to sign. The five keys can sit with different officers, in different offices, or in hardware security modules.
  • 2-of-2 Lightning channels. Every Lightning channel is technically a 2-of-2 multisig output between you and your channel partner. Most users never see this; the protocol just uses multisig under the hood for the channel's funding output.

Bitcoin has two ways to express multisig on-chain:

  • Classical multisig (OP_CHECKMULTISIG, pre-Taproot). Wrapped in P2SH or P2WSH. The script is visible on-chain when spent, so observers can see "this was a 2-of-3 spend." The opcode accepts up to 20 keys. P2SH tops out at 15 compressed keys because its whole script must fit in a single 520-byte data element; P2WSH carries the script in the witness, where that size limit does not apply, so it allows the full 20.
  • Taproot multisig (since Taproot activated in November 2021). In a script-path spend, Tapscript replaces OP_CHECKMULTISIG with OP_CHECKSIGADD, which lifts the 20-key cap. In a key-path spend, the cosigners share one combined public key, so the spend looks like any single-sig Taproot spend and observers can't tell it was multisig. MuSig2 key aggregation does this when all N sign. FROST does it for any M of N, though its Bitcoin spec is a draft BIP as of October 2026. A single signature also makes the spend smaller and cheaper.

The signing flow usually uses PSBT. One cosigner builds the transaction, signs their part, passes it to the next, who adds their signature, and so on until the threshold is met. With hardware wallets and coordination tools like Sparrow, Nunchuk, or Specter, this is straightforward but more involved than single-sig.

When to use multisig: when the value justifies the operational complexity. For small balances, a well-backed-up single-sig hardware wallet is more secure than a multisig you'll fumble. For amounts you can't afford to lose and won't move daily, multisig is the right answer.

Key takeaways

  • Spending requires M of N cosigner signatures (e.g., 2-of-3)
  • Eliminates the single-point-of-failure problem of a single seed
  • Standard pattern: each cosigner key on a different device, often in different locations

Corrected

  • Was: The entry said classical multisig is capped at 15 cosigners by the design of the OP_CHECKMULTISIG opcode, and that an attacker has to compromise two keys of a 2-of-3 at the same time.

    Now: The opcode accepts up to 20 keys. P2SH tops out at 15 compressed keys because its whole script has to fit in one 520-byte data element, P2WSH allows the full 20, and Taproot script paths use OP_CHECKSIGADD, which lifts the 20-key cap. A key stolen months earlier still counts toward the two unless the funds have moved to new keys. Details

Sources (8)

External references (3)

Related terms (12)