A Bitcoin timelock is a condition written directly into a transaction or a script that prevents coins from being moved until a specific point in time, or until the blockchain reaches a certain block height. It's not an add-on or a third-party feature. It's baked into the Bitcoin protocol itself, and it's one of the more elegant tools in Bitcoin's scripting toolkit.
Most beginners learn about wallets, addresses, and private keys first. Timelocks tend to come later, because they're not something you encounter when simply buying or sending Bitcoin. But understanding them gives you a clearer picture of just how programmable Bitcoin actually is.
Two ways Bitcoin measures time
Before getting into the types of timelocks, it helps to know that Bitcoin tracks time in two ways: by Unix timestamp (seconds since 1 January 1970) and by block height (the sequential number of the most recently mined block). Both measurements are used in different timelock implementations, and which one applies depends on the value specified in the transaction.
Block height is often preferred because it's more predictable within the Bitcoin network itself. A new block is mined roughly every 10 minutes, so if you want to lock funds for approximately one week, you'd set a lock of around 1,008 blocks. Unix timestamps are also valid, but they rely on the clocks of the nodes processing the transaction.
The four main types of timelock
Bitcoin has four timelock mechanisms, split across two dimensions: whether the lock applies at the transaction level or the output level, and whether it's absolute or relative.
nLocktime is the oldest timelock, embedded in the transaction itself. It sets an absolute point in time or block height before which the entire transaction cannot be included in a block. If you set nLocktime to block 900,000, miners won't process that transaction until the chain reaches that height.
OP_CHECKLOCKTIMEVERIFY (CLTV) works at the script level rather than the transaction level. It's enforced inside a Bitcoin Script and locks a specific output until an absolute time or block height is reached. Unlike nLocktime, CLTV can't be overridden by replacing the transaction. The lock is embedded in the spending condition of the coins themselves.
nSequence is a relative timelock set in each transaction input. It defines how long after the previous transaction's confirmation the new one can be broadcast. It's measured in blocks or, for longer periods, in 512-second increments.
OP_CHECKSEQUENCEVERIFY (CSV) is the script-level version of relative timelocks. Like CLTV for absolute timelocks, CSV enforces the relative delay inside the spending script, making it tamper-resistant and a core component of more sophisticated Bitcoin applications.
Why timelocks matter in practice
Timelocks aren't just academic curiosities. They have real applications that range from inheritance planning to payment channels.
The Bitcoin Lightning Network relies heavily on CSV timelocks. When a payment channel is opened between two parties, the funds are locked in a multisig output. If one party tries to cheat by broadcasting an old channel state, the other party has a window defined by a CSV timelock to respond and claim the full balance. Without relative timelocks, Lightning channels couldn't work safely.
Timelocks are also used in inheritance and estate planning. A parent could create a transaction that sends Bitcoin to their child's address but locks the output until a block height ten years in the future. The coins sit on-chain, verified and immutable, with no trusted third party needed to enforce the condition. For more on planning your Bitcoin for future generations, see our guide on Bitcoin inheritance planning.
Escrow arrangements are another application. Two parties can lock funds in a script where the recipient can claim payment after a service is delivered, but the sender can reclaim funds via a timelock if the service never arrives. This removes the need for a centralised escrow agent.
How timelocks connect to Bitcoin Script
Timelocks are implemented through Bitcoin Script, the lightweight programming language that governs spending conditions on every transaction output. CLTV and CSV are opcodes within that language, meaning they execute as part of the validation logic when a transaction is broadcast to the network.
When a node validates a transaction that spends a CLTV-locked output, it checks the current block height or timestamp against the value embedded in the script. If the condition isn't met, the transaction is rejected outright. No miner will include it in a block, and no amount of fee-bumping will change that. The time has to pass first.
This is what makes script-level timelocks more secure than transaction-level ones. An nLocktime transaction can technically be replaced or re-signed before broadcast. A CLTV or CSV lock is embedded in the unspent output itself and can't be circumvented without producing a completely different transaction that spends a different output.
What timelocks don't do
A timelock doesn't hide funds or move them anywhere. The coins stay exactly where they are on the blockchain. What changes is who can spend them and when. Anyone can see the output exists and observe that it's time-locked, because all of this is visible in the public transaction data.
Timelocks also don't prevent the original owner from making a mistake. If you set an absolute CLTV lock with the wrong block height, the funds will be locked until that height regardless of intent. There's no override mechanism. Bitcoin transactions are final, and timelock conditions are enforced by every node on the network without exception.
It's also worth understanding that timelocks don't protect against lost keys. If the private key controlling a time-locked output is lost before the lock expires, the funds become inaccessible. Good private key management remains essential regardless of how sophisticated the spending conditions are.
Timelocks and the broader picture
Timelocks are one of the features that make Bitcoin more than a simple payment token. They demonstrate that Bitcoin's scripting system can enforce time-based conditions trustlessly, without any intermediary checking whether the clock has ticked over. The network itself is the enforcer.
For beginners, you don't need to implement timelocks directly to benefit from them. Every time you use a Lightning wallet, you're relying on CSV timelocks working correctly under the hood. They're part of what makes Bitcoin's second layer secure and functional, which in turn makes Bitcoin faster and cheaper for everyday use.
As your understanding of Bitcoin deepens, timelocks are worth revisiting. They sit at the intersection of cryptography, scripting, and economic incentive design, and they hint at how much more programmable Bitcoin's base layer could become as future soft forks add new opcodes to the stack.