Absolute Timelock

An absolute timelock prevents a Bitcoin transaction from being included in a block until a fixed point in the future — either a specific block height or a specific calendar time. It is the original timelock mechanism, expressed through the transaction's 4-byte nLockTime field and enforceable inside a locking script with OP_CHECKLOCKTIMEVERIFY (CLTV, defined in BIP 65). Where most script conditions ask "who is allowed to spend this?", an absolute timelock asks "when is anyone allowed to spend this?" — and consensus rules, not a custodian, enforce the answer.

How nLockTime works

The nLockTime value is interpreted against a single threshold: values from 0 to 499,999,999 are read as a block height, and values from 500,000,000 to 4,294,967,295 are read as a Unix timestamp. The block-height range covers thousands of years of future blocks, while the timestamp range runs to the year 2106. A node refuses to accept a locked transaction into a block until the chain has reached the specified height or time. There is one classic gotcha: for nLockTime to take effect at all, at least one input's nSequence must be set below the maximum (0xfffffffe or lower); otherwise the field is ignored and the transaction is treated as final. Time-based locks are evaluated against Median Time Past — the median of the last eleven block timestamps — rather than wall-clock time, which is why a time-locked transaction typically becomes valid roughly an hour later than a naive reading of the timestamp suggests.

nLockTime versus CLTV

The distinction that trips people up is where the lock lives. nLockTime is a property of a transaction: it constrains when that one signed transaction can confirm, but nothing stops the key-holder from signing a different, unlocked transaction spending the same coins. OP_CHECKLOCKTIMEVERIFY moves the constraint into the output's locking script: the coins themselves become unspendable by anyone until the specified height or time, no matter what transaction tries to spend them. CLTV works by comparing its argument against the spending transaction's nLockTime, so the two mechanisms interlock — the script forces the spender to set an nLockTime at or beyond the threshold.

What it is good for

Absolute timelocks underpin inheritance schemes, escrow refunds, and savings vaults where a coin must be unspendable until a known date or height. A common self-custody pattern is a recovery path that only becomes valid after a distant block height: if the primary keys are lost, a backup key (or a family member's key) can sweep the funds after the deadline, but not a day before. Embedding the constraint in the scriptPubKey via CLTV makes this trustless — no lawyer, exchange, or hardware wallet vendor can move the funds early, and neither can a thief who steals the backup key today. Layer-two protocols lean on the same primitive: Lightning's original HTLC construction uses absolute locks to bound how long a payment can remain in limbo, and multisig vault designs use staggered timelocks to create tiered recovery paths with different key sets unlocking at different dates.

There is also a subtler, everyday use most wallet users never notice: anti-fee-sniping. Bitcoin Core and several other wallets set nLockTime on ordinary transactions to the current block height, making each transaction valid only for the next block onward. This removes a perverse incentive during high-fee periods — a miner tempted to deliberately re-mine (reorganize) a recent block to capture its juicy fees would find that the transactions inside it cannot simply be pulled forward into an earlier slot. It costs nothing, and it means absolute timelocks quietly protect the chain's stability in millions of transactions that have no vault or escrow anywhere in sight.

For deadlines measured from an output's confirmation instead of a fixed point, see relative timelock. The opcode that enforces absolute locks in script is covered in depth under OP_CHECKLOCKTIMEVERIFY (CLTV).