The time warp: all 483 mainnet retarget seams checked, and the history since 201

[windpath]

A new Rabbit Hole on Bitcoin's difficulty adjustment and the time warp attack, which was first explained on this forum by ArtForz on 12 September 2011 (topic 43692):

The Time Warp: How Lying About the Time Could Break Bitcoin's Difficulty

What's in it:

• The timestamp rules as they are in Bitcoin Core v32.1: the median-time-past floor, the two-hour ceiling against the node's own system clock since 27.0 (PR #28956), the ten-minute peer-clock warning since 28.0 (PR #29623).
• The 0.1.0 loop (`i < nInterval-1`) that gives both the 2,015-gap off-by-one (600.3 s by division, about 600.6 s on average, per Wuille) and the seam, set against Satoshi's November 2008 draft, which had neither.
• A simulation with Core's retarget arithmetic that reproduces all 483 mainnet retargets: with all the hash rate, minimum difficulty on day 39.4 from a window boundary, about 37.4 with the best start. Window-by-window CSV on the page.
• Every seam on mainnet, read from the Bitcoin Core node powering ChainQuery: ten negative in 483, worst -1,127 s at block 203,616 (16 October 2012), -43 s since 2015 (812,448). BIP-94's 600 s would have rejected that one block; BIP-54's 7,200 s none. Full table as CSV.
• Maxwell's planted time warp in testnet3 (blocks 8,063/8,064 and 10,079/10,080, mined late July 2012, difficulty 16 to 4 to 1), and why the April 2024 storms were the other bug.
• Why the fix waited: Andresen 2011, BIP-99's model hard fork, Maxwell 2018, Corallo's 2019 cleanup, Towns 2022, Friedenbach's Forward Blocks objection, Poinsot's 2024 revival, BIP-54 complete in May 2026, PR #35793 open.

https://www.learnbitcoin.com/rabbit-hole/time-warp

[eternalgloom]

Time warp attack typically require attacker to possess majority of hashrate. So, an individual miner cannot execute this exploit on their own.

And specification for Great Consensus Cleanup has been complete for many month now. So, it is clear that any complete specification does not equate to mainnet activation.

I want developer and mining pools to conduct more extensive testing before activation. Even any small change to Bitcoin's consensus rule can have major impact, so rushing this would be bad idea.

[windpath]

Time warp attack typically require attacker to possess majority of hashrate. So, an individual miner cannot execute this exploit on their own.

And specification for Great Consensus Cleanup has been complete for many month now. So, it is clear that any complete specification does not equate to mainnet activation.

I want developer and mining pools to conduct more extensive testing before activation. Even any small change to Bitcoin's consensus rule can have major impact, so rushing this would be bad idea.

Agreed on all three. The Rabbit Hole says: it would take a majority, and "Complete" on a BIP only means the text is finished. Nobody has proposed activation parameters yet.

On testing, quite a bit is already happening in the open:

• testnet4 has enforced the time warp rule (with a ten-minute grace) since 2024
• Bitcoin Inquisition has enforced all of BIP-54 on signet since February 2026
• Bitcoin Core's own block templates have respected the time warp rule since 29.0 and the second timestamp rule since 32.1, so pools on current Core already build blocks that would pass
• pools that find something like 40 percent of blocks already make coinbases that pass BIP-54's new coinbase rule (mainnet.observer tracks this pool by pool)

One bit of our own data bears on your point about small changes having big effects. We checked every one of the 483 difficulty adjustments since 2009, and no block in Bitcoin's history would have failed BIP-54's two-hour timestamp rule. The closest call was about 19 minutes, in 2012. So for honest miners the rule shouldn't bite at all, and that's the main thing more testing has to confirm.

There's still review left on the Core pull request and on other implementations, so I don't see anyone rushing it.