Median Time Past (MTP)

Median Time Past (MTP) is the timestamp Bitcoin uses to evaluate time-based timelocks. Instead of trusting a single block's self-reported timestamp, the protocol takes the timestamps of the previous 11 blocks, sorts them, and uses the median. BIP 113 made MTP the reference value for time-based nLockTime and relative-locktime comparisons, replacing the raw tip timestamp with a value no individual miner can steer. It is a small rule with an outsized effect: it turned Bitcoin's notoriously loose block clock into something contracts can actually rely on.

Why block timestamps needed taming

Block timestamps are set by miners and are only loosely constrained — a block's time must be greater than the MTP of its ancestors and not too far into the future by network rules, but timestamps are not strictly ordered and routinely jitter backwards between consecutive blocks. Before BIP 113, this created a perverse incentive: a miner could push a block's timestamp forward to prematurely satisfy time-based locks under nLockTime and sweep extra fee-paying transactions into a block. Honest timestamping was, at the margin, unprofitable — precisely the kind of incentive misalignment consensus rules exist to remove.

Why the median of 11 blocks works

The median of a sliding 11-block window advances monotonically — it can never go backwards — and cannot be moved meaningfully by any single miner, because no one miner controls enough of the window to shift the middle value. Manipulating MTP requires colluding across a majority of the last 11 blocks, at which point the attacker has far larger powers than nudging a timelock. The construction is characteristic of Bitcoin engineering: rather than trying to make miners honest about the time, it makes the time a statistic that honesty-indifferent miners still cannot bend.

Practical effects for contracts and wallets

Because the median of 11 blocks trails wall-clock time, transactions using time-based locks confirm roughly an hour later than a naive reading of the deadline suggests — a lag wallet and contract designers must budget for when choosing timeout values, particularly in Lightning, where reaction windows are safety margins. MTP applies only to time-based locks, those with values above the 500,000,000 threshold that separates Unix timestamps from block heights; height-based locks are compared against the actual chain height. BIP 113 was deployed in 2016 alongside BIP 68 and BIP 112, the package that gave Bitcoin dependable relative timelocks.

A concrete example

Take the timestamps of the last 11 blocks as a miner would see them — jittering forward and occasionally backward, since each miner stamps blocks from its own clock. Sort those 11 values and take the sixth: that middle value is the MTP, and it is what a time-based lock is compared against. For the median to move, six of the eleven timestamps must move, which is why no single block — however creatively stamped — can drag it around. Two boundary rules complete the picture. A new block's timestamp must be strictly greater than the current MTP, which is what forces the median to only ratchet forward. And network policy rejects blocks stamped too far into the future relative to a node's adjusted clock, boxing timestamps in from the other side. Between the two constraints, miners retain a little slack for clock drift and stamping strategy, but nothing that a contract relying on MTP needs to fear — which is precisely the property BIP 113 set out to buy.

MTP is the clock behind both absolute timelocks and relative timelocks whenever a constraint is expressed in seconds rather than blocks, and it is enforced by every node that validates — one more reason running your own node under the verify, don't trust ethos means your timelocked contracts settle by rules you checked yourself, not by anyone's clock.