LearnBitcoin

Glossary

M-of-n

A generic way to denote multisig, requiring M signatures out of N total possible signers (e.g., 2-of-3).

M-of-N is the common shorthand for threshold multisig: any M signatures out of N total cosigners are sufficient to spend. BIP 11, written in 2011, used the same notation when it proposed making M-of-N multisig with up to three keys a "standard" transaction, one that nodes relay and miners include in blocks. Version 0.6.0 of the Bitcoin software (now Bitcoin Core) put that into effect in March 2012. M and N tune two independent dials:

  • M is the security threshold. Larger M means more cosigners must agree, harder to steal.
  • N - M is the redundancy. The wallet survives loss of up to N - M cosigners without losing access.

Common configurations:

  • 2-of-3: the personal-custody sweet spot. One key with you, one with a trusted backup location, one with a third party (lawyer, friend, custody service). Survives loss of any one. Steal one and you can't spend; steal two and you can.
  • 3-of-5: for groups and companies where more people should have a say. Survives loss of two, requires three to spend.
  • 4-of-7 or higher: large federations and high-stakes custody. Blockstream's 2020 whitepaper for the Liquid sidechain says the bitcoin backing Liquid is locked in an 11-of-15 multisig. Its 15 keys are held by 15 functionaries, which the whitepaper calls "watchmen" when they sign withdrawals from Liquid back to Bitcoin. Each functionary is run by one member of the Liquid Federation, which had 87 members as of May 2026.

Pre-Taproot multisig uses OP_CHECKMULTISIG, which accepts at most 20 keys. In P2SH it tops out at 15 compressed keys, because the whole script has to fit in a single 520-byte data element. P2WSH avoids that limit and allows the full 20. Taproot script-path spends use OP_CHECKSIGADD instead, which allows far more keys. Bitcoin Core's multi_a descriptor (BIP 387) supports up to 999.

Taproot key-path spends can make the M-of-N structure invisible on-chain entirely. MuSig2 does this when all N cosigners sign. FROST does it for any M of N; its Bitcoin spec is still a draft BIP as of October 2026.

The right choice is rarely "more cosigners." Each cosigner is a real human or device, and each is a failure mode: lost device, dead person, forgotten passphrase, miscommunication during signing. Most retail users do better with 2-of-3 than with anything fancier. For a company or group, 3-of-5 is a reasonable place to start; go higher only for a specific reason, such as more officers who must approve each spend.

Key takeaways

  • General term for threshold signature setups
  • Allows flexible security policies based on participants' needs
  • Practical for corporate, family, or co-managed funds

Corrected

  • Was: The entry said legacy multisig hard-caps at 15 cosigners because of the OP_CHECKMULTISIG opcode, and that MuSig2 or FROST aggregation hides any M-of-N structure on chain.

    Now: The opcode accepts up to 20 keys, the 15-key cap applies only inside P2SH, P2WSH allows 20, and Bitcoin Core's Taproot multi_a descriptor allows up to 999. MuSig2 hides the structure only when all N cosigners sign, and FROST, which covers any M of N, is still a draft BIP as of October 2026. Details

Sources (11)

Related terms (10)

Published . Revised . One correction logged for this page.

Edit this page on GitHub