TERM_DEF // SCRIPT_AUTHORIZATION / OP_CHECKMULTISIG
OP_CHECKMULTISIG
OP_CHECKMULTISIG. Verifies M of N signatures against N pubkeys; consumes an extra dummy stack item due to a 2010-era bug.
This page sits in the Script & Authorization section — The stack VM that decides whether a UTXO is spendable — opcodes, templates, and modern script trees. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
This page sits in the Script & Authorization section — The stack VM that decides whether a UTXO is spendable — opcodes, templates, and modern script trees. 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
SCRIPT
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. Verifies M of N signatures against N pubkeys; consumes an extra dummy stack item due to a 2010-era bug.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.
COMMON_PITFALLS
Things that catch people out
PITFALLS
RELATED_CONCEPTS
Other terms from Script & Authorization — click any to read its page:
TERMINOLOGY_INDEX
TERMINOLOGY
OP_CHECKMULTISIG
Verifies M of N signatures against N pubkeys; consumes an extra dummy stack item due to a 2010-era bug.
Script
Bitcoin's purpose-built stack language; every locking and unlocking script is a script program.
Stack
The single LIFO data structure all script execution operates on; no variables, no registers.
Locking Script
The scriptPubKey on an output; specifies the spending conditions.
Unlocking Script
The scriptSig/witness in an input; provides the data that satisfies the lock.
Redeem Script
Witness Script
In P2WSH, the script whose SHA256 is committed in the output; placed at the end of the witness stack.
Script Execution
Sequential stepping through opcodes, mutating the stack until either a valid truthy stack remains or the script fails.