MSTR Cat

Blockchain/Level IV · Protocol depth/4.1 Script/Lesson 4

Timelocks: CLTV and CSV

The clock that cannot be wound back, and the median that keeps it honest

MaterialsA block explorer with transaction detail views (e.g., mempool.space or blockchain.com)A calculator capable of handling Unix timestampsThe BIP65, BIP68, and BIP113 specification documents

Wonder

  1. Why does a transaction field exist to delay spending if a new transaction can always bypass it?
  2. How does a single miner lie about time without breaking consensus for everyone else?
  3. What is the difference between waiting until a specific year and waiting two years from now?

Explore

  1. Every Bitcoin transaction carries an nLockTime field, a four-byte value that prevents the transaction from being mined before a certain point. If the value is below 500,000,000, it represents a block height; if at or above that threshold, it is a Unix timestamp. However, this mechanism applies only to that specific transaction instance. A user can always create a new transaction with the same inputs and a zero locktime, spending the coins immediately. nLockTime alone offers no security for future conditions because it does not bind the output itself.
  2. OP_CHECKLOCKTIMEVERIFY (CLTV), proposed by Peter Todd in BIP65 and activated in December 2015, changes this dynamic. CLTV is a script opcode that compares the transaction’s nLockTime against a value on the stack. If the locktime is less than the required value, execution fails. Because this check occurs within the output’s locking script, every attempt to spend that specific Unspent Transaction Output (UTXO) must satisfy the condition. This creates an absolute timelock: the coins are unspendable until a global consensus point in time or block height is reached.
  3. Relative timelocks operate differently by measuring duration rather than absolute points. BIP68 reinterprets the nSequence field of transaction inputs, which was previously unused for this purpose, to encode relative delays. OP_CHECKSEQUENCEVERIFY (CSV), defined in BIP112 and activated alongside BIP68 in July 2016, compares the input’s sequence value against a required duration. This allows scripts to enforce conditions like ‘this output cannot be spent until 144 blocks after it was confirmed.’ The delay is relative to the specific confirmation of that UTXO, making it ideal for time-based recovery paths or payment channel expiry.
  4. Time-based locks also gave miners an incentive to manipulate timestamps. Miners could set block timestamps up to two hours into the future to include more timelocked transactions earlier than intended. BIP113, activated simultaneously with relative timelocks in July 2016, introduced Median Time Past (MTP). Timelock checks now compare against the median of the past eleven blocks’ timestamps instead of the block’s own timestamp. This ensures no single miner can influence the clock significantly; MTP typically runs about one hour behind wall-clock time, providing a stable and verifiable reference for all timelock calculations.
  5. These mechanisms underpin complex applications like payment channels and inheritance protocols. In Lightning channels, payments in flight use absolute timelocks (CLTV) so an unclaimed payment can be refunded after a deadline, while relative delays (CSV) on a party’s own outputs give the other side time to punish an outdated channel state. For inheritance, scripts can combine multisignature requirements with timelocks: perhaps two keys are needed for daily access, but after one year of inactivity, a third key (an heir) joins the quorum via a CSV condition. These parameters are fixed at wallet creation and cannot be altered once funds are locked.
  6. Timelocks are permanent constraints; they unlock at a set time but offer no mechanism to relock or extend delays after activation. If a script encodes a sequence value of 100 blocks, the coins become spendable exactly when that relative height is reached from confirmation. Mistakes in encoding can render funds inaccessible for longer than intended or, conversely, unlock them too early. For hands-on verification, open any recent transaction on a block explorer and inspect the nLockTime field. Most wallets set it to the current block height, so the transaction cannot be placed in a block at an earlier height; that removes one incentive for miners to rewrite the latest block to collect its fees (‘fee sniping’).

Key facts

  • nLockTime values below 500,000,000 are interpreted as block heights; values at or above are Unix timestamps.
  • OP_CHECKLOCKTIMEVERIFY (BIP65) was activated in December 2015 and enforces absolute timelocks at the script level.
  • OP_CHECKSEQUENCEVERIFY (BIP112) and BIP68 were activated in July 2016, enabling relative timelocks via the nSequence field.
  • Median Time Past (MTP), introduced by BIP113, uses the median of the past eleven blocks to prevent miner time manipulation.
  • CSV delays are measured relative to the confirmation height or time of the specific UTXO being spent.
  • Wallets typically set nLockTime to the current block height to mitigate fee sniping risks.

Exercise nine, six, three, one

9CollectList 9 uses of timelocks you can find described (Lightning, vaults, inheritance, escrow, atomic swaps and others), noting whether each uses an absolute or a relative lock.
6ClusterGroup the 9 into 6 by purpose: refund, penalty window, inheritance, savings lock, contract deadline, or other.
3DistillReduce the 6 to 3 reasons a timelock must live in the output’s script rather than only in the spending transaction.
1CrystallizeWrite 1 sentence explaining how MTP transforms timelocks from a trust-in-miners model into a deterministic consensus rule.

Fact check

Dates, figures and claims checked against the published sources listed below.

Open in the interactive academy →

PT ES ZH JA KO RU DE FR MS