--- title: "Bitcoin Timelocks Explained: nLockTime, CLTV and CSV" description: "Timelocks dictate when Bitcoin transactions become valid. Learn the difference between absolute and relative timelocks, and how they power inheritance schemes and the Lightning Network." url: https://basisdesk.news/learn/bitcoin-timelocks-explained published: 2026-11-06T18:30:32.294Z modified: 2026-11-06T18:30:32.294Z section: Bitcoin author: Basis Desk Newsroom (AI-generated, source-verified) sentiment: neutral tickers: [BTC] tags: [timelocks, nLockTime, CLTV, CSV, Lightning Network, smart contracts, UTXO] license: Quote with attribution to Basis Desk (basisdesk.news). Not financial advice. --- # Bitcoin Timelocks Explained: nLockTime, CLTV and CSV Timelocks dictate when Bitcoin transactions become valid. Learn the difference between absolute and relative timelocks, and how they power inheritance schemes and the Lightning Network. ## Key points - Bitcoin timelocks restrict when a transaction can be confirmed or when an output can be spent. - nLockTime applies to entire transactions, while CLTV and CSV apply to specific outputs. - Values below 500 million represent block heights; values 500 million and above represent UNIX timestamps. - The Lightning Network relies on CSV relative timelocks to penalize dishonest actors. - Timelocked transactions must be held off-chain and broadcast manually after the lock expires. Bitcoin timelocks are programmable conditions that restrict when funds can be spent, ensuring a transaction remains invalid until a specific time or block height is reached [1]. These mechanisms form the foundation of complex smart contracts on the network, enabling inheritance plans, escrow services, and second-layer scaling solutions [5]. By distinguishing between absolute and relative timelines, timelocks allow users to encode future financial operations directly into the blockchain protocol without relying on third parties. ## The Evolution of Time Control The original method for restricting a transaction by time is **nLockTime**, a parameter included in every $BTC transaction [1]. It operates at the transaction level, meaning it invalidates the entire transaction until the specified condition is met. If a transaction with an active nLockTime is broadcast to the network prematurely, nodes will reject it, and it will not enter the mempool [1]. For more on how unconfirmed transactions are processed, see our guide to [The Bitcoin Mempool: How Unconfirmed Transactions Work](https://basisdesk.news/learn/bitcoin-mempool-explained). The network interprets the nLockTime value in one of two ways. Timelocks specify their measurement method based on the value used: values below 500,000,000 are interpreted as block heights, while values at or above 500,000,000 are interpreted as UNIX timestamps [1]. For example, setting an nLockTime of 900,000 means the transaction cannot be included in a block until the blockchain reaches block height 900,000. Setting the value to 1700000000 restricts the transaction until that specific UNIX timestamp is recorded by the network. ## Script-Level Absolute Timelocks While nLockTime provided foundational utility, it lacked the granularity needed for specific outputs within a transaction. This limitation led to the introduction of **CheckLockTimeVerify (CLTV)**, established via Bitcoin Improvement Proposal 65 [2]. CLTV operates at the script level rather than the transaction level. Instead of preventing an entire transaction from being mined, CLTV locks a specific Unspent Transaction Output (UTXO) [2]. The recipient of that UTXO cannot spend the funds until the CLTV condition expires. When someone attempts to spend a UTXO encumbered by CLTV, the network checks the spending transaction's nLockTime. If the spending transaction's nLockTime is less than the CLTV value embedded in the UTXO, the script fails and the transaction is rejected [2]. This script-level absolute timelock allows a single transaction to pay multiple recipients, with each output unlocking at a different calendar date or block height. ## Relative Timelocks and Protocol Upgrades Absolute timelocks rely on external, forward-looking metrics. Relative timelocks, however, depend on the age of the UTXO being spent. Bitcoin Improvement Proposal 68 repurposed the transaction sequence numbers to enable relative timelocks at the transaction level [4]. Following this, Bitcoin Improvement Proposal 112 introduced **CheckSequenceVerify (CSV)**, enabling relative timelocks at the script level [3]. CSV ensures that a specific UTXO cannot be spent until a certain amount of time has elapsed since that UTXO was confirmed on the blockchain [3]. Unlike CLTV, which sets a hard deadline, CSV starts a countdown only after the funding transaction is mined. This mechanism is crucial for trustless smart contracts where the timing of the initial transaction is unpredictable. Consider a worked numeric example for an inheritance setup using CSV. Assume a user secures 10 BTC in a multisig wallet with a primary key and a backup key. The primary key can spend the funds immediately. The backup key is restricted by a CSV script requiring 52,500 blocks to pass. If a block is mined every 10 minutes on average, 52,500 blocks equate to roughly 365 days. The countdown begins the moment the 10 BTC UTXO is confirmed. If the primary key holder moves the funds to a new address after 100 days, the backup key's 365-day timer resets on the new UTXO. If the primary key is lost and the funds remain unspent for 52,500 blocks, the backup key becomes active, allowing heirs to recover the asset. ## Real-World Applications Beyond basic inheritance and delayed payments, timelocks are the structural enforcement mechanism for the Lightning Network [5]. Lightning relies on bidirectional payment channels where parties exchange unbroadcast transactions. To prevent a participant from broadcasting an outdated transaction to steal funds, the protocol uses Revocable Sequence Maturity. This system employs CSV to delay the payout of a closed channel. If a participant attempts to cheat by broadcasting an old state, the relative timelock delays their access to the funds, giving the honest party a window of time to submit a breach remedy transaction and claim all the funds in the channel [5]. ## Common Misconceptions * Timelocks push transactions automatically: The Bitcoin network does not store or automatically execute transactions at future dates. A transaction with a timelock must be held off-chain by the user and broadcast only after the lock expires. * Timelocks lock coins indefinitely: While funds can be locked for long periods, maximum values apply. A script can only lock funds up to the maximum block height or timestamp allowed by the protocol's integer limits. * Timelocks dictate when funds will be spent: They only dictate when funds *can* be spent. Once the timelock expires, the UTXO behaves like any standard output; the owner is not required to move the funds immediately. ## Protocol and Market Implications Timelocks fundamentally alter how Bitcoin operates as programmable money. By enabling stateful contracts without a Turing-complete virtual machine, they maintain the network's minimal attack surface while supporting robust layer-two scaling. From a market perspective, large volumes of BTC locked in long-term CLTV or CSV contracts temporarily remove supply from active circulation. Institutional custodians and escrow providers increasingly leverage these cryptographic primitives to enforce withdrawal delays and security protocols, integrating basic time-based limits without relying on centralized banking infrastructure. ## FAQ **What is the difference between nLockTime and CLTV?** nLockTime invalidates an entire transaction until a time is reached, while CLTV locks a specific output within a transaction so the recipient cannot spend it until the deadline. **How does the network distinguish between block height and timestamps?** The protocol uses a threshold of 500,000,000. If the timelock value is below 500 million, it is read as a block height. If it is 500 million or higher, it is read as a UNIX timestamp. **What happens if I broadcast a timelocked transaction early?** The Bitcoin nodes will reject the transaction as invalid, and it will not enter the mempool or be included in a block. **Are timelocks used in the Lightning Network?** Yes, relative timelocks (CSV) are critical for Lightning channel security, providing a delay period that allows honest parties to penalize users who broadcast outdated channel states. ## Sources 1. [The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments](https://lightning.network/lightning-network-paper.pdf) — Lightning Network 2. [Bitcoin Developer Reference: Timelocks](https://developer.bitcoin.org/devguide/transactions.html) — bitcoin.org 3. [BIP 65: OP_CHECKLOCKTIMEVERIFY](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki) — Bitcoin Core 4. [BIP 112: CHECKSEQUENCEVERIFY](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki) — Bitcoin Core 5. [BIP 68: Relative lock-time using consensus-enforced sequence numbers](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) — Bitcoin Core --- Basis Desk Newsroom · AI-generated, source-verified · https://basisdesk.news/about/how-we-use-ai