Bitcoin timelocks: derive when a restricted spend is eligible
A Bitcoin timelock is a transaction-validity condition, not a project team’s promised token-release date. Determining whether a restricted spend is eligible requires the relevant script, transaction fields, confirmation history and proposed inclusion block. A calendar label alone cannot establish that all conditions are satisfied.
BIP 68 specifies relative lock-time semantics using transaction sequence fields. Apply its activation and encoding conditions before interpreting a field as a delay. The worked example below uses block-based predicates; time-based locks require their own consensus clock and cannot be replaced by a wall-clock countdown.
List every applicable condition
Identify the outpoint, creation block, spending script and candidate transaction version and fields. Separate absolute conditions from relative conditions. An absolute condition refers to a height or consensus time threshold; a relative condition depends on the age of the referenced output under the applicable rules.
Do not assume that any nonzero sequence number means a relative lock. Flags, encoding and transaction version determine its meaning. Also inspect whether the selected script branch requires signatures, a hash preimage or another condition. Satisfying a delay is only one part of spend validity.
For a block-based analysis, express each condition as a predicate in candidate inclusion height H. Keep strict and non-strict inequalities explicit. Off-by-one mistakes are easy when a display says “unlocks at block X” without explaining whether X itself is valid.
Hypothetical absolute and relative restrictions
Assume a fictional output confirms at height 1,000. The correctly decoded relative condition permits a candidate spend when H ≥ 1,010. Suppose the same candidate also has an active absolute condition expressed as H > 1,050. These are stipulated predicates for the example, not universal defaults for all scripts.
| Candidate height | Relative condition | Absolute condition | Combined height eligibility |
|---|---|---|---|
| 1,009 | Fails | Fails | No |
| 1,010 | Passes | Fails | No |
| 1,050 | Passes | Fails | No |
| 1,051 | Passes | Passes | Yes, subject to other rules |
The first height passing both is 1,051, not 1,010. Taking the earlier date because one lock has expired would be wrong. The combined test is a conjunction: all applicable conditions must pass.
Now suppose the output instead confirms at height 1,045 while retaining a relative ten-block condition. Its relative boundary shifts to H ≥ 1,055, and the combined earliest height becomes 1,055. Relative locks move with the origin’s confirmation; an absolute-only countdown misses this dependency.
Keep clock and access assumptions visible
For time-based conditions, identify the applicable median-time-past reference and the encoded time units. Do not convert an expected number of blocks into a guaranteed time of day. Actual block intervals vary, and the consensus clock has its own definition.
Keep the chain reference and rerun after a relevant reorganization. If an input’s confirmation history changes, the relative condition may need recomputation. A height attached to an output on a removed branch is not sufficient evidence for the selected chain.
After height or time conditions pass, verify that the intended party can satisfy the remaining script. A matured refund branch might be available to one participant but not another. Published script conditions do not establish that anyone still possesses the necessary key or secret.
The deliverable is a condition table, an earliest-eligible boundary under a stated chain and the remaining access requirements. It is not a guarantee of immediate inclusion, a legal entitlement opinion or a prediction of selling pressure. Recheck after candidate transaction changes, altered confirmation history or evidence that a different script branch will be used.
Check every input of a multi-input transaction. One unlocked input cannot make the complete transaction eligible while another input’s relative condition still fails. Preserve the per-input calculation and report the binding condition. A transaction-level summary should be derived from those rows rather than copied from the least restrictive input or from the wallet’s oldest output.
FAQ
Does an expired timelock guarantee immediate spending?
No. Other script and transaction conditions, key access and eventual block inclusion still matter.
Can a relative lock be converted into a fixed release date?
Only as a scenario tied to confirmation and clock assumptions. Its origin and actual consensus conditions determine eligibility.