Bitcoin's Median Time Past Rule Prevents Miners From Gaming Your Timelocks

You've just locked 0.5 BTC behind a timestamp condition. The script is clean, the logic is sound, and you walk away assuming the coins won't move until the clock says so. Then you remember: the miner who builds the next block also sets the clock.

That's the problem. The `nTime` field in every block header is a number miners fill in themselves. Bitcoin's answer to this is Median Time Past, MTP, and I think it's one of the most underappreciated pieces of engineering in the protocol.

The Timestamp Field Is Not a Clock

Consensus rules impose two loose constraints on `nTime`. The timestamp can't run more than two hours ahead of network-adjusted time, and it must exceed the median of the last eleven blocks. That second constraint is MTP.

Computing it takes about three seconds to describe: grab the timestamps of the eleven most recent blocks, sort them, take the sixth value. That number is the "official" time for script evaluation. No single miner controls it, because no single miner produced all eleven blocks. It's a trailing window, not a live reading. Think of it less like a clock and more like a ship's position fixed by averaging several imperfect sextant readings, none of which any one navigator can quietly falsify.

So when a `CHECKLOCKTIMEVERIFY` (CLTV) script says "this output cannot be spent before Unix timestamp 1,700,000,000," the node ignores what the current block claims the time is. It checks whether MTP has crossed that threshold. The current miner's timestamp is one data point in eleven, and it only influences MTP after the fact, once the block is buried in history.

The practical implication is sharp: to unlock a CLTV-protected coin early, a miner would need to drag roughly six preceding blocks' timestamps forward far enough to shift the median. Other miners produced those blocks. The two-hour cap limits how far any single timestamp can be inflated. Coordinating six-plus miners to falsify timestamps in concert is an entirely different class of attack, well beyond any solo bad actor, and economically irrational even for a majority-hashrate coalition given what exposure of the scheme would cost them.

A Worked Scenario

Alice locks 0.5 BTC in a payment channel output with a CLTV refund path that opens at MTP block 840,050. Bob is the miner for block 840,049. He wants the refund early.

Bob sets his block timestamp as far forward as the two-hour cap allows. The block is accepted. Now the chain carries one inflated timestamp. MTP for block 840,050 is still the median of blocks 840,039 through 840,049, sorted. Bob's block is one of those eleven. Moving a single value in an eleven-element sorted set shifts the median by much less than the full inflation, often nothing, if the honest timestamps cluster tightly. The MTP almost certainly still falls short of Alice's threshold.

For Bob's manipulation to succeed, five or six of those eleven blocks would need similarly inflated timestamps. He doesn't produce them. Alice's coins stay locked.

The rule holds.

The Subtlety Most People Miss

MTP moves forward monotonically, but slowly. Being a median of eleven blocks, it can lag real wall-clock time by an hour or more when miners set honest but slightly conservative timestamps. This is not a bug. A timelock that triggers a little late is vastly safer than one that can be triggered early, and I'd argue that tradeoff is obvious once you see it.

For anyone building contracts with CLTV or `CHECKSEQUENCEVERIFY` (CSV governs relative timelocks keyed to block sequence numbers rather than absolute timestamps), the lag is worth designing around explicitly. If your script unlocks at a given MTP value and you need it reliably spendable by a specific real-world moment, add a buffer. An hour of extra margin is a reasonable working assumption. A few hours is conservative-but-sane for high-value outputs.

Are you actually accounting for MTP lag in your timelock math, or are you just using wall-clock intuition and hoping the numbers line up?

What the MTP rule actually encodes is this: Bitcoin's security model does not assume miners are honest. It assumes they are profit-motivated and hemmed in by game theory. MTP doesn't stop a miner from lying about the time. It just makes lying useless, because the number that matters is computed from a window of history that no single miner can rewrite alone. The lie is permitted. It just goes nowhere.