CLTV

Anna is designing custody where she and Peter approve ordinary payments together. In case of prolonged unavailability, she also wants a recovery path usable only after a chosen threshold. CLTV can put this time condition into the script, the rules for spending previously received coins. The nLockTime field alone would delay only a particular transaction. CLTV prevents bypassing that path with a new transaction using a lower threshold. Other branches can still have different rules. [1] [5]

CLTV does not identify an owner or send money. If the recovery path requires Anna’s signature, she must provide it even after the time condition is met. A private key is a secret numerical value used to create such a signature. Time passing does not recover a lost private key. Nor do coins automatically move to another address: someone must prepare, sign and broadcast a valid transaction. If another branch permits earlier spending, a time lock in the recovery branch does not itself restrict that alternative. [1]

A block groups transactions into a batch added to the shared history. CLTV suits a condition tied to a predetermined point, rather than “wait a certain number of blocks after these coins were received.” CSV together with BIP 68, the relative-lock rules, handles the latter. That depends on confirmation of the particular output: a previously received amount with spending conditions. Neither approach guarantees an exact calendar date. Mining varies, and a reorganisation can change the confirmed history. In a reorganisation, the network adopts another valid branch of the chain, replacing part of its previous block history. [1] [7] [8] [9]

CLTV distinguishes two kinds of value. Below 500000000, the value means block height, its position in the chain. At or above that threshold it means a timestamp, a numerically encoded time. The script condition and the spending transaction’s nLockTime must use the same kind. Checking which number is larger is not enough: a block’s position cannot be compared with a time as though they meant the same thing. [1] [3] [5]

A Full Node independently checks the rules. It compares the script’s nonnegative threshold with the transaction’s absolute nLockTime. The threshold must not exceed nLockTime; equality is allowed for this check. The transaction must also satisfy the rules for inclusion in a particular block. CLTV does not read your computer clock or pause a program until morning. A failed check makes that attempt to use the spending path invalid. [1] [3] [4]

A transaction input identifies previously received coins being spent. Among its fields is nSequence. For the input checked by CLTV, this must not be 0xffffffff, the special final-sequence value. If all inputs used it, nLockTime could be disabled. CLTV prevents that by requiring this input to be nonfinal. This does not automatically set any particular relative waiting period; that belongs to other rules. [1] [3] [4]

Take a hypothetical transaction with nLockTime set to 900000 and a nonfinal input. For this time condition, the earliest possible block is 900001. Inclusion requires nLockTime to be strictly below the candidate block’s height. Block 900000 is therefore not enough even though CLTV’s own comparison allowed equality. “Finality” here means eligibility for inclusion, not payment irreversibility. Fees, other conditions and the miner’s choice can delay confirmation further. [4]

For a timestamp, BIP 113 uses the previous block’s Median Time Past. This is the middle value among the sorted timestamps of the last up to 11 blocks, not your watch or the block currently being mined. A time-based nLockTime must be strictly below it. You therefore cannot promise spending at precisely local noon. The condition has a meaning the network can verify; it is not a precise payment timetable. [2] [4]

During evaluation, the script uses a stack, a working pile of data. CLTV checks its time argument but does not remove it. In a simple schematic, OP_CHECKLOCKTIMEVERIFY is therefore followed by OP_DROP to remove the argument; a public key is pushed and OP_CHECKSIG verifies the signature. A public key is used to verify signatures and does not need to be kept secret. This explains the instructions’ roles, not a ready-made recipe for locking money. The script version, initial data and every other spending path must also be correct. [1] [3]

BIP 65 introduced CLTV as a soft fork, a tightening of rules that replaced the former OP_NOP2. It is not merely a proposed future feature. The whole design still needs checking: threshold type, nLockTime, nSequence, signatures and alternative branches. Bitcoin Core v29.0 and the linked specifications document the technical details. For an ordinary user, the key questions are who may spend before and after the threshold, and whether the recovery options are understood. [1] [3] [6] [10]