Locktime (nLockTime)

Locktime (the nLockTime field) is a 4-byte value at the end of every Bitcoin transaction that specifies the earliest point at which the transaction may be included in a block. It enables absolute timelocks: "this payment cannot confirm until X". Until that point arrives, the network treats the transaction as non-final — nodes will not relay it into the mempool and miners refuse to include it, no matter how generous its fee.

Block height vs. timestamp

A single threshold — 500,000,000 — decides how the value is read. Below it, nLockTime is interpreted as a block height: the transaction is valid only in a block after that height. At or above it, the value is a Unix timestamp. Height-based locks are the norm in practice because block height is unambiguous, while timestamps in a block header are only loosely ordered. Since BIP113, timestamp locks are compared against the median-time-past — the median of the previous 11 block timestamps — rather than the current block's clock, which removes a miner-manipulation surface and guarantees the reference time only ever moves forward.

The nSequence dependency

Locktime has a famous quirk: it is only enforced if at least one input has a sequence number below 0xFFFFFFFF. If every input uses the maximum sequence value, nLockTime is ignored entirely. This is a fossil of Satoshi's original transaction-replacement design, and it is why wallets that want an active locktime deliberately set inputs to 0xFFFFFFFE — one below the maximum, keeping the lock live while leaving replace-by-fee signalling untouched.

What locktime is used for

The everyday use is invisible: many wallets set nLockTime to the current block height on ordinary spends as anti-fee-sniping protection, making it unattractive for a miner to reorganize the chain to capture juicy fees, since the reorged transaction could not be pulled into an earlier block anyway. The structural uses are protocol-level. Refund branches in payment protocols pre-sign a locked transaction the payer can broadcast if the counterparty disappears. Inheritance and recovery schemes hand a beneficiary a transaction that only becomes valid far in the future, refreshed periodically while the owner is alive. And the commitment machinery inside the Lightning Network leans on timelocks to give parties windows in which to dispute an outdated channel state.

Locktime vs. CHECKLOCKTIMEVERIFY

It is worth keeping the two layers straight. nLockTime constrains a transaction, and only by the cooperation of whoever builds it — nothing stops the holder of the keys from signing a different, unlocked spend. The opcode OP_CHECKLOCKTIMEVERIFY (BIP65) moves the constraint into the script that guards the coins themselves: it makes the output unspendable by any transaction whose nLockTime is below the script's threshold, so the timelock binds every possible spender rather than trusting one to set the field honestly. Relative timelocks — "this input must wait N blocks after its parent confirmed" — are the mirror-image feature, provided by sequence numbers and OP_CHECKSEQUENCEVERIFY. We find it helpful to think of nLockTime as a "not before" stamp baked into the transaction: a small, ancient field that quietly underpins refunds, inheritance plans, and the entire idea of off-chain protocols with on-chain deadlines.

Two clarifications save recurring confusion. First, the 100-block maturity rule that prevents spending a freshly mined coinbase output is a separate consensus rule, not an nLockTime under the hood — miners do not set locktimes on their rewards; the chain itself refuses immature spends. Second, locktime is easy to inspect: any decoded raw transaction shows the field in plain sight, and block explorers display it, so you can verify with your own node that a wallet's anti-fee-sniping behavior or a pre-signed refund actually carries the lock it claims. As with everything in Bitcoin, the field's value is not that someone promises it is set — it is that anyone can check.