Bitcoin timelocks: absolute and relative delays
Distinguish transaction locktime from script-enforced conditions and plan recovery without assuming an automatic future payment.
The quick answer
Timelocks limit when a spending transaction can be valid. Absolute locks refer to a height or time threshold; relative locks depend on the age of an output under the applicable rules.
Eligibility is not automatic execution
Transaction nLockTime can delay a particular transaction, while script conditions such as CLTV or CSV can constrain a spending path. Signatures, fees, correct fields and eventual inclusion are still required.
Step by step
- 1
Define the intended condition
Choose whether you need a calendar-related threshold, block height or relative age. Check every alternative spending path; an unlocked alternative changes what is protected.
- 2
Use supported, reviewed tooling
Follow a wallet or protocol's documented policy rather than inventing a script for savings. Test on a separate network and understand the time and sequence semantics.
- 3
Plan spending and recovery
Preserve the script or descriptor and signing keys. Allow for fees, block timing and any later fee-bump process before relying on the lock.
Worked example
A relative delay of 144 blocks is roughly a day at a ten-minute average, but can take longer or less. It is not a promise to pay at a specific clock time.
Before you continue
A related question
Will a timelock send funds when it expires?
No. Expiry can make a spend eligible; someone must still construct, sign and broadcast a valid transaction that is included in a block.
Try it with a tool
Sources & further reading
Source links checked on 15 Oct 2026. Examples explain the mechanics; provider fees and features can change.
