MASTERING-BITCOIN · Interactive Practice — Unit 7 · Video 1

Bitcoin Script: The Stack-Based Validation Engine

IQuick Reference: Script Operations

Token Type	Examples	What it does
Data	`2`, `5`, `42`	Push the value onto the top of the stack
`OP_ADD`	—	Pop top two values, push their sum
`OP_SUB`	—	Pop top two values $(a, b)$ , push $a - b$
`OP_EQUAL`	—	Pop top two values, push `TRUE` if equal else `FALSE`
`OP_DUP`	—	Duplicate the top value of the stack

Validation rule: A script is valid when it finishes execution with TRUE on top of the stack. Two-stage execution (post-2010): Run the input script first, snapshot the stack, then run the output script on a copy of that stack.

IIVisualization 1: Step Through a Script

Conceptual question: How does a stack-based language process tokens one at a time?

Pick a script from the dropdown, then drag the step slider to walk through execution token by token. Watch the stack grow and shrink as data tokens push values and operators pop them off.

⚙ interactive visualization — coming to this page format soon

Reflect: Notice that operators like OP_ADD always consume values (the stack shrinks by one) while data tokens always grow the stack. Try the script that fails — 2 3 OP_ADD 7 OP_EQUAL. The stack still finishes with one item, but that item is FALSE instead of TRUE, so the script is rejected.

IIIVisualization 2: Two-Stage Validation (Input Script + Output Script)

Conceptual question: How does a spender prove they can unlock a UTXO?

The locking script is fixed: 3 OP_ADD 5 OP_EQUAL. Your job, as the spender, is to provide an input script (the "key") whose final stack, copied into the output script, ends in TRUE.

Pick different input scripts and watch validation run in two stages.

⚙ interactive visualization — coming to this page format soon

Notice: Several different input scripts unlock the same UTXO — 2, 1 1 OP_ADD, and 10 8 OP_SUB all work. They each leave 2 on top of the stack, which is exactly what the output script needs. The key isn't a password — it's any computation that produces the right value. This is why Script is more general than "just signatures."

IVQuiz Questions

Question 1

What does the operator OP_ADD do when it executes?

✅ Correct! OP_ADD consumes the top two values and replaces them with their sum, so the stack shrinks by one slot.

❌ Not quite. Operators in a stack machine consume their inputs. They pop values off the stack, never just read them.

Show solution

Solution:

Every binary operator in Script follows the same pattern: pop the top two values off the stack, compute something with them, and push the result back onto the stack. For OP_ADD:

Pop b (the top)
Pop a (the new top)
Push a + b

So the stack shrinks by exactly one slot each time OP_ADD runs. There is no "peek" or "read without removing" — Script only has push and pop.

Question 2

Run the script 4 6 OP_ADD 9 OP_EQUAL step by step on an empty stack. What is the final state of the stack, and is the script valid?

✅ Correct! 4 + 6 = 10, but OP_EQUAL then compares 10 with 9 and pushes FALSE. A non-TRUE top means the script is rejected.

❌ Not quite. Walk through token by token, and remember: OP_ADD and OP_EQUAL each pop two values and push exactly one result.

Show solution

Solution:

Walk through the tokens one at a time:

Step	Token	Stack after
0	(start)	`[]`
1	`4`	`[4]`
2	`6`	`[4, 6]`
3	`OP_ADD`	`[10]` (since 4 + 6 = 10)
4	`9`	`[10, 9]`
5	`OP_EQUAL`	`[FALSE]` (since 10 ≠ 9)

The final stack is [FALSE]. Validation requires the top of the stack to be TRUE at the end, so this script is invalid.

Question 3

True or False: Bitcoin Script is intentionally not Turing complete — it has no loops and bounded execution time — and this restriction is a security feature, not a limitation.

✅ Correct! As the video puts it: a more powerful language would have been a more powerful weapon. The limits prevent denial-of-service attacks against every full node simultaneously.

❌ Not quite. The lack of loops and the bounded execution model are core security properties. They guarantee that validation always terminates and that every node reaches the same verdict.

Show solution

Solution:

This is true. Script's restrictions are deliberate:

No loops means execution always terminates in time roughly proportional to script length.
Bounded runtime means a single transaction cannot freeze a node by running forever.
No state between scripts means execution is deterministic — every node reaches the same verdict.

Because every full node must validate every transaction, a more powerful language would have been a more powerful weapon: an attacker could craft a script that loops forever or eats unbounded memory, denying service to the entire network. The "crippled" feature set is exactly what makes global consensus tractable.

Question 4

Suppose a UTXO has the output script 7 OP_EQUAL (which expects a single 7 on the stack from the input script). Which of the following input scripts will successfully spend this UTXO?

✅ Correct! Script validates any computation that produces the right top-of-stack value. Signatures are common but not required by the language itself.

❌ Not quite. Recall the surprising example from the video: the output 3 OP_ADD 5 OP_EQUAL could be unlocked by anyone with arithmetic skills, with no signature at all. The language validates whatever stack-based condition the output script encodes.

Show solution

Solution:

Bitcoin Script validates any spending condition that can be expressed in its tiny stack language — not only signatures. Two-stage validation works like this:

Stage 1: Run the input script alone. Take a snapshot of the resulting stack.
Stage 2: Copy that snapshot, then run the output script 7 OP_EQUAL on the copy. OP_EQUAL pops two values; the snapshot supplied one (7), and the output script supplies the other (7). They match, so TRUE is pushed.

Inputs that work include:

7 — pushes 7 directly
3 4 OP_ADD — final stack is [7]
10 3 OP_SUB — final stack is [7]

What does not work:

❌ 5 — leaves [5], OP_EQUAL then compares 5 to 7 → FALSE
❌ (empty) — output script's OP_EQUAL would underflow

Most real Bitcoin outputs do require signatures, but that's a choice made by whoever wrote the output script — not a property of Script itself. The language is more general than "just signatures."

Solved: 0 / 4