MASTERING-BITCOIN · Unit 7 · Video 5

Locking Coins in Time: Interactive Practice

IKey Reference

Mechanism Scope What It Restricts Enforced By
nLockTime Transaction field When the transaction can be mined Miners (per-tx)
OP_CLTV Output script (per UTXO) Spending the UTXO before an absolute height/time Full consensus
OP_CSV Output script (per UTXO) Spending the UTXO before N blocks/seconds since confirmation Full consensus

CLTV handshake: spending tx must have nLockTime ≥ CLTV value AND input sequence < 0xFFFFFFFF.

Block-time approximation: ~10 minutes/block, so 3 months ≈ 12,960 blocks.

IIVisualization 1: Why nLockTime Alone Fails

Alice creates a transaction Tx1 paying Bob with an nLockTime set 3 months in the future. Because the lock lives on the transaction, not on the coins, Alice can race a second transaction Tx2 that spends the same input back to herself today.

Adjust the slider to see what happens at different points in time.

⚙ interactive visualization — coming to this page format soon

Notice: Whenever Alice broadcasts Tx2 before Tx1's lock expires, Tx2 confirms first and consumes the input. Tx1 becomes permanently invalid — its nLockTime only delayed broadcast, not betrayal. The deadline must be bound to the coin, not the transaction wrapping it.

IIIVisualization 2: Absolute (CLTV) vs Relative (CSV) Timelocks

Both opcodes encumber a UTXO, but they answer different questions:

The key difference: CSV's countdown only starts when the parent transaction confirms. Adjust when the parent confirms and watch how the unlock points move.

⚙ interactive visualization — coming to this page format soon

Reflect: Move the parent-confirmation slider. The CLTV unlock stays anchored at block 832,960 regardless of when the parent confirms — it's a wall-clock deadline. The CSV unlock slides with the parent, always N blocks later. This is exactly why Lightning channels use CSV: the safety window must begin when the channel state actually lands on-chain, not at some predetermined calendar date.

IVVisualization 3: CLTV Stack Execution and OP_DROP

Walk through what happens on the script stack as Bob's redeem script executes:

<BobPubKey> OP_CHECKSIGVERIFY <832960> OP_CHECKLOCKTIMEVERIFY OP_DROP

Use the slider to step through each opcode and watch the stack.

⚙ interactive visualization — coming to this page format soon

Notice: At step 4, OP_CHECKLOCKTIMEVERIFY enforces the deadline but leaves 832960 on the stack. This is because CLTV was grafted onto a previously-unused NOP opcode for soft-fork compatibility — old nodes treat it as a no-op, so it cannot mutate the stack. OP_DROP is not part of the timelock logic; it's just cleanup.

VQuiz Questions

Question 1

Alice signs a transaction Tx1 paying Bob 1 BTC, with nLockTime set to a block height 3 months in the future. She gives Tx1 to Bob.

Why is Bob not actually paid by this alone?

✅ Correct! The lock is on the wrapper, not the coins.

❌ Not quite. The transaction is valid and the fee/signature aren't the issue. Think about what nLockTime restricts and what it doesn't.

Show solution

Solution:

nLockTime lives on the transaction, not on the coins. Miners will refuse to include Tx1 until the locktime is reached — but nothing stops Alice from broadcasting a second transaction Tx2 today that spends the same input UTXO back to herself. Once Tx2 confirms, the input no longer exists, and Tx1 becomes permanently invalid.

The fix (CLTV/CSV) moves the lock into the output script of the UTXO itself, so consensus rejects any spend that doesn't honor the deadline.

Question 2

Which of the following correctly describes a key difference between OP_CHECKLOCKTIMEVERIFY (CLTV) and OP_CHECKSEQUENCEVERIFY (CSV)?

✅ Correct! Absolute deadline vs. relative aging.

❌ Not quite. Both are full-consensus rules and both are NOP-compatible (don't consume their argument). The real difference is what kind of clock they read.

Show solution

Solution:

  • CLTV (absolute): "This UTXO cannot be spent before block X (or Unix time T)." The deadline is fixed in calendar/blockchain time.
  • CSV (relative): "This UTXO cannot be spent until N blocks (or seconds) have elapsed since the parent transaction was confirmed." The clock starts at confirmation and slides with it.

Both are enforced by full consensus (not just miners), and both are NOP-style opcodes that leave their argument on the stack — so the other options reverse the truth or invent distinctions that don't exist. Lightning relies primarily on CSV (relative aging windows for penalty); CLTV is widely used in HTLCs and escrow.

Question 3

True or False: When OP_CHECKLOCKTIMEVERIFY succeeds, it consumes (pops) its locktime argument from the stack — that's why scripts using CLTV need OP_DROP afterward to handle the leftover stack item.

✅ Correct! CLTV is NOP-compatible — it leaves the stack unchanged, and OP_DROP cleans up afterward.

❌ Not quite. Re-read the statement carefully — it gets the cause-and-effect backwards. If CLTV consumed its argument, why would you need OP_DROP?

Show solution

Solution: False.

The statement contradicts itself. CLTV does not consume its argument — it leaves the locktime value on the stack. That is precisely why OP_DROP is needed afterward.

The reason: CLTV was added via soft fork by repurposing a previously-unused NOP (no-operation) opcode. Old nodes that don't know about CLTV must still be able to validate the script, and they treat the opcode as a no-op — meaning it cannot alter the stack. So CLTV-aware nodes also leave the stack unchanged (other than the verification check), and OP_DROP is just stack hygiene to clean up the leftover value.

Question 4

Bob writes a redeem script with <832960> OP_CHECKLOCKTIMEVERIFY OP_DROP .... He later tries to spend this UTXO with a transaction whose nLockTime = 832960 and whose input sequence = 0xFFFFFFFF (the maximum value).

What happens?

✅ Correct! A maxed-out sequence disables nLockTime enforcement, so CLTV refuses to honor the spend.

❌ Not quite. The nLockTime check passes, and 832,960 is well below the timestamp threshold (~500 million). There's a second requirement CLTV places on the input itself.

Show solution

Solution:

CLTV imposes two requirements on the spending transaction:

  1. The transaction's nLockTime must be ≥ the CLTV value (here 832,960). ✓ satisfied.
  2. The input's sequence field must be strictly less than 0xFFFFFFFF. ✗ violated.

Why the sequence rule? Setting sequence = 0xFFFFFFFF is the historical signal that disables nLockTime enforcement on that input. If CLTV allowed that, the spender could effectively bypass the timelock. So CLTV explicitly rejects spends where the sequence is at maximum.

(For reference: 832,960 is below the threshold (~500 million) where Bitcoin switches from interpreting the value as a block height to a Unix timestamp, so the format is unambiguously a block height.)

Solved: 0 / 4