Median Time Past (MTP)

What Is Median Time Past?

Median Time Past (MTP) is the method Bitcoin uses to determine "current time" for consensus purposes. Instead of relying on any single clock or timestamp, MTP takes the timestamps from the previous 11 block headers, sorts them, and selects the middle value (the 6th in sorted order). This median becomes the network's agreed-upon time reference.

Bitcoin faces a fundamental challenge: it is a decentralized system with no central time authority. Each node has its own local clock, and miners set the timestamp in their blocks manually. A single miner's timestamp could be inaccurate or deliberately manipulated. MTP solves this by aggregating multiple timestamps into a single robust measure that resists tampering from any minority of miners.

The concept was originally proposed by Gregory Maxwell in 2013 and formalized in BIP 113, authored by Thomas Kerin and Mark Friedenbach. It activated as part of the CSV soft fork deployment at block 419,328 on July 4, 2016.

How It Works

The MTP calculation is straightforward. Given any block in the chain, a node collects the timestamps from the 11 blocks immediately preceding it, sorts them in ascending order, and returns the middle value:

// Simplified MTP calculation
function getMedianTimePast(block) {
  const timestamps = [];
  let current = block.previousBlock;

  // Collect timestamps from the previous 11 blocks
  for (let i = 0; i < 11 && current; i++) {
    timestamps.push(current.timestamp);
    current = current.previousBlock;
  }

  // Sort and return the median (6th value)
  timestamps.sort((a, b) => a - b);
  return timestamps[Math.floor(timestamps.length / 2)];
}

Because the window uses an odd number (11), the result is always a single unambiguous value. And because it is a median, MTP is monotonically increasing: adding a new block to the chain can only keep MTP the same or push it forward, never backward.

Block Timestamp Rules

Bitcoin enforces two rules on the timestamp a miner places in a block header:

1. The timestamp must be strictly greater than the MTP of the previous 11 blocks. This is a hard consensus rule: blocks violating it are invalid and rejected by all nodes. It ensures that MTP always moves forward.
2. The timestamp must be no more than 2 hours ahead of network-adjusted time. Network-adjusted time is computed by collecting UTC timestamps from connected peers, calculating the median offset, and adding it to the node's local clock (capped at 70 minutes from local system time). This prevents miners from pushing timestamps far into the future.

These two constraints create a valid range for each block's timestamp. Importantly, block timestamps do not need to be strictly ordered: block N+1 can have an earlier timestamp than block N, as long as it exceeds the MTP. This happens regularly due to clock drift between miners, which is exactly why MTP exists as a stable reference.

Why 11 Blocks?

The choice of 11 blocks aligns with Bitcoin's security model. At a target block time of 10 minutes, 11 blocks span roughly 110 minutes. Using an odd number ensures the median is always a single value. The window is large enough that manipulating MTP requires majority hashrate control (at least 6 of 11 blocks), but small enough that MTP stays reasonably close to real wall-clock time, typically lagging by about one hour.

Why Bitcoin Needs MTP

Before BIP 113, Bitcoin evaluated time-based nLockTime values against the timestamp of the block containing the transaction. This created a vulnerability: a miner could set their block's timestamp up to 2 hours in the future, causing time-locked transactions to become spendable earlier than intended.

This was not just a theoretical concern. Miners had a financial incentive to inflate timestamps: doing so let them include not-yet-mature time-locked transactions and collect their fees. A single dishonest miner with even a small share of hashrate could accelerate timelocks by up to 2 hours at will.

MTP eliminates this attack vector. To shift MTP meaningfully, an attacker would need to have mined 6 of the last 11 blocks, requiring over 50% of recent hashrate. With just 1% of hashrate, the expected wait to solve 6 of 11 consecutive blocks exceeds 43,000 years. Even with 50% hashrate, solving 6 consecutive blocks (probability 1/64) only happens roughly every 12 hours, and the maximum shift is still bounded by the 2-hour future limit on individual timestamps.

Use Cases

Absolute Timelocks (OP_CHECKLOCKTIMEVERIFY)

