Bitcoin Median Time Past: Block Timestamp Manipulation Explained
You're a miner with 15% of Bitcoin's hashrate. Not a majority. Not even close. But you've noticed something: you set your own block timestamps. The protocol has limits, sure, but what if you nudge every block you find two hours into the future? If the difficulty algorithm thinks blocks arrived faster than they did, it adjusts upward. If it thinks they arrived slower, it eases off. You want it to ease off. No stolen keys, no double-spend, just a manipulated clock and cheaper blocks for the next 2016-block epoch.
Median Time Past is the rule that makes this not work.
What MTP Actually Calculates
Every Bitcoin block header contains a timestamp field. Miners set this themselves. The protocol does impose limits, but the core defence against timestamp abuse isn't a hard cap: it's a median.
Before accepting a new block, every full node checks that its timestamp is strictly greater than the Median Time Past: the median timestamp of the eleven blocks immediately preceding it. Not the average. The median. That single word does a lot of work.
Here's the mechanism in concrete terms. Suppose the last eleven block timestamps, in order, are:
`100, 102, 103, 105, 107, 108, 110, 111, 113, 115, 116`
The median of those eleven values is `108`. Any new block claiming a timestamp of 108 or earlier gets rejected outright, regardless of how much proof-of-work it carries. The new block must claim a time strictly after 108.
Now suppose a miner submits a block timestamped `90`, trying to rewind the clock. The network doesn't care about the proof-of-work. Rejected. To move the MTP backward, an attacker would need to control a majority of those eleven historical blocks, and those blocks are already buried in the chain. A minority miner can't rewrite them.
Moving MTP forward aggressively is its own problem. Bitcoin's other timestamp rule caps how far forward a block can be set: no more than two hours ahead of the node's local network-adjusted time. So the maximum drift any single block can introduce is bounded. Getting eleven consecutive blocks with maximally inflated timestamps would require something close to sustained majority control, which is a different threat model entirely.
A Worked Scenario: The 15% Miner's Problem
Call the miner Yusuf. He controls 150 petahashes out of a 1,000-petahash network. On average, he finds roughly one in every seven blocks. His plan: stamp every block he mines two hours into the future, hoping to inflate the MTP and make the difficulty algorithm believe blocks are arriving faster than they are.
The difficulty algorithm looks at the timestamps of the first and last block in a 2016-block epoch. If the span looks shorter than two weeks, difficulty rises. If it looks longer, difficulty drops. Yusuf wants it to look longer, so the chain gets easier.
In practice, Yusuf finds maybe 288 of those 2016 blocks (15% of them). Each of his blocks is timestamped two hours ahead. The other 1,728 blocks are stamped honestly by everyone else. The MTP at any given point is dominated by blocks Yusuf didn't mine. His inflated timestamps creep into the rolling eleven-block window occasionally, but they never constitute a majority of it. The median barely moves.
Run the numbers: if two of the eleven most recent blocks are Yusuf's and both are inflated by two hours (7,200 seconds), the median shifts by exactly zero. His two blocks sit at positions 10 and 11 in a sorted list of eleven. You need six of eleven to move the median. Yusuf controls fewer than two on average. He's not even in the game.
What People Get Wrong About This Rule
The common misconception is that MTP prevents all timestamp manipulation. It doesn't.
It prevents backward manipulation absolutely, and it severely limits forward manipulation for anyone without majority hashrate. A miner with 51% could, in theory, systematically inflate the MTP over time. That's real. But that's also a consequence of 51% attacks in general, which carry separate and well-documented costs. Conflating the two muddies the actual guarantee MTP provides.
The second misconception is that MTP's only job is blocking dishonest miners. It also governs `nLockTime` and `OP_CHECKLOCKTIMEVERIFY` validation: those opcodes compare against MTP rather than wall-clock time. A transaction locked until time `T` won't be valid until MTP exceeds `T`. I'd flag this to any developer building time-sensitive contracts, because MTP typically lags real time by about an hour, sometimes more during slow block periods. That lag is a feature of the median mechanic, not a bug, but it will bite you if you're not expecting it.
Think of MTP as a ratchet rather than a clock: it clicks forward, it never clicks back, and each click is constrained by what came before. Eleven numbers, one median function, and the manipulation surface collapses to something only a majority attacker could exploit.
The honest miner pays no cost at all. Set a reasonable timestamp, get your block accepted. The entire burden of the rule lands on whoever is lying, and it scales directly with how much they're lying. That asymmetry is the point.