# Median time past: Bitcoin’s shared time reference

Calculate median time past with an eleven-block example and understand why Bitcoin timelocks do not promise an exact wall-clock release time.

Canonical page: https://mybitcoinexplorer.com/learn/median-time-past
Topic: Blocks and the blockchain
Published: 2026-10-31
Updated: 2026-10-31

> Implementation examples refer to Bitcoin Core 30.0. File layouts and operational behavior can change; check the documentation for your installed version.

## 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.

> Diagram: A shared time reference comes from chain data — Recent headers: up to eleven → Sort timestamps: numerical order → Middle value: median → Locktime check: candidate eligibility

## 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.

### Worked example: 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](https://mybitcoinexplorer.com/learn/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.

## 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.

## Sources and further reading

- [BIP 113: median time past for locktime](https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki)
- [Core 30.0: finality checks at the chain tip](https://github.com/bitcoin/bitcoin/blob/v30.0/src/validation.cpp)

## Related lessons

- [Block timestamps](https://mybitcoinexplorer.com/learn/block-timestamps)
- [Locktime and sequence](https://mybitcoinexplorer.com/learn/locktime-and-sequence)
- [What is a Bitcoin confirmation?](https://mybitcoinexplorer.com/learn/bitcoin-confirmations)