nLockTime sets an absolute boundary
The transaction-level nLockTime field is interpreted as a block height when below 500,000,000 and as a Unix timestamp when at or above that threshold. A transaction with an active locktime is non-final until the relevant chain boundary has passed.
At least one input must use a non-final nSequence value for nLockTime to be effective. Time-based absolute locks are evaluated using the median time past of recent blocks rather than a miner's single header timestamp.
nSequence can encode a relative delay
BIP68 gives nSequence a consensus meaning for version 2 or later transactions. Unless its disable flag is set, an input can require that its referenced output age by a number of blocks or by intervals of 512 seconds before the spend is valid.
Relative locks start from confirmation of the spent output, so the same template can express a delay without knowing a future absolute block height in advance.
CLTV and CSV enforce locks inside Script
CHECKLOCKTIMEVERIFY, introduced by BIP65, checks a value from the script against the transaction's nLockTime and requires compatible lock types. It is commonly used to make one spending branch unavailable until a chosen height or time.
CHECKSEQUENCEVERIFY, introduced by BIP112, checks relative-lock conditions against the input's nSequence. It works with BIP68 semantics to make a branch spendable only after the previous output has aged sufficiently.
Wallets combine time with authority
A recovery policy might allow two keys to spend immediately but one recovery key only after a delay. Payment protocols can use hash conditions and relative delays so a participant has time to react before an alternative path becomes available.
The lock only controls timing. The spender must still satisfy every signature, hash and script condition, and the transaction must pass all other consensus rules.
Do not confuse consensus locks with wallet scheduling
A wallet interface can promise to broadcast a transaction later without encoding an on-chain timelock. That promise depends on the wallet service remaining available. Conversely, a consensus timelock can be visible in a transaction or script and is enforced by validating nodes.
Locktime construction has edge cases around finality, sequence values, fee replacement and off-by-one boundaries. Test policies with maintained tools on regtest or signet before using them with real funds.
Visual recap
Four ways timing enters a spend
Absolute and relative transaction fields can be checked directly or enforced by a selected script path.
Choose height or time
Set nLockTime or nSequence
Add CLTV or CSV branch
Satisfy signatures
Reach boundary
Nodes validate spend
Key vocabulary
Terms worth knowing
- Absolute timelock
- A boundary expressed as a specific block height or time.
- Relative timelock
- A delay measured from confirmation of the output being spent.
- Median time past
- The median timestamp of recent blocks, used for consensus time comparisons instead of one miner-provided timestamp.
Worked example
A delayed recovery branch
A wallet policy permits two everyday keys to spend immediately, while one recovery key may spend only after a relative delay.
- 1Define the immediate multisignature branch
- 2Define a CSV-delayed recovery branch
- 3Confirm the delay begins when the output confirms
- 4Keep policy and keys backed up
- 5Test both paths with valueless regtest coins
A delay can create response time without weakening the signatures required by either branch, but the entire policy must remain recoverable.
Common misconceptions
What learners often get wrong
Misconception
A timelock releases bitcoin to anyone when time expires.
More accurate
The chosen spending path must still satisfy every key, signature and script requirement.
Misconception
A wallet's scheduled-send feature is always an on-chain timelock.
More accurate
It may only be a local promise to broadcast later; inspect the transaction or script to know what nodes enforce.
Try it yourself
Classify four fictional policies before writing any script.
- Mark each boundary absolute or relative
- Choose block-based or time-based measurement
- Identify the signatures still required
- State when the delay starts
- Identify how you would test boundary behavior safely
Use fictional values and public information only. Never enter seed words, private keys or other wallet secrets into a learning exercise.
Key takeaways
- nLockTime expresses an absolute height or time boundary.
- BIP68 uses nSequence to express a delay relative to the spent output.
- CLTV checks absolute-lock conditions inside Script.
- CSV checks relative-lock conditions inside Script.
- Timelocks delay authorization paths but never replace the required signatures or scripts.
Lesson recap
Check what you learned
Reveal each model answer, then honestly mark whether you understood it or need another review.
1 of 3
Recall
Does reaching a timelock boundary allow anyone to spend the output?
References
