What if you could create Bitcoin today but make it impossible to spend until a specific time in the future?
Bitcoin can do exactly that.
A feature called a timelock can restrict when a transaction or particular spending path becomes valid.
That might mean:
“This Bitcoin cannot be spent until block 900,000.”
Or:
“Wait 30 days after this output is created before this spending path becomes available.”
Timelocks are an important part of Bitcoin’s scripting system and help make more advanced arrangements possible, including delayed recovery paths, escrow designs, payment channels, and other conditional spending systems.
Unlike simply keeping Bitcoin in a wallet and choosing not to spend it, a properly constructed timelocked output can enforce the waiting condition through Bitcoin’s consensus rules.
What Is a Bitcoin Timelock?
A Bitcoin timelock is a rule that prevents certain Bitcoin spending conditions from being satisfied until a specified amount of time has passed or a particular blockchain height has been reached.
Think of it like a digital lock with a timer.
Before the required condition:
Spending attempt → Not valid
After the required condition:
Spending attempt → Can become valid
The important distinction is that the lock isn’t merely a promise.
When implemented through Bitcoin’s consensus and scripting rules, nodes can reject a transaction that attempts to spend the output too early.
This allows developers to build spending conditions that depend on time.
Why Would Bitcoin Need Timelocks?
At first, a timelock may seem unnecessary.
Why not simply hold the Bitcoin yourself and promise not to spend it?
The problem is that a personal promise isn’t enforceable by the Bitcoin network.
Suppose Alice and Bob create an agreement where Alice should only be able to recover funds after six months.
If Alice controls the private key and nothing else restricts the output, she could potentially spend the Bitcoin tomorrow.
A timelock can create an actual blockchain-enforced restriction.
The network can effectively say:
“This spending path isn’t valid yet.”
That opens the door to financial arrangements that would be difficult to implement with ordinary signatures alone.
Bitcoin Has More Than One Kind of Timelock
This is where the topic gets interesting.
Bitcoin has two major types of time-based restrictions:
Absolute Timelocks
These refer to a specific point in blockchain time.
For example:
“This spending path becomes available after block 900,000.”
or:
“This spending path becomes available after a specified timestamp.”
Relative Timelocks
These refer to how long an output has existed or how long a related transaction input has aged.
For example:
“Wait 1,000 blocks after this output is confirmed.”
The two mechanisms solve different problems.
Absolute Timelocks: A Specific Future Point
An absolute timelock can be thought of as a deadline or unlock point.
Imagine a Bitcoin output containing a condition that says:
Spend normally now, or use a recovery path after a specific future point.
The future point can be represented using the transaction’s nLockTime mechanism together with script rules such as OP_CHECKLOCKTIMEVERIFY (CLTV).
BIP-65 introduced OP_CHECKLOCKTIMEVERIFY, allowing a script to make an output unspendable until a specified block height or block-time condition is satisfied.
Conceptually:
Today
↓
Bitcoin locked
↓
Required block height/time reached
↓
Timelocked spending path becomes available
The exact rules are more precise than simply “wait until this date,” but that is the basic idea.
What Is nLockTime?
Bitcoin transactions contain a field called:
nLockTime
It can be used to specify a locktime for the transaction.
At a high level, it can represent either:
A block height
or:
A timestamp
The interpretation depends on the value used.
BIP-65 relies on the relationship between the transaction’s nLockTime and the value checked by OP_CHECKLOCKTIMEVERIFY. The locktime type also has to match.
This means nLockTime isn’t simply a note saying:
“Please don’t mine this yet.”
It becomes part of the transaction’s validity conditions when used with the appropriate rules.
Block Height vs Time
A Bitcoin timelock doesn’t always mean a wall-clock date.
It can be based on:
Block height
or:
Time
A block-height example might be:
“Not spendable until block 900,000.”
A time-based example might be:
“Not spendable until a specified future timestamp.”
Block height is often easier to reason about because it counts confirmed blocks.
Time-based lock conditions depend on Bitcoin’s time rules rather than your phone or computer’s local clock.
That’s an important distinction.
Bitcoin does not simply trust one user’s device clock when enforcing blockchain timelocks.
A Simple Absolute Timelock Example
Imagine Alice creates a recovery arrangement.
Her normal spending path requires:
Alice + Bob
to authorize the transaction.
But she also wants an emergency recovery path.
She could design a script where:
Normal path → Alice and Bob can spend
and:
Recovery path → Alice plus a backup key after a future time
The simplified structure could look like:
Bitcoin Output
|
┌────────┴────────┐
↓ ↓
Normal Path Recovery Path
Alice + Bob Backup Key
|
Timelock passes
|
Spend
BIP-65 specifically describes escrow and recovery-style constructions where a delayed path becomes available after a specified future point.
A Timelock Does Not Necessarily Mean the Entire Wallet Is Frozen
This is another important distinction.
A wallet can contain several UTXOs.
Some could be immediately spendable.
Others could be subject to timelocks.
For example:
Wallet
|
├── UTXO A → Spendable now
|
├── UTXO B → Locked until future height
|
└── UTXO C → Normal spending conditions
So a timelock can apply to a particular output or particular spending path rather than freezing everything a user owns.
This makes timelocks useful for structured custody arrangements.
Timelocks Can Create Recovery Paths
One of the most practical uses is recovery.
Imagine you want a Bitcoin wallet where:
You can spend normally with two keys
but:
A backup key can recover the funds after a long delay if something goes wrong.
A timelock can help create that delayed branch.
For example:
Normal
Alice + Bob
↓
Spend immediately
Recovery
Backup key
↓
Wait 90 days
↓
Spend
The delay can give another participant time to react to an unauthorized or unexpected transaction, depending on the exact script design.
This is one reason timelocks appear in advanced Bitcoin custody systems.
Timelocks and Escrow
Timelocks can also be used in escrow-style arrangements.
Suppose Alice and Bob jointly control funds.
They normally require both signatures to spend.
But what happens if one person disappears?
A delayed recovery path can provide another route after a predetermined period.
BIP-65 gives an escrow example where a delayed third-party recovery option becomes available after a specified time.
The basic design is:
Before expiry:
Alice + Bob
After expiry:
Alice + Backup Party
The exact script can be much more sophisticated, but the principle is simple:
Time changes which spending paths are available.
Why a Timelock Is Different From a Calendar Reminder
Imagine writing:
“Do not spend these coins before January 1.”
That’s just a note.
A Bitcoin timelock can be part of the transaction and script rules themselves.
That means participating nodes can enforce the condition.
If someone creates an otherwise valid-looking transaction that tries to use a timelocked path too early, the transaction can fail validation.
That’s a fundamental part of what makes timelocks useful for contracts and recovery systems.
Timelocks and Bitcoin Smart Contracts
Bitcoin doesn’t use smart contracts in exactly the same way as Ethereum.
However, Bitcoin Script can express conditional spending rules.
Timelocks are one of the important building blocks.
A Bitcoin script can effectively say:
“You need the right signature.”
and:
“You also need to wait long enough.”
Those conditions can be combined with:
- Multisignature
- Hash locks
- Taproot
- Miniscript
- Payment channels
- Recovery paths
This makes timelocks an important primitive for Bitcoin’s programmable spending model.
Why Timelocks Matter for Lightning
The Lightning Network relies heavily on time-dependent spending conditions.
Payment-channel constructions can use relative and absolute timelocks to create windows during which participants can respond to certain on-chain events.
For example, BIP-112 describes relative timelocks as useful in bidirectional payment channels because they can create a defined period in which a counterparty can react to certain conditions.
This is one reason timelocks are much more than an obscure Bitcoin Script feature.
They help make sophisticated off-chain protocols possible.
Absolute vs Relative: The Core Difference
The simplest way to remember the two systems is:
Absolute
“Wait until this particular point.”
Example:
Block 900,000
Relative
“Wait this long after the relevant output or transaction input becomes active.”
Example:
1,000 blocks after confirmation
The relative version doesn’t start from a fixed calendar date.
Its clock is connected to the age of the output being spent.
BIP-112’s OP_CHECKSEQUENCEVERIFY works with BIP-68 to enforce these relative age conditions.
Why Relative Timelocks Are Useful
Imagine Alice and Bob create a transaction today.
They don’t know exactly when that transaction will confirm.
If Alice’s recovery period were based on a calendar date, the useful waiting period could vary depending on when the transaction enters the blockchain.
A relative timelock can instead say:
“Once this output confirms, wait another 7 days.”
Now the timer begins from the blockchain event itself.
That makes relative timelocks particularly useful for protocols where the delay should start when an output is created or confirmed.
A Simple Relative Timelock Example
Imagine a transaction creates an output for Alice.
The script says Alice can use one spending path only after:
144 blocks
have passed from the relevant output’s confirmation.
The process becomes:
Output created
↓
Confirmation
↓
Relative timer begins
↓
144 blocks pass
↓
Delayed spending path becomes available
That’s different from saying:
“Alice can spend after block 900,000.”
The first is relative.
The second is absolute.
What Is OP_CHECKLOCKTIMEVERIFY?
OP_CHECKLOCKTIMEVERIFY, usually abbreviated CLTV, is the opcode introduced by BIP-65.
Its job is to let Bitcoin Script verify a locktime condition.
The script can require that the transaction’s nLockTime satisfies the required condition.
If the condition isn’t met, the script path fails.
BIP-65 also requires the transaction’s relevant input sequence not to be final when using this mechanism.
CLTV is therefore associated with:
Absolute timelocks
What Is OP_CHECKSEQUENCEVERIFY?
OP_CHECKSEQUENCEVERIFY, usually called CSV, is the opcode introduced by BIP-112.
It works together with BIP-68 to provide relative timelocks.
Instead of comparing a spending transaction against one fixed future locktime, CSV can enforce a minimum age for the relevant input.
BIP-112 specifies both block-based and time-based relative locktime modes, with time-based relative locktime using 512-second units.
CSV is therefore associated with:
Relative timelocks
Why Timelocks Are More Powerful Than They Look
A timelock by itself is simple:
Wait before spending.
But combine it with another condition and things become much more interesting.
For example:
Signature + timelock
Multisig + timelock
Hash secret + timelock
Taproot + timelock
These combinations can create spending paths where different people have different rights at different times.
That’s the foundation for many advanced Bitcoin protocols.
Timelocks Can Protect Against Failure
One of the most useful ideas is that a delay can create a reaction window.
Imagine a protocol has:
Normal path
and:
Delayed fallback path
The normal path can be used immediately.
The fallback path only becomes available after a waiting period.
That waiting period can give another participant time to respond.
BIP-112 specifically discusses this pattern in payment channels, where relative delays create a response window around certain spending conditions.
The delay isn’t just an inconvenience.
It can be a security feature.
What Happens if You Try to Spend Too Early?
The transaction can fail the relevant timelock condition.
For a consensus-enforced timelock, nodes can reject a transaction that doesn’t satisfy the required conditions.
The important distinction is:
The Bitcoin still exists.
It simply cannot be spent through that particular path yet.
Once the required condition is satisfied, a correctly constructed transaction can become valid.
Timelocks Don’t Automatically Mean “Frozen Forever”
A timelock usually describes a condition.
It doesn’t necessarily mean:
“Nobody can ever spend these coins.”
A script can contain multiple branches.
For example:
Bitcoin Output
|
┌───────┴───────┐
↓ ↓
Normal path Delayed path
Spend now Wait 90 days
This is why timelocks can be combined with multisig and other conditions.
The delay might apply only to the fallback branch.
CLTV vs CSV: The Core Difference
The easiest way to remember the two systems is:
CLTV
Wait until a specific point in the future.
CSV
Wait a specific amount of time after an earlier blockchain event.
For example:
CLTV:
“Do not allow this spending path before block 900,000.”
CSV:
“Do not allow this spending path until 144 blocks have passed since the relevant output became mature.”
CLTV is therefore associated with absolute timelocks, while CSV is associated with relative timelocks.
BIP-65 introduced OP_CHECKLOCKTIMEVERIFY for absolute locktime conditions, while BIP-112 introduced OP_CHECKSEQUENCEVERIFY and builds on the relative-locktime semantics defined by BIP-68.
What Is nLockTime?
Every Bitcoin transaction contains a field called:
nLockTime
It can represent the earliest point at which the transaction can be included in the blockchain, depending on how it is used.
Bitcoin’s transaction reference describes lock_time as either a block number or a Unix-epoch time.
The interpretation follows an important threshold.
If nLockTime is:
Below 500,000,000
it is interpreted as a block height.
If it is:
500,000,000 or higher
it is interpreted as a Unix timestamp.
For example:
nLockTime = 900000
↓
Block-height lock
nLockTime = 1800000000
↓
Time-based lock
This gives Bitcoin a compact way to represent either:
“Not before this block.”
or:
“Not before this time.”
The Bitcoin developer documentation describes the same threshold and semantics.
But nLockTime Alone Isn’t the Whole Story
Here’s an important detail.
nLockTime controls whether a transaction is considered final for inclusion.
But by itself, it doesn’t necessarily create a permanent restriction on the underlying UTXO.
The Bitcoin developer documentation explains that a time-locked transaction can effectively be superseded by another valid transaction spending the same output before the locktime expires.
This is one reason CLTV is important.
BIP-65 allows the spending condition itself to enforce an absolute locktime.
That means a script can say, in effect:
“This particular spending path requires the transaction to satisfy this locktime.”
What Does OP_CHECKLOCKTIMEVERIFY Do?
OP_CHECKLOCKTIMEVERIFY, usually called CLTV, is a Script opcode introduced by BIP-65.
It allows an output’s spending conditions to require a particular locktime.
Conceptually:
Script says:
"Required locktime = X"
↓
Spending transaction provides nLockTime
↓
Bitcoin checks them
↓
Condition satisfied?
↙ ↘
YES NO
↓ ↓
Continue Script fails
BIP-65 specifies that the locktime type must match—block height with block height, or timestamp with timestamp—and the transaction’s nLockTime must satisfy the required value. It also requires the relevant input’s sequence number not to be final.
Why Does CLTV Care About nSequence?
This is a detail that often gets skipped in simplified explanations.
A transaction input has a field called:
nSequence
If the sequence number is:
0xffffffff
that input is considered final.
BIP-65 specifically requires the sequence number to be non-final for the CLTV condition to function.
So a simplified CLTV transaction needs to satisfy both:
The transaction’s nLockTime is high enough
and:
The relevant input isn’t final.
That’s why simply putting a future value into nLockTime doesn’t automatically guarantee that a timelocked Script path will work.
Why Does Bitcoin Use Block Height Instead of Only Dates?
Bitcoin isn’t a centralized database with one trusted clock.
Nodes operate independently.
If the network simply trusted a user’s computer clock, different machines could disagree about whether a transaction should be valid.
Block height provides a blockchain-native measurement.
For example:
Block 900,000
is a concrete event in the chain.
A transaction can therefore become valid based on reaching that height.
This is useful when an application needs a condition tied to the progression of the blockchain rather than an exact calendar date.
But Bitcoin Also Supports Time-Based Locktimes
Time-based locktimes exist too.
However, Bitcoin doesn’t simply rely on the timestamp of one newly mined block.
BIP-113 changed the consensus calculation for locktime-related checks to use Median Time Past (MTP) rather than the timestamp of the block currently being evaluated.
MTP is calculated from the median timestamps of the previous 11 blocks.
This gives the network a more monotonic, consensus-defined clock.
So when Bitcoin uses a time-based lock, it is not simply asking:
“What time does my computer say it is?”
It is using blockchain-derived time information.
Why Median Time Past Matters
Imagine miners were allowed to set block timestamps however they wanted.
A miner could potentially manipulate timestamps to make a timelocked transaction appear mature earlier than expected.
BIP-113 addresses this by using the median of the previous 11 block timestamps.
Because the median of those values advances monotonically with the chain, it provides a more reliable consensus reference for locktime calculations.
This is important for protocols that rely on predictable delays.
What Is nSequence?
Every non-coinbase transaction input has an:
nSequence
field.
Bitcoin originally included sequence numbers for transaction-update concepts, but BIP-68 repurposed their semantics to support consensus-enforced relative locktimes.
This is what makes relative timelocks possible.
Instead of saying:
“This transaction can’t be used before block 900,000.”
a relative lock can say:
“This input must wait 144 blocks after the output it spends has reached the required age.”
That’s fundamentally different.
Relative Timelocks With BIP-68
BIP-68 defines how nSequence can encode a relative locktime.
It applies its new consensus meaning to transactions with:
version 2 or higher
and with the appropriate sequence-lock behavior enabled.
A sequence number can represent either:
A number of blocks
or:
A period of time
That allows much more flexible delayed-spending systems.
Relative Block-Based Timelocks
Suppose an output becomes confirmed at a particular block.
A transaction spending it could use a relative locktime requiring:
10 blocks
to pass.
The basic process looks like:
Parent output confirmed
↓
Wait 10 blocks
↓
Relative lock expires
↓
Transaction can become valid
This isn’t tied to a specific future block such as 900,000.
The countdown starts relative to the age of the output being spent.
BIP-68 defines this block-based relative locktime semantics.
Relative Time-Based Timelocks
BIP-68 also supports a time-based mode.
In this mode, the sequence value represents time in units of:
512 seconds
The time is measured using the blockchain’s Median Time Past rules rather than a local clock.
For example, a sequence value can represent a relative delay of approximately:
1 hour
or:
1 day
or another permitted period, subject to the encoding’s granularity and range.
The 512-second granularity means it isn’t designed to represent every exact second.
Why Is the Time Unit 512 Seconds?
512 seconds is:
2⁹ seconds
This makes the value efficient to encode inside the available sequence-number bits.
It also provides a reasonable relationship between time-based and block-based delays because Bitcoin blocks arrive roughly every ten minutes on average.
BIP-68 specifically chose this granularity for its relative time encoding.
The Relative Timelock Encoding
BIP-68 uses specific bits in nSequence.
The important ones are:
Bit 31
Controls whether the relative-locktime interpretation is disabled.
Bit 22
Determines whether the lock is:
block-based
or:
time-based
The lower 16 bits encode the actual relative lock value.
BIP-68 defines the relevant mask as:
0x0000ffff
and uses bit 22 to distinguish time-based locks.
You don’t normally need to manipulate these bits manually.
Wallet and protocol software handles the encoding.
CLTV and CSV in Script
The two opcodes can be summarized like this:
OP_CHECKLOCKTIMEVERIFY
Checks an absolute locktime.
It works with:
nLockTime
and is associated with BIP-65.
OP_CHECKSEQUENCEVERIFY
Checks a relative locktime.
It works with:
nSequence
and is associated with BIP-112 and BIP-68.
BIP-112 explains that CSV makes the relative sequence field available to Script so protocols can create spending paths that become valid only after the required age has passed.
An Easy Side-by-Side Example
Imagine two different Bitcoin outputs.
Output A — CLTV
The script says:
“You may spend this recovery path after block 900,000.”
That is absolute.
It points to a specific location in the future blockchain.
Output B — CSV
The script says:
“You may spend this recovery path 144 blocks after this output becomes eligible.”
That is relative.
The delay begins from the relevant output’s blockchain history.
So:
CLTV
Fixed future point
↓
Block 900,000
CSV
Relative age
↓
Output confirmation
↓
144 blocks
Why CSV Is Powerful for Lightning
Payment channels need relative delays.
Imagine a protocol creates a state where one party can publish a transaction, but another party needs a limited period in which to respond.
A relative timelock can create that response window.
BIP-112 specifically identifies payment channels and other phased protocols as important uses for OP_CHECKSEQUENCEVERIFY.
That’s why CSV is a major component of Bitcoin’s more advanced second-layer constructions.
Timelocks Can Be Combined
CLTV and CSV don’t have to be used alone.
Bitcoin Script can combine a timelock with:
A signature
A multisignature condition
A hash lock
Taproot
Miniscript
For example:
Bitcoin Output
|
┌───────┴───────┐
↓ ↓
Normal Path Recovery Path
2 signatures 1 signature
+
90-day delay
This allows the same output to have different spending rules depending on the circumstances.
A Recovery Wallet Example
Imagine you build a recovery system with:
Key A
Key B
Backup Key C
The normal path requires:
A + B
No delay.
But the recovery path requires:
C + 90-day timelock
The logic becomes:
Output
|
┌────────┴────────┐
↓ ↓
A + B C + Delay
Now 90 days
This gives the normal users immediate access while preserving a delayed emergency path.
The delay can also provide an important response window in some protocol designs.
Why Timelocks Don’t Guarantee a Precise Calendar Date
This is another important limitation.
Bitcoin blocks are not produced exactly every ten minutes.
The average is around ten minutes, but individual block intervals vary.
So a lock expressed as:
144 blocks
does not mean:
Exactly 24 hours.
It means:
144 additional blocks according to the consensus locktime rules.
Likewise, time-based conditions use Bitcoin’s consensus-defined time calculations rather than your phone’s exact clock.
This distinction matters whenever a protocol uses timelocks for deadlines.
Block-Based vs Time-Based Relative Locks
Relative locks therefore have two forms.
Block-Based
Example:
144 blocks
The required age is measured in block height.
Time-Based
Example:
Approximately 24 hours
The required age is encoded in 512-second units and evaluated using blockchain-derived time.
BIP-68 supports both modes through nSequence.
What Happens if You Set a Sequence Number Incorrectly?
Timelock construction is technically sensitive.
If the sequence number is encoded incorrectly, the intended relative lock may not exist.
For example, setting the disable flag can mean the sequence number isn’t interpreted as a relative timelock at all.
Likewise, mixing block-based and time-based expectations can produce a completely different condition from what the developer intended.
This is why application developers generally rely on established libraries and wallet infrastructure instead of manually constructing sequence values.
The Relationship Between BIP-65, BIP-68, BIP-112 and BIP-113
These BIPs work together.
BIP-65
Introduces:
OP_CHECKLOCKTIMEVERIFY
for absolute Script-enforced timelocks.
BIP-68
Defines:
Relative locktime semantics for nSequence.
BIP-112
Introduces:
OP_CHECKSEQUENCEVERIFY
so Script can inspect and enforce those relative lock conditions.
BIP-113
Defines:
Median Time Past
for locktime calculations involving time.
Together, they provide much of the foundation for Bitcoin’s modern timelock functionality.
The Complete Mental Model
You can think of the system as four layers:
Absolute lock
↓
nLockTime
↓
CLTV
↓
"Wait until this future point"
Relative lock
↓
nSequence
↓
CSV
↓
"Wait until this input is old enough"
Underneath the time-based rules, Bitcoin uses blockchain-derived timing rather than trusting one user’s local clock.
This gives developers a reliable way to make time part of Bitcoin’s spending logic.
Why Timelocks Matter
Before timelocks, Bitcoin’s basic spending logic was closer to:
Have the right authorization → spend
Timelocks add another dimension:
Have the right authorization + satisfy the required time condition → spend
That extra condition makes advanced protocols possible.
It can create:
Delayed recovery
Refund paths
Escrow arrangements
Payment channels
Lightning mechanisms
Time-based security windows
and other structured spending conditions.
Timelocks for Bitcoin Recovery
One of the most useful applications is creating a delayed recovery path.
Imagine a wallet normally requires two keys:
Key A + Key B
Both can spend immediately.
But you also want an emergency backup.
You could create another spending path using:
Backup Key + Timelock
The structure might look like:
Bitcoin Output
|
┌────────┴────────┐
↓ ↓
Normal Path Recovery Path
A + B Backup Key
Anytime + Delay
The normal path remains available.
The recovery path activates only after the required timelock condition is satisfied.
BIP-65 explicitly describes this kind of delayed recovery arrangement.
Timelocks and Bitcoin Inheritance
Timelocks can also be considered in inheritance planning.
Imagine someone wants a Bitcoin backup arrangement that becomes available only after a delay.
A simplified structure could be:
Normal owner → Spend normally
Recovery beneficiary → Spend after a long delay
The exact legal and technical design would need much more than a simple timelock. You would still need to think about key custody, backups, inheritance law, and how the beneficiary obtains the necessary signing credentials.
But Bitcoin’s scripting system provides the technical building block for making a recovery route time-dependent.
The important idea is:
Ownership conditions can change with time.
Timelocks and Escrow
Escrow is another classic use case.
Suppose Alice and Bob normally control funds together.
They use a 2-of-2 arrangement.
If everything goes well, both cooperate and spend the funds normally.
But what if Bob becomes unavailable?
A timelocked fallback can provide another route.
For example:
Before deadline:
Alice + Bob
After deadline:
Alice + Backup Key
BIP-65’s motivation section describes an escrow construction in which a third party gains access only after a specified delay.
The delay can therefore reduce the need to give the backup party immediate spending power.
Timelocked Refunds
Another useful pattern is a refund path.
Imagine two parties lock funds into a transaction for a protocol.
The normal spending route requires cooperation.
But they also need protection in case one participant disappears.
A timelocked refund can provide a fallback.
Conceptually:
Lock Funds
↓
Normal completion
↓
Spend normally
If protocol fails:
↓
Wait
↓
Refund path becomes available
BIP-65 specifically discusses non-interactive time-locked refunds and explains how script-enforced lock conditions can avoid some problems associated with pre-signed refund transactions.
Timelocks and Lightning
The Lightning Network makes extensive use of time-dependent spending conditions.
Payment channels must deal with situations where one party publishes an old or otherwise problematic state and the other party needs an opportunity to respond.
Relative timelocks provide part of that protection.
A simplified idea looks like:
Channel State
↓
On-chain Event
↓
Response Window
↓
Timelock Expires
↓
Fallback Spending Path
BIP-112 identifies relative locktime semantics as useful for bidirectional payment channels and other protocols where participants need a defined response period.
This is one reason timelocks are such an important part of Bitcoin’s broader ecosystem.
Timelocks With Taproot
Taproot gives developers more ways to organize spending conditions.
A Taproot output can commit to multiple script paths.
That means a timelocked recovery path can exist alongside a normal key-path or alternative script path.
A simplified design might look like:
Taproot Output
|
┌──────────┴──────────┐
↓ ↓
Key Path Script Path
Normal use Recovery branch
|
Timelock
|
Backup key
This can make complex spending policies easier to organize while keeping unused script paths out of the blockchain unless they are actually used.
Your existing Taproot, Script, Miniscript, and BIP-371 articles provide useful background for understanding these constructions.
Timelocks and Miniscript
Miniscript is particularly useful for expressing structured Bitcoin spending policies.
Instead of manually writing complicated Script conditions, developers can describe policies in a more structured form and compile them into Bitcoin Script.
That makes combinations such as:
signature + timelock
or:
multisig + delayed recovery
easier to reason about.
For example, a policy could conceptually express:
Alice and Bob can spend immediately
OR:
Alice plus a backup key can spend after a delay
The timelock supplies the time condition.
Miniscript provides a structured way to represent the policy.
Taproot can then provide a modern output structure for committing to the resulting scripts.
Timelocks Are Useful Because They Create Windows
A timelock isn’t always about permanently preventing spending.
Often, it creates a window of time in which different participants have different rights.
Imagine:
Immediately → Alice can spend
After 90 days → Backup key can recover
That creates two phases.
PHASE 1
Normal spending
↓
90-day delay
↓
PHASE 2
Recovery spending
This is a powerful concept for Bitcoin protocols.
Time isn’t just a restriction.
It can change the set of available spending paths.
Why Timelocks Can Be Dangerous
Timelocks are powerful, but they can also create serious mistakes when implemented incorrectly.
A developer needs to understand:
- Block-based vs time-based locks.
- Absolute vs relative locks.
nLockTime.nSequence.- Transaction version requirements.
- MTP-based time calculations.
- Script execution.
- The exact spending path being protected.
BIP-68, for example, applies its relative-locktime semantics to version 2-or-higher transactions and uses specific sequence-number bits for block/time modes.
A small mistake can produce a lock that behaves differently from what was intended.
Block Delays Are Not Exact Clock Delays
Suppose you create:
144-block relative timelock
It is tempting to say:
“That’s exactly one day.”
But it isn’t.
Bitcoin blocks are not produced exactly every ten minutes.
The average target interval is around ten minutes, but real block times vary.
So 144 blocks represent a blockchain-based delay, not a guaranteed 24-hour wall-clock timer.
Likewise, Bitcoin’s time-based lock calculations use consensus-defined median-time-past rules rather than relying on your computer clock.
A Timelock Doesn’t Move Your Bitcoin Somewhere Else
Another common misconception is that locking Bitcoin somehow transfers it to a special storage system.
It doesn’t.
The Bitcoin remains represented by a transaction output.
The difference is that the output’s spending conditions make certain transactions invalid until the required condition is satisfied.
So:
Timelock ≠ separate account
Timelock = additional spending condition
Can You Remove a Timelock?
Generally, you cannot simply decide to remove a consensus-enforced timelock after the output has been created.
The spending conditions are part of the output’s script or the relevant transaction rules.
If the condition says:
“Wait until block 900,000,”
you cannot simply create a transaction today that ignores that rule.
You must satisfy the actual conditions defined by the output.
This is precisely why timelocks are useful for security and contractual-style protocols.
Timelocks vs Simply Holding Bitcoin
There is a major difference between:
Choosing not to spend
and:
Making a spending path unavailable until later
If you simply keep Bitcoin in a normal wallet, the key holder may be able to spend it at any time.
A timelocked construction can impose a rule at the blockchain level.
That makes it useful when the restriction must apply regardless of someone’s intentions.
Common Timelock Mistakes
Mistake 1: Confusing CLTV and CSV
CLTV is associated with absolute locktime.
CSV is associated with relative locktime.
They are not interchangeable.
Mistake 2: Assuming 144 Blocks Means Exactly 24 Hours
It doesn’t.
Block production varies.
A block-based delay is measured in blockchain progression, not exact clock time.
Mistake 3: Treating a Timestamp Like a Local Alarm
Bitcoin uses consensus-defined time rules.
Time-based lock calculations use blockchain-derived timing rather than simply trusting your device’s clock.
Mistake 4: Assuming a Timelock Applies to the Entire Wallet
A timelock normally applies to a particular transaction or spending condition.
Other UTXOs can remain immediately spendable.
Mistake 5: Using Timelocks Without Testing the Recovery Path
A delayed recovery design is only useful if the recovery keys, scripts, derivation paths, and transaction construction actually work.
Complex Bitcoin custody arrangements should be tested carefully before storing significant funds.
Mistake 6: Giving the Backup Key Too Much Immediate Power
One reason timelocks are useful is that a backup participant can be delayed.
Giving a backup key immediate spending access may defeat part of the security model the timelock was intended to provide.
Frequently Asked Questions
What is a Bitcoin timelock?
A Bitcoin timelock is a spending condition that prevents a transaction or spending path from becoming valid until a specified blockchain condition is satisfied.
What is the difference between absolute and relative timelocks?
An absolute timelock targets a specific future block height or time. A relative timelock measures a required age from an earlier blockchain event.
What is CLTV?
CLTV, or OP_CHECKLOCKTIMEVERIFY, is a Bitcoin Script opcode introduced by BIP-65 for enforcing absolute locktime conditions.
What is CSV?
CSV, or OP_CHECKSEQUENCEVERIFY, is a Script opcode introduced by BIP-112 for enforcing relative locktime conditions using the sequence-number semantics defined by BIP-68.
What is nLockTime?
nLockTime is a transaction field that can specify a block height or time before which the transaction cannot be mined under the applicable locktime rules.
What is nSequence?
nSequence is a per-input field. Under BIP-68’s rules, it can encode a relative locktime based on block count or elapsed time.
What is Median Time Past?
Median Time Past, or MTP, is a blockchain-derived time value based on the median timestamps of recent blocks. BIP-113 uses MTP as the endpoint for consensus locktime calculations involving time.
Can Bitcoin be permanently locked with a timelock?
A timelock can make a particular spending path unavailable until a future condition is reached. Whether funds remain inaccessible indefinitely depends on the complete spending script.
Can I use timelocks for inheritance?
Yes, timelocked spending paths can be part of a technically designed inheritance or recovery arrangement, although legal and custody planning are separate issues.
Are timelocks used by Lightning?
Yes. Relative timelocks are important building blocks for payment-channel protocols, including Lightning-related constructions.
Does a Bitcoin timelock use my computer’s clock?
No. Consensus-enforced time-based lock calculations use Bitcoin’s blockchain-derived timing rules, including Median Time Past.
Can a timelocked transaction be broadcast early?
It can sometimes be constructed and transmitted before it becomes valid, but nodes cannot confirm it before the required consensus condition is satisfied. The exact relay behavior depends on the transaction and node policy.
Does a timelock increase Bitcoin transaction fees?
Not inherently. A timelock is a spending condition; transaction fees still depend on transaction size, fee rate, and network conditions.
Bitcoin Timelocks in One Example
Imagine a wallet creates an output with two spending paths.
Path 1
Alice + Bob
No delay.
Path 2
Alice + Backup Key
90-day relative delay.
The result is:
Bitcoin Output
|
┌─────────┴─────────┐
↓ ↓
Normal Path Recovery Path
Alice + Bob Alice + Backup
↓ +
Spend now Wait 90 days
↓
Spend
The same output can therefore provide:
Immediate normal access
and:
Delayed emergency recovery
That is the power of Bitcoin timelocks.
The Bigger Picture
Bitcoin began with a relatively simple spending idea:
Provide valid authorization → spend the output.
Timelocks add another dimension:
Provide valid authorization + satisfy the time condition → spend the output.
That makes Bitcoin Script considerably more expressive.
Time can determine:
- When a refund becomes available.
- When a backup key can recover funds.
- How long a participant has to react.
- When an escrow fallback activates.
- When a payment-channel path can be used.
- Which spending branch is currently available.
CLTV and CSV provide two different ways to build those conditions.
CLTV asks:
“Has this specific future point been reached?”
CSV asks:
“Has this output been old enough?”
Together with BIP-68 and BIP-113, they give Bitcoin protocols a way to use blockchain time as part of the spending logic.
Final Thoughts
Bitcoin timelocks are one of those features that look simple on the surface but become extremely powerful when combined with Bitcoin’s scripting system.
A timelock can turn time into part of the security model.
Instead of relying entirely on:
“Who has the key?”
a Bitcoin spending policy can also ask:
“Has the required amount of time passed?”
That makes possible:
Delayed recovery
Escrow
Refunds
Inheritance-style recovery structures
Payment channels
Lightning mechanisms
and other advanced protocols.
The two most important concepts to remember are:
Absolute timelock → a specific future point
Relative timelock → a delay measured from the relevant blockchain event
CLTV handles absolute Script-based lock conditions.
CSV handles relative Script-based lock conditions.
BIP-68 gives nSequence its relative-locktime semantics.
BIP-113 provides the consensus time reference used for time-based lock calculations.
And together, these mechanisms allow Bitcoin to make time itself part of a transaction’s spending rules.
