OP_CHECKLOCKTIMEVERIFY (CLTV) - BIP 65 Explained

1. OP_CHECKLOCKTIMEVERIFY (CLTV) — BIP 65 Explained

Background and Motivation

Before BIP 65 was introduced in December 2015, Bitcoin already had a mechanism called nLockTime that prevented a transaction from being included in a block until a certain block height or Unix timestamp had passed. However, this mechanism had a critical limitation: it was set at the transaction level, not at the script level. This meant that a sender could lock funds and set an nLockTime, but there was nothing in the locking script itself (the scriptPubKey) that enforced the timelock. A recipient could potentially replace the transaction with one that had no nLockTime, effectively bypassing the time restriction entirely.

The Bitcoin community needed a way to embed time constraints directly into the locking script, making them irrevocable and enforceable by the consensus rules of the network. This is exactly what BIP 65 — authored by Peter Todd — achieved by introducing the OP_CHECKLOCKTIMEVERIFY opcode, commonly abbreviated as CLTV.

What BIP 65 Defines

BIP 65 repurposed the previously unused opcode OP_NOP2 (opcode value 0xb1) and gave it new semantics. Before BIP 65, OP_NOP2 was a no-operation instruction: it consumed nothing from the stack, pushed nothing, and had no effect. BIP 65 gave it a new identity while maintaining backward compatibility — nodes that did not upgrade would still see it as a NOP, while upgraded nodes would enforce the new rule.

The core rule introduced by BIP 65 is:

CLTV checks that the top of the stack is less than or equal to the transaction's nLockTime field. If not, the script fails.

In other words, when a script contains <locktime> OP_CHECKLOCKTIMEVERIFY, the spending transaction must have an nLockTime value equal to or greater than the value specified in the script. This ties the script-level timelock to the transaction-level timelock, making both required simultaneously.

Soft Fork Activation

BIP 65 was activated as a soft fork, meaning it was backward-compatible. Old nodes that hadn't upgraded simply treated OP_CLTV as OP_NOP2 — a harmless no-op. Upgraded nodes enforced the new rule. The activation threshold required 75% of blocks in a 1,000-block window to signal readiness, eventually reaching the activation threshold at block 388,381 in December 2015.

This was a landmark moment: it was the first major soft fork that embedded time semantics into Bitcoin scripts at the consensus level.

Conditions Under Which CLTV Fails

CLTV will cause a script to fail under any of the following conditions:

• The stack is empty (there is no value to compare against).

• The top stack item is negative.

• The top stack item is greater than the maximum serialized script number.

• The transaction's nSequence field for the current input is 0xFFFFFFFF (this disables nLockTime checks — explained further in topic 2).

• The locktime type mismatches: one value is below 500,000,000 (block height) and the other is above (Unix timestamp).

• The top stack item (the required lock time in the script) is greater than the transaction's nLockTime.

If none of these failure conditions occur, CLTV acts like a NOP — it does not pop the value from the stack. This is why scripts using CLTV always follow it with OP_DROP to remove the locktime value before continuing with the rest of the script logic.

A Minimal CLTV Script

Copy

scriptPubKey:
  <expiry_time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

scriptSig (unlocking):
  <signature> <pubKey>

In this script:

1. <expiry_time> is pushed onto the stack.

2. OP_CHECKLOCKTIMEVERIFY checks that the spending transaction's nLockTime >= expiry_time. If not, the script fails immediately.

3. OP_DROP removes the <expiry_time> from the stack (since CLTV does not pop it).

4. The remainder is a standard Pay-to-Public-Key-Hash (P2PKH) check.

Why CLTV Was a Game Changer

Before CLTV, if Alice wanted to send Bob funds that he couldn't spend before a certain date, she had no cryptographic guarantee — Bob could simply rebroadcast the transaction without the locktime. With CLTV, the condition is embedded in the scriptPubKey itself. The coins are literally unspendable by anyone, regardless of what the spending transaction says about its own locktime, until the consensus-enforced condition is met.

This made Bitcoin significantly more expressive and opened the door to trustless smart contracts based on time, including inheritance mechanisms, vault patterns, and eventually the Lightning Network's payment channels.