TERM_DEF // MODULE_8_MULTISIG / OP_CHECKMULTISIG
OP_CHECKMULTISIG
OP_CHECKMULTISIG. Verify M-of-N signatures; requires a dummy OP_0 due to a historical bug.
OP_CHECKMULTISIG validates that at least M out of N provided signatures are valid for the corresponding public keys. It reads N public keys, M signatures, and the dummy element from the stack, then checks each signature against each key in order. A historical off-by-one bug requires an extra element (conventionally OP_0) to be on the stack before the signatures — it is silently consumed. fork/">BIP 147 mandated this dummy must be an empty array.
This page sits in the Module 8 — Multisig section — Vocabulary introduced in the Multisig module. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
OP_CHECKMULTISIG validates that at least M out of N provided signatures are valid for the corresponding public keys. It reads N public keys, M signatures, and the dummy element from the stack, then checks each signature against each key in order. A historical off-by-one bug requires an extra element (conventionally OP_0) to be on the stack before the signatures — it is silently consumed. fork/">BIP 147 mandated this dummy must be an empty array.
This page sits in the Module 8 — Multisig section — Vocabulary introduced in the Multisig module. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
WHAT_OP_CHECKMULTISIG_IS
OP_CHECKMULTISIG — at a glance
MODULE 8
OP_CHECKMULTISIG is a Bitcoin Script opcode in the SIG family. Its stack effect is
0 sig₁…sigₘ M pub₁…pubₙ N → 1 or 0. M-of-N multisig validation. Note the historical off-by-one bug requiring a leading OP_0. Verify M-of-N signatures; requires a dummy OP_0 due to a historical bug.OP_CHECKMULTISIG validates that at least M out of N provided signatures are valid for the corresponding public keys. It reads N public keys, M signatures, and the dummy element from the stack, then checks each signature against each key in order. A historical off-by-one bug requires an extra element (conventionally OP_0) to be on the stack before the signatures — it is silently consumed. BIP 147 mandated this dummy must be an empty array.
Why it exists
DESIGN
OP_CHECKMULTISIG exists because Spending requires proof that the holder of a private key authorised the spend — that proof is verified by a CHECKSIG-family opcode.
HOW_IT_WORKS
Mechanism
HOW IT WORKS
Every UTXO is locked by a scriptPubKey — the output's locking script. To spend it, you provide a scriptSig (or witness) containing data that satisfies the lock. The node concatenates them, runs the combined script on a stack machine, and accepts the spend if and only if execution finishes with a single truthy value on the stack. OP_CHECKMULTISIG contributes a specific stack effect within that process — opcodes either push, pop, copy, hash, branch, or verify, and they do so left-to-right deterministically.
1. The script is parsed into a sequence of opcodes and push-data items.
2. Execution starts with an empty stack and an empty alt-stack.
3. Each opcode runs in order — push opcodes add to the stack, others consume the top items and may push results.
4. When OP_CHECKMULTISIG is reached, it performs its specific stack effect (see below).
5. Final state: a single non-zero (truthy) value on top → the spend is authorised. Anything else (empty stack, false, error) → the script fails and the tx is rejected.
WORKED_EXAMPLE
OP_CHECKMULTISIG — stack effect + canonical use
EXAMPLE
Opcode : OP_CHECKMULTISIG
Family : SIG
Stack effect: 0 sig₁…sigₘ M pub₁…pubₙ N → 1 or 0
Behaviour : M-of-N multisig validation. Note the historical off-by-one bug requiring a leading OP_0.
Open /playground in another tab and search for OP_CHECKMULTISIG.
Drag the opcode in, watch the stack visualisation step through it
against any combination of inputs you choose.
KEY_PROPERTIES
FAMILY
Belongs to the SIG family of Script opcodes — siblings share validation rules and historical evolution.
STACK EFFECT
Exactly 0 sig₁…sigₘ M pub₁…pubₙ N → 1 or 0. Every full node enforces the same effect, byte-for-byte.
ACTIVE
Active on mainnet today; every spend that uses it is being validated by every full node.
CONSENSUS-CRITICAL
OP_CHECKMULTISIG's behaviour is consensus rule — a node implementing it differently would fork off the network.
COMMON_PITFALLS
Things that catch people out
PITFALLS
- Signature checking is the most expensive Script operation; SIGOP-limit consensus rules cap how many can appear per block.
- The infamous off-by-one bug: CHECKMULTISIG pops one extra item before reading signatures. Always include a leading OP_0 (or empty push) as the dummy.
TERMINOLOGY_INDEX
TERMINOLOGY
OP_CHECKMULTISIG
Verify M-of-N signatures; requires a dummy OP_0 due to a historical bug.