Glossary / Developer reference
OP_CHECKMULTISIG
- Definition
- OP_CHECKMULTISIG verifies a group of signatures against a list of public keys in one step, and Taproot spends cannot use it at all because it blocks batch verification.
Specified in BIP-11.
Byte 0xae is what made shared custody possible: it pops a key count, that many public keys, a required-signature count, that many signatures, and then one item too many. Consensus allows up to 20 keys in a single call. It is the reason a company can require three of five officers to approve a withdrawal without any one of them being able to act alone.
How it works
Verification is a single pass down two lists rather than a search. The opcode walks the signatures in order and tries each against successive public keys, so the signatures have to appear in the same relative order as the keys they belong to. Present a valid 2-of-3 with the two signatures swapped and the script fails, which is a routine cause of confusion when people assemble multisig spends by hand.
The stack is left one item short, and always has been. The original implementation popped an extra element it never used, a bug that could not be removed without breaking every existing coin. Signers learned to push a throwaway item first, and BIP-147 closed the resulting malleability by requiring that item to be empty, from block 481,824 onward.
Cost accounting is where it bites. A bare call is charged as 20 signature operations regardless of how many keys are really in it, unless a small number opcode immediately precedes it, in which case the charge is that number. A block is limited to 80,000 units of signature operation cost, and relay policy allows at most 15 of them in a single pay-to-script-hash input. That policy number, not the opcode's own limit of 20, is the reason script addresses top out at fifteen cosigners.
Tapscript retired it outright. BIP-342 made the opcode and its verify variant fail on sight inside a Taproot leaf, because checking a batch of Schnorr signatures against a list in one operation defeats the batch verification that makes Schnorr worth having.
Where you see it
The 2-of-2 output that funds every Lightning channel uses OP_CHECKMULTISIG, which alone puts the opcode in a large fraction of the network's script spends. Corporate treasuries, escrow arrangements on older peer-to-peer marketplaces and exchange cold storage built before Taproot use it too, usually as a 2-of-3 inside a script hash.
Bare calls, where the keys sit directly in the output with no hash in front of them, are relay-standard for up to three keys and almost never used, because the sender pays for every key and the whole arrangement is public before a single coin moves. In 2014 that format briefly became a way to store files on the chain, which is part of why data storage arguments still surface whenever anyone touches relay policy.
If you are setting up shared custody now, your wallet will more likely produce a Taproot arrangement using the counted alternative, or a P2WSH script if compatibility matters more than fees.
OP_CHECKMULTISIG vs P2SH multisig
OP_CHECKMULTISIG is an instruction and P2SH multisig is a way of packaging it. The opcode says how a quorum is checked; the packaging says the quorum is hidden behind a hash and revealed at spend time. The same instruction can appear in a bare output with the keys in plain view, in a redeem script behind an address beginning with 3, or in a witness script behind a bc1q address, and the three differ enormously in cost and privacy while running identical verification logic. What you cannot do is use the instruction in a Taproot leaf, which is why modern quorums are built from a different opcode entirely.