A Timewarp Attack is coordinated manipulation of block-header timestamps that distorts the next difficulty calculation. It can lower difficulty without a corresponding fall in hashrate, accelerating block production.
Bitcoin recalculates difficulty every 2016 blocks, targeting an average of 10 minutes between blocks. It subtracts the first block’s timestamp in a period from the last, covering only 2015 intervals. The interval between one period’s final block and the next period’s first block is omitted from these differences. At that boundary, time can move backward without the calculations continuously linking both periods. [4] [3]
A new block’s timestamp must exceed Median Time Past (MTP), the median of the previous 11 block times. It need not exceed the immediately preceding block’s time. Attackers can set most timestamps just 1 second above MTP, give the period’s final block roughly the real time, then use an older time again. They manipulate newly mined blocks, rather than rewriting already confirmed headers. [1]
The classic scenario assumes a majority of hashrate, or a minority gaining additional influence over block ordering, for example through Selfish Mining. It requires sustained control of the time series, not one block with an unusual timestamp. The classic attack takes about a month of preparation whose traces are publicly visible in the chain. [1]
In the second attacked period, timestamps can imply an average of 20 minutes per block, roughly halving difficulty. The next period is mined faster, yet manipulated times again call for a reduction. The fourfold limit on one adjustment does not prevent repetition. The theoretical long-term limit from MTP corresponds to about 6 blocks per second; this is not a promise of practical network throughput. [1] [3]
Faster blocks would bring future block subsidy forward into a shorter time; they do not by themselves raise the 21 million BTC limit. Nodes would need to verify and relay data faster. Overloaded processors, inadequate connections, competing branches and frequent reorganizations would undermine reliable confirmations. [1]
BIP 113 uses the previous block’s MTP to evaluate absolute nLockTime locks specified as a time. Locks specified as a block height still use height. During the attack, MTP may advance much more slowly than real clocks. Funds in a time-dependent contract may remain unavailable longer than expected, and more complex protocols may lose the intended coordination between steps. [5] [1]
The proposal limits the first block’s time in a period: it must not be more than 7200 seconds, or two hours, earlier than the preceding block. The final block’s time must also be no earlier than the first block’s. The specification has status Complete. That means the proposal is finished, not activated: enforcing new consensus rules on mainnet requires a separate activation. [2]
Compare header times, MTP, boundaries every 2016 blocks, real mining pace, difficulty and hashrate. Distinguish the classic attack from the Murch–Zawy variant, and testnet rules from mainnet rules. Software may proactively construct safer block templates; that does not mean the whole network rejects every block violating the proposed protection. [3] [2]
For the clearest picture, read this entry together with Difficulty Adjustment, Mining, Proof of Work, Consensus Cleanup, Timelock, Reorg. The reverse links also lead from Consensus Cleanup.
01Does the attack require a majority of hashrate?+
The classic scenario assumes a majority or another advantage providing the necessary influence over block ordering. A smaller miner without that advantage lacks sufficient control over their times.
02Is Median Time Past protection enough?+
No. MTP constrains individual timestamps but does not close the gap at period boundaries. BIP 54 proposes further constraints on the relationship between first and last block times.