OP_CHECKLOCKTIMEVERIFY (CLTV), defined in BIP 65, makes a transaction output unspendable until a specific point in time. For time-based locks (as opposed to block height locks), CLTV compares the transaction's nLockTime against the block's time reference. Since BIP 113, that reference is MTP rather than the block's own timestamp.

The threshold between height-based and time-based interpretation is 500,000,000: nLockTime values below this are treated as block heights, while values at or above it are treated as Unix timestamps evaluated against MTP.

Relative Timelocks (OP_CHECKSEQUENCEVERIFY)

OP_CHECKSEQUENCEVERIFY (CSV), defined in BIP 112, enforces relative timelocks: an output cannot be spent until a certain amount of time has elapsed since it was confirmed on-chain. For time-based relative locks, the nSequence field specifies the delay in multiples of 512 seconds.

The elapsed time is measured from the MTP of the block prior to the one containing the output being spent. CSV was deployed simultaneously with BIP 113, so it has always used MTP as its time reference.

Lightning Network Channels

Lightning channels rely heavily on timelocks enforced by CLTV and CSV. When a channel is force-closed, the party broadcasting the commitment transaction must wait through a CSV-enforced delay before claiming their funds. This delay, measured against MTP, gives the counterparty time to broadcast a penalty transaction if an outdated state was published. MTP ensures these time-based security guarantees cannot be circumvented by miner timestamp manipulation.

For a deeper look at how CLTV and CSV interact in practice, see the research article on Bitcoin timelocks.

Time-Locked Contracts

Hash Time-Locked Contracts (HTLCs), Discreet Log Contracts (DLCs), and other conditional payment schemes use timelocks as refund mechanisms. If one party fails to act within the time window, the other party can reclaim funds after the timelock expires. MTP is the clock against which these deadlines are measured, providing consistent enforcement across all nodes regardless of their local system time.

MTP and Soft Fork Activation

BIP 113 activated as part of a combined deployment alongside BIP 68 (consensus-enforced sequence number relative locks) and BIP 112 (CSV). This deployment used BIP 9 versionbits signaling on bit 0.

During the signaling window (blocks 415,296 to 417,311), 1,946 of 2,016 blocks signaled support (96.53%), far exceeding the 95% threshold. The deployment locked in at block 417,312 on June 21, 2016, and activated at block 419,328 on July 4, 2016.

The practical impact of activation was that time-locked transactions needed approximately one additional hour before they could be confirmed, since MTP lags behind real time by roughly that amount. This was considered a worthwhile tradeoff for the security improvement.

Risks and Considerations

MTP Lag

Because MTP is the median of the last 11 blocks (spanning roughly 110 minutes at the target block time), it typically lags behind real wall-clock time by about one hour. This means time-locked transactions become spendable slightly later than a naive wall-clock calculation would suggest. Applications and wallets that set time-based locks should account for this lag when choosing lock times.

Time Warp Attack

An attacker controlling over 50% of hashrate could theoretically manipulate timestamps to affect the difficulty adjustment algorithm. By setting block timestamps to advance minimally (just 1 second above MTP), an attacker could make a 2,016-block retarget window appear to have taken far longer than it actually did, triggering difficulty reductions of up to 75% per period (the maximum allowed adjustment). This is known as the "time warp attack" and would require sustained majority hashrate, making it impractical against Bitcoin's current network. The Great Consensus Cleanup proposal includes a fix for this vulnerability.

Timestamp Ordering Assumptions

Developers building on Bitcoin should not assume block timestamps are strictly ordered. Block N+1 can have an earlier timestamp than block N. Any application logic that depends on time should use MTP (which is monotonically increasing) rather than individual block timestamps. The Bitcoin Core reference implementation provides a GetMedianTimePast() method for this purpose.

Year 2106 Limit

Bitcoin stores block timestamps as unsigned 32-bit integers, which overflow around the year 2106. While this avoids the more immediate Year 2038 problem (which affects signed 32-bit integers), it will eventually require a protocol change. This is a known long-term consideration rather than an immediate risk.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.