P2SH multisig

A 2-of-3 redeem script is 105 bytes: an opcode for 2, three 33-byte compressed keys with their push prefixes, an opcode for 3, and OP_CHECKMULTISIG. Spending one input costs roughly 297 vbytes, about triple a native SegWit single-key input. This was the standard shared-custody arrangement from 2012 until witness data got its discount.

How it works

A P2SH multisig redeem script lists the quorum directly: the required signature count, then every participating public key, then the total key count, then OP_CHECKMULTISIG. Nobody sees it while the coins sit unspent, because the output commits only to its 20-byte hash.

The fifteen-key ceiling is arithmetic, not policy invention. Fifteen compressed keys at 34 bytes each, counting the push prefix, come to 510 bytes; adding the two count opcodes and OP_CHECKMULTISIG reaches 513, which fits inside the 520-byte limit on a single stack element. A sixteenth key does not. Bitcoin's consensus rules allow OP_CHECKMULTISIG up to 20 keys, but a P2SH redeem script physically cannot carry that many.

There is an old quirk in the spending path. OP_CHECKMULTISIG pops one more item off the stack than it uses, a bug from the original implementation that was never removable without a hard fork. Signers work around it by pushing a dummy element first, and BIP-147 made that element required to be empty, which activated alongside SegWit at block 481,824. A completed input therefore reads: empty push, signature, signature, redeem script.

Where you see it

Corporate treasuries, inheritance arrangements and exchange cold storage built between 2013 and 2018 are largely P2SH multisig. Escrow on older peer-to-peer marketplaces used 2-of-3 with the platform holding the third key, which is how a dispute could be settled without either trader controlling the coins outright.

The backup requirement catches people out. Each cosigner needs the extended public keys of every other cosigner, or a descriptor recording them, because the redeem script cannot be reconstructed from one seed phrase. Holding two of three private keys and none of the public keys leaves you unable to spend. Write the descriptor down with the seed backups, and test a recovery before the arrangement holds anything you care about.

New quorums today are built with P2WSH or Taproot instead, because the same policy costs far less to spend and is not capped at fifteen keys. Existing P2SH vaults still work exactly as before, and there is no forced migration.

P2SH multisig vs Multisig

Multisig is the policy and P2SH multisig is one way of writing it down. The same 2-of-3 requirement can live in a bare multisig output from bitcoin's earliest rules, in a P2SH redeem script, in a P2WSH witness script, or, under Taproot, inside a single aggregated key that spends like an ordinary payment and reveals no quorum at all. Choosing P2SH is a decision about fees, the fifteen-key ceiling, and the fact that your whole signing arrangement becomes public knowledge the first time you move coins.