Calculate median time past with an eleven-block example and understand why Bitcoin timelocks do not promise an exact wall-clock release time.
Block time is not a precise clock reading
A block header contains a timestamp selected by its miner within the applicable rules. It is useful chain data, but it is not a trusted observation of the moment every transaction happened. Consecutive block timestamps can differ from the order or spacing a person expects from a wall clock.
Bitcoin needs a reproducible time reference for consensus decisions. Nodes must be able to calculate the same result from the same chain data, without asking a website what time it is. Median time past, usually shortened to MTP, uses recent block timestamps for that purpose.
Calculate the middle, not the average
For an established chain with eleven available headers, sort their timestamps and choose the sixth value. One unusually large value does not directly pull the result upward the way it pulls an arithmetic average. The recent window still represents miner-supplied observations, so MTP should not be described as a perfect civil-time clock.
An illustrative eleven-header window
Imagine timestamp offsets of 0, 60, 120, 180, 240, 300, 360, 420, 480, 540 and 9,000 seconds from a shared starting point. Their median is 300 seconds, the sixth value. Their average is much higher because of the last entry. These offsets illustrate the calculation; they are not a claim about a particular valid chain segment.
Apply the right reference to the right rule
BIP 113 uses the previous block's MTP when evaluating time-based absolute transaction locktime for inclusion in a candidate block. This distinction matters: the candidate miner cannot simply choose a later candidate timestamp to make that particular check pass.
Height-based locktimes still refer to block heights. Transaction sequence settings also determine whether absolute locktime is enabled, and relative timelocks have additional rules. A decoder showing a time-looking number has not yet explained all the conditions for spending. Read Locktime and sequence before treating one field as a complete payment schedule.
Eligibility is not a confirmation appointment
A timelock prevents confirmation before the applicable conditions are satisfied. It does not reserve block space or instruct a miner to include the transaction immediately afterward. The transaction still needs valid signatures, available inputs, appropriate fees and propagation.
Suppose a service promises delivery when a time-locked payment confirms. Display the current state as “not yet eligible”, “eligible but unconfirmed” or “confirmed”, using the relevant evidence. Showing a countdown to guaranteed confirmation would hide the most important uncertainty from the customer.
Read explorer dates with their limits
An explorer may display the block timestamp, local first-seen time and confirmation status. Those fields answer different questions. First-seen time is one observer's record, while a block timestamp is supplied in the header. Neither establishes when an individual person created or signed a transaction.
For accounting exports, label the chosen date explicitly and preserve the block reference. For a timelock investigation, use the rule's chain-derived reference rather than comparing the displayed date with your laptop's clock. That keeps both calculations and user explanations reproducible.
Sources and further reading
Key takeaways
- MTP uses a median of recent block timestamps rather than an arithmetic average.
- Time-based absolute locktime checks use the previous block’s MTP under BIP 113.
- Passing a timelock makes a transaction eligible; it does not guarantee immediate confirmation.
Common questions
Does MTP identify the exact time a payment was sent?
No. It is a chain-derived reference used by particular rules, not an individual transaction creation timestamp.
Will a transaction confirm as soon as its timelock passes?
Not necessarily. It still needs to satisfy other validity conditions and be selected for a block.