MASTERING-BITCOIN · Interactive Practice | Unit 7 · Video 2
| Item | Meaning |
|---|---|
OP_DUP |
Duplicates the top stack item |
OP_HASH160 |
Pops top item, pushes its RIPEMD160(SHA256(...)) hash |
OP_EQUALVERIFY |
Pops two items, fails script unless equal |
OP_CHECKSIG |
Pops <pubkey> <sig>, pushes TRUE if signature is valid |
OP_CHECKMULTISIG |
Pops <n> <keys> <m> <sigs> plus one extra dummy item |
OP_0 |
Pushes the empty/zero value (used as the multisig dummy) |
P2PKH scriptPubKey: OP_DUP OP_HASH160 <keyhash> OP_EQUALVERIFY OP_CHECKSIG
P2PKH scriptSig: <sig> <pubkey>
Bare multisig scriptPubKey (t-of-k): <t> <key_1> ... <key_k> <k> OP_CHECKMULTISIG
Bare multisig scriptSig: OP_0 <sig_1> ... <sig_t>
A P2PKH spend concatenates scriptSig (signature, then pubkey) with scriptPubKey
(the lock) and runs the combined program on a stack. Use the slider to step through
each opcode and watch how the stack changes.
Conceptual question: At which step does the script verify that the spender's public key actually matches the address commitment?
⚙ interactive visualization — coming to this page format soon
Notice: The address only commits to a hash of the public key. The actual public key
is not revealed until step 2 (when the spender pushes it onto the stack), and it is verified
against the committed hash at step 6 (OP_EQUALVERIFY). Only after the hash matches does
OP_CHECKSIG verify the signature itself.
A 2-of-3 multisig spend reveals Bitcoin's most famous "permanent accident". The
scriptSig mysteriously begins with OP_0 — a dummy element that gets popped and
thrown away. Step through execution to see why it's required.
Conceptual question: Without OP_0 at the bottom, what would OP_CHECKMULTISIG
encounter on its final pop?
⚙ interactive visualization — coming to this page format soon
Reflect: OP_CHECKMULTISIG performs one extra pop beyond what its arguments
require. The leading OP_0 exists purely to feed that final pop without underflowing
the stack. BIP147 (2017) made this rule strict — the dummy must be exactly OP_0,
permanently freezing what was likely intended as a placeholder for a future upgrade.
OP_CHECKMULTISIG walks signatures and keys in order. For a 1-of-k spend with one
signature that matches the last key, the verifier still runs k signature checks.
Adjust the threshold t and key count k, and pick which key index actually matches
the (single) signature, to see the cost.
⚙ interactive visualization — coming to this page format soon
Notice: When the matching key sits at index k-1, the verifier wastes k-1 signature checks. The dummy element was likely intended to one day carry an index map telling the verifier exactly which signature pairs with which key — a soft-fork upgrade that BIP147 ossified out of existence.
Question 1 · What's in a Bitcoin Address?
A standard P2PKH Bitcoin address contains a commitment to a key. What does it actually encode?
✅ Correct! The address commits to HASH160(pubkey) — the key itself only appears at spend time.
❌ Not quite. The address is a commitment, not the key itself, and it certainly never contains the private key.
Solution:
A P2PKH address commits to HASH160(pubkey) = RIPEMD160(SHA256(pubkey)), not the public
key itself. The scriptPubKey is:
OP_DUP OP_HASH160 <keyhash> OP_EQUALVERIFY OP_CHECKSIG
When spending, the owner reveals the public key and a signature in the scriptSig. The script then:
OP_HASH160),<keyhash> (OP_EQUALVERIFY), and only thenOP_CHECKSIG).This indirection provides a small privacy benefit and a buffer against future quantum attacks on unspent coins.
Question 2 · P2PKH Stack Order
A P2PKH scriptSig is <sig> <pubkey>. After both items are pushed but before
any opcodes from the scriptPubKey execute, what does the stack look like
(bottom-to-top)?
✅ Correct! Pubkey ends up on top, ready for OP_DUP to duplicate it.
❌ Not quite. Items are pushed in order, with the last push on top. Re-trace the scriptSig <sig> <pubkey>.
Solution:
Stack-based execution pushes items in the order they appear. The scriptSig has <sig>
first, then <pubkey>:
<sig> → stack: [sig]<pubkey> → stack: [sig, pubkey] (pubkey is on top)This matters because OP_DUP (the first opcode of the scriptPubKey) duplicates whatever
is on top — and we want it to duplicate the public key so that one copy can be hashed
and the other can later be paired with the signature for OP_CHECKSIG.
Question 3 · Why OP_0?
True or False: The leading OP_0 in a multisig scriptSig is required because
OP_CHECKMULTISIG pops one more item from the stack than the signatures and keys
it actually verifies, and without OP_0 the stack would underflow.
✅ Correct! Without OP_0, that final unexplained pop would underflow the stack.
❌ Not quite. Trace the pops in OP_CHECKMULTISIG carefully — there's one more pop than you'd expect.
Solution:
True. OP_CHECKMULTISIG pops, in order:
That final pop has no semantic role — but if there's nothing to pop, the stack
underflows and the script fails, even with valid signatures. So multisig spenders
prepend OP_0 purely to feed that pop.
The dummy was likely meant to be repurposed by a soft fork (perhaps to encode a
signature-to-key index map for efficiency), but BIP147 (2017) ossified it: the dummy
must now be exactly OP_0. The would-be future feature is permanently blocked.
Question 4 · Bare Multisig Key Limit
Bare multisig (multisig used directly as a scriptPubKey) is limited to a maximum of 3 total public keys on mainnet. Which statement best describes this limit?
✅ Correct! It's a standardness/policy rule. Wrapping multisig in P2SH, P2WSH, or P2TR raises the cap to 15 or 20 keys.
❌ Not quite. The 3-key cap applies only to bare multisig and isn't enforced at the consensus layer.
Solution:
The 3-key cap on bare multisig is a policy (relay) rule, not a consensus rule. Standard nodes refuse to relay or mine non-standard bare multisigs with more keys, but a block containing one would still be technically valid by consensus.
Wrapping the same multisig inside other script types raises the limit:
| Script type | Max keys | Limit type |
|---|---|---|
| Bare multisig | 3 | policy |
| P2SH | 15 | policy + consensus |
| P2WSH | 20 | consensus |
| P2TR | 20 | consensus |
So the 3-key ceiling is specific to bare multisig only.
Solved: 0 / 4