LearnBitcoin

Glossary

Time Warp Attack

A way for miners with most of the hash rate to push Bitcoin's difficulty toward its minimum by lying about block timestamps. It works because the 2,016-block retarget window measures 2,015 intervals and does not overlap the window before it. Known since about 2011, never seen on mainnet, and the fix is the first rule in BIP-54.

Bitcoin's difficulty is recalculated every 2,016 blocks from timestamps that miners write into the block headers themselves. GetNextWorkRequired in src/pow.cpp finds the first block of the window and hands its timestamp to CalculateNextWorkRequired, which subtracts it from the last block's timestamp and compares the result with two weeks. Two details of that arithmetic matter here. The first and last block of a 2,016-block window are 2,015 intervals apart, not 2,016, so the comparison is off by one. And each window starts over with its own first block. Nothing ties the first timestamp of a window to the last timestamp of the window before it, except the median time past rule, which only asks that a block be stamped later than the median of the previous eleven.

The off-by-one is harmless on its own. It spreads 1,209,600 seconds over 2,015 gaps instead of 2,016, so the real target is ten minutes and three tenths of a second. The seam between windows is the vulnerability. A miner who produces the last block of one window and the first block of the next may stamp the last with the true time and the first with a time far in the past, and both blocks are valid.

The attack built on that seam has been known since about 2011. A miner with a majority of the hash rate stops writing real timestamps. For almost every block the stamp creeps forward by one second every six blocks, the slowest pace the median rule allows, so the chain's clock falls further and further behind the wall clock. On the last block of each window the miner writes the real time, by now weeks ahead of the stamps around it. The first block of the next window drops back to the crawling clock, which the median rule permits because one outlier does not move a median of eleven. From the second window on, each period measures far longer than two weeks, so each retarget cuts difficulty: by half the first time, by more as the windows get shorter, and the miner finds blocks faster every round.

The numbers are bad: Antoine Poinsot's analysis for BIP-54 puts difficulty at its minimum within 38 days of starting, after which the attacker can mine millions of blocks, bringing forward all the remaining subsidy and breaking every time lock that Lightning channels and vaults rely on. BitMEX Research ran the same arithmetic and got more than ten blocks a second by day 39. Honest miners are what stands in the way. An honest first block in any window, stamped with the real time, spoils that round, and honest stamps elsewhere drag the median forward, so the attack needs a majority. A minority miner who bends timestamps opportunistically gains almost nothing, and Matt Corallo's 2019 draft recorded no known attempt on mainnet.

The reasons it sat unfixed are mundane. The attack is slow, visible to everyone for weeks, and needs a majority that could already censor the chain, so for years it was filed under theoretical. Corallo's 2019 Great Consensus Cleanup bundled the fix with script changes that drew objections about confiscating old coins, and the whole package stalled; his pull request was closed that November. Testnet3 then supplied a live demonstration of what a collapsing difficulty does. Its 20-minute minimum-difficulty exception, a different bug in the same code, produced block storms that mined three years' worth of blocks in a few weeks in 2024, and BIP-94 notes that a time warp would have amplified them. Testnet4, which replaced it, enforces a time warp rule, the only Bitcoin network that does as of October 2026.

The fix itself is small. The first block of a difficulty window may not be stamped earlier than the last block of the previous window, minus a grace period. Corallo proposed ten minutes, because deployed mining hardware rolls the timestamp forward by up to that much while searching for a nonce, and testnet4 enforces 600 seconds through the MAX_TIMEWARP constant in Bitcoin Core. BIP-54 widened it to two hours after testnet4 showed pool software producing blocks that broke the ten-minute version; two hours matches the future-time limit, and under attack the BIP puts the cost at about two seconds per block. Bitcoin Core has refused to build a block template that breaks the rule since version 29.0. Mainnet enforcement is still a soft fork away. See Great Consensus Cleanup for the full package and block timestamp rules for the limits miners work within.

Key takeaways

  • The retarget compares the first and last timestamps of a 2,016-block window, 2,015 intervals apart, and the next window starts fresh; the first block of a window may carry an earlier stamp than the last block of the previous one as long as it beats the median of the eleven before it
  • A majority miner holds timestamps back, stamps the last block of each window with the real time and drops back on the next one; from the second window on each period looks weeks longer than it was, difficulty falls faster each round, and BIP-54 puts the minimum within 38 days
  • The fix is one rule: the first block of a window may not be stamped more than a grace period before the last block of the previous one. Testnet4 has enforced ten minutes since 2024 (BIP-94); BIP-54 proposes two hours for mainnet, and Bitcoin Core 29.0 already refuses to build a template that breaks it

Sources (12)

Related terms (12)

Published . No corrections logged for this page.

Edit this page on GitHub