How Bitcoin Keeps a One-Year Promise Without a Clock
From the nLockTime already sitting in your ordinary payments, to the two-layer design of CLTV and CSV that never reads a clock, to the median time that blocks miner timestamp games. The Lightning Network and inheritance planning all stand on top of this.
Open any transaction in a block explorer. Near the bottom there is a field called locktime, and more often than not the value is not zero. A large share of ordinary payments made by modern wallets look like this. You never configured anything, yet your transaction already carries a time condition. The reason appears midway through this article.
A timelock is a device that makes bitcoin unspendable before a certain point in time. Inheritance planning, escrow, and the entire Lightning Network stand on top of it. But look at the implementation and something odd stands out. It is a feature that enforces time, and nowhere in it is there any code that reads a clock.
Bitcoin has no clock
In a distributed system, "what time is it" is a harder question than it looks. Every node's clock differs slightly, and the timestamp in a block is a value the miner writes in, constrained only loosely by consensus rules. A miner can stamp a time earlier than the previous block, or pull it somewhat into the future.
The problem is that promises about money need time. To enforce a condition like "these funds become spendable in one year," the system needs a notion of time everyone agrees on. Bitcoin's answer is not a wall clock but the chain itself. Block height increases monotonically in a way nobody can dispute, and timestamps become usable time once passed through a safeguard we will meet later. The whole design of timelocks rests on this premise.
nLockTime: this transaction is not valid yet
The oldest timelock attaches to the transaction itself. Every bitcoin transaction has a 4-byte field called nLockTime, and a transaction with this field set cannot enter a block until that point arrives. The interpretation splits on magnitude. Below 500,000,000 it is read as a block height; at or above, as a Unix timestamp. Block five hundred million is thousands of years away, so the two readings can never collide.
There is one caveat. If every input's nSequence is at its maximum value (0xFFFFFFFF), nLockTime is ignored. This is a trace of Satoshi Nakamoto's original design. The early implementation had a replacement mechanism where an unconfirmed transaction could be superseded by a new version with a higher nSequence, and nLockTime was the deadline that kept the transaction from finalizing before that negotiation ended. The mechanism was disabled early because it allowed a DoS attack of endless free replacements, but the fields and rules remained, and they carried forward into today's RBF and timelocks.
This also solves the puzzle from the opening. Bitcoin Core and several other wallets fill in nLockTime with the current block height even on ordinary payments. The target is fee sniping: during a chain reorganization, a miner could pull someone else's confirmed transactions into a re-mined past block and sweep their fees again. A transaction that cannot enter any block below the current height removes the incentive to rewind the chain for it. The locktime value stamped on your payment is that countermeasure at work.
The limit of nLockTime is that what it locks is the transaction, not the coin. As in the method used for inheritance planning, you can pre-sign a transaction that only becomes valid a year from now. But the coin itself remains free, so if you change your mind you can simply spend the same coin with a different transaction first. As a renewable promise that is a feature, but to bind a condition to the coin itself, one more tool is needed.
The script never looks at the clock: CLTV
That tool is BIP-65, OP_CHECKLOCKTIMEVERIFY, proposed by Peter Todd in 2014 and known as CLTV. Put this opcode in a script and the condition attaches to the coin rather than to a transaction. From the moment the output is received, nobody can spend it before the specified point.
<expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP <pubkey> OP_CHECKSIGThe interesting part is how it verifies. CLTV does not check the current block height or the current time. Instead it checks that the nLockTime field of the transaction trying to spend this coin is at or above the expiry written in the script. The script fails if the stack is empty, if the value is negative, if the units mismatch because one side is a block height and the other a timestamp, if nLockTime falls short of the expiry, or if that input's nSequence is at maximum so that nLockTime itself is switched off.
The lock is therefore enforced in two steps. The script only asks "does the spending transaction carry an nLockTime at or above the expiry," and whether that nLockTime has actually passed is checked separately by consensus rules. It looks like a detour, but the design has a reason. Script verification must produce the same result no matter which block it runs in. If a script read the current state of the chain directly, a transaction valid today could become invalid after a reorganization, and at that moment the determinism of verification breaks. By wrapping the time check in a field of the transaction, the script stays deterministic and the comparison against time is delegated to the consensus layer.
There is also elegance in the deployment. Rather than inventing a new opcode, BIP-65 gave meaning to OP_NOP2, a reserved opcode that did nothing. Old nodes that never upgraded still read that slot as "do nothing" and let it pass, so the new rules formed a subset of the old ones and could ship as a soft fork. It activated in late 2015.
How long since confirmation: BIP-68 and CSV
It soon became clear that absolute points in time were not enough. The condition a payment channel needs is not "from March 1, 2027" but "144 blocks after this output confirms." Nobody knows in advance when a channel will close, so the reference point must be the output's own confirmation, not the calendar. This is the relative timelock.
Three BIPs, activated together in 2016, built it. BIP-68 recycles the nSequence field left idle since the replacement mechanism was disabled. In transactions of version 2 or higher, when the field's top bit (the disable flag) is off, the low 16 bits become a relative lock duration. Bit 22 selects the unit: off means blocks, on means time in units of 512 seconds. 512 is 2 to the 9th power, so the bit shift is cheap, and it is close to the 600-second average block interval, keeping the two units on the same scale. Sixteen bits allow a lock of up to 65,535 blocks, about 1.25 years.
OP_CHECKSEQUENCEVERIFY from BIP-112, known as CSV, is its script counterpart. It uses exactly the same indirection as CLTV. Instead of looking at the current chain, it checks that the nSequence written on the spending transaction's input is at or above the value the script demands, and whether that nSequence is actually satisfied is checked by BIP-68's consensus rules. The reserved opcode redefined this time was OP_NOP3.
When miners lie about time: BIP-113
Time-based locks still had one hole. If maturity is judged by a block's timestamp, the problem is that the person writing the timestamp is the miner. When not-yet-mature transactions are sitting in the mempool carrying fees, a miner has an incentive to stamp the block with a time pulled forward and sweep them up early. In BIP-113's own words, a perverse incentive to lie about the time of their blocks.
BIP-113 changed the reference for maturity comparisons from the block's own timestamp to the median of the previous 11 blocks' timestamps, the so-called median time-past. Moving a median requires steadily manipulating the times of many blocks rather than one, so an individual miner's lie loses its force, and the value always advances monotonically. The side effect is minor: the median trails real time by roughly an hour, so time-based locks release about that much later than the wall clock.
What runs on these parts
The Lightning Network is the biggest consumer of timelocks. The HTLC that relays a payment hop by hop combines a hash condition with a CLTV expiry, so an intermediary can recover funds after a deadline if the other side goes silent. When a channel is closed unilaterally, the closer's own balance being locked for a period is CSV. That delay gives the counterparty time to inspect whether an old channel state was used to cheat and to file an objection. With hundreds of thousands of channels open, as long as they close honestly the timelocks never even fire. It is a safety net invisible in normal times that acts only at the moment of dispute.
In inheritance planning the two mechanisms serve different roles. A transaction pre-signed with nLockTime becomes a will that is renewed periodically, while a script containing CLTV engraves a condition like "if I do not move this coin for 50,000 blocks, my heir's key can open it too" onto the coin itself. The vault designs in the covenants discussion also use timelocks to force a delay on withdrawals. Even if a key is stolen, the lock window gives the recovery key a chance to pull the funds back.
What timelocks cannot do
Mind the direction. A timelock only ever locks one way. "Cannot spend before this point" is possible; "cannot spend after this point," that is, coin expiry, is not. This is not an accident but a deliberate constraint. If a spending condition that was once valid could turn invalid with the passage of time, a transaction already confirmed could become retroactively invalid during a reorganization. Verification must be monotonic, meaning what is valid stays valid, for the chain to be safely reassembled.
So where expiry is needed, a fork in the road is built instead of a lock. A two-branch script opens only with A's key before the deadline, and also with B's key after it. A's right never disappears; B's path is merely added, so monotonicity holds. The refund path in escrow, the inheritance script above, and the recovery path of an HTLC all follow this pattern.
A system with no clock and no administrator enforces promises that take time. The nLockTime that attaches to transactions, the CLTV and CSV that attach to coins, and the median time that filters out miners' lies. Those four are all the parts there are, and each one is no more complex than comparing a single field. The careful arrangement of those simple parts so that determinism never breaks is what everything built on time, from Lightning to inheritance, actually rests on.