How does the mechanism work?

The transaction-level nLockTime field uses height when below 500,000,000 and a time interpretation at or above that threshold. A nonzero locktime is ineffective if every input has its final sequence value. To apply a transaction lock, the sequence settings must leave it active. Script conditions can also require a minimum locktime through CHECKLOCKTIMEVERIFY.

Absolute time-based finality uses median time past under the applicable rules, rather than your device clock. Median time past is computed from the preceding block timestamps as defined by the protocol. That choice gives validation a common chain-derived reference. It does not make block timestamps precise records of when a person pressed send.

Relative locks use the input’s sequence field under the version and flag requirements of BIP 68. A transaction version of at least 2 is required for those sequence-lock rules. The disable flag can turn the relative interpretation off for an input. CHECKSEQUENCEVERIFY lets a script require a compatible relative lock rather than relying on a sender’s voluntary delay.

When several inputs have relative locks, the transaction must satisfy every applicable requirement. The easiest input does not override the latest one. Absolute and relative conditions may also coexist, so passing one comparison does not imply the transaction is ready. Check the parent confirmation context, field flags and script requirements together. This is especially relevant when a drawing shows a fallback recovery path: the delay describes one part of the path, while signatures and other conditions still apply. A displayed countdown should therefore be understood as an interpretation of chain conditions, not a command that will execute the spend automatically.

How do absolute and relative timelocks differ?An absolute timelock constrains a transaction against a block height or time threshold. A relative timelock constrains spending according to the age of an input. Neither automatically sends funds when its threshold is reached.Identify lock and unitsCompare chain contextEligible, still needsinclusion
Eligibility is a validation condition. It is separate from relay, mining and a calendar reminder.

How do the protocol numbers work in an example?

For an invented height example, set active nLockTime to 900,000. Transaction finality compares it strictly with the candidate block height. A candidate at height 900,000 is too early; height 900,001 passes this absolute-height comparison. All other spending rules must still pass. Equality is an easy boundary to misread when a display says only “locked until”.

For a separate relative example, let an input’s creating transaction confirm at height 900,000. A block-based relative delay of 10 makes height 900,010 the earliest candidate height satisfying that input’s age condition. Other inputs can impose later requirements. Moving the parent confirmation through a reorganisation changes the context for this calculation.

Time-based relative locks have a granularity of 512 seconds. A value of 2 therefore represents 1,024 seconds in the specified median-time calculation, not two seconds on a stopwatch. The reference uses chain medians associated with the confirming block’s ancestry. Do not substitute the parent transaction’s displayed arrival time or a website’s timestamp into the consensus comparison.

Different height boundaries for two example locksAn active absolute nLockTime of 900000 is first eligible at candidate height 900001. A relative delay of 10 for an output confirmed at 900000 is first eligible at 900010. Both examples still need all other rules to pass.Absolute nLockTime: 900,000First eligible: 900,001Parent height: 900,000Relative 10 → 900,010
The diagram follows the worked example. Sample heights and amounts illustrate the sourced rules.

Common misunderstandings

A timelock normally prevents an early spend; it does not force a later one. Once eligible, a transaction still needs authorisation and inclusion. Unless the output’s script requires the lock, someone with suitable authority may construct another spend with different transaction fields.

Absolute and relative locks are not interchangeable calendar dates. A height lock follows block production. A relative age follows its parent’s confirmation context. A time lock uses the chain’s median-time rules. Each can diverge from an intuitive wall-clock countdown.

A lock can coexist with other conditions. Meeting the time requirement does not replace a signature, resolve a conflicting spend or make missing recovery information reappear. Read the full script and transaction context before claiming that one number proves an output is spendable.

Check yourself

Does an active height nLockTime of 900,000 pass in candidate block 900,000?

Reveal the answer

No. The absolute finality comparison is strict, so 900,001 is the first eligible height in this example. Relative-height locks use a different calculation.

What does this diagram leave out?

These examples show eligibility only. They do not construct a recovery script, predict confirmation or recommend a lock duration. Exact field encoding, sequence flags and script checks must agree before a real transaction can be used.