Bitcoin’s difficulty-adjustment algorithm contains a long-known off-by-one bug in Satoshi’s original code. The retarget window is documented as 2,016 blocks — two weeks at 10-minute block intervals — but the code that computes the elapsed time measures from the first block to the last block of each window: 2,015 intervals, not 2,016. And because each window is timed only from its own first block, the interval between one window’s last block and the next window’s first block is never measured at all. The bug is small, the consequences are not.
1. The mechanic
When a majority of hashrate cooperates, miners can keep the timestamps of almost every block barely moving, just enough to satisfy the rule that a block’s time must exceed the median of the previous eleven, and stamp only the last block of each retarget window with the real time. The first block of the next window is then set back into the past again; a single outlier does not move the median of eleven. Because the algorithm times each window from its own first block to its own last, the jump back between windows is never measured, and every window looks far longer than it really took. Difficulty does not move after the first window, but from the second retarget on it falls, and the colluding majority then mines blocks at faster-than-10-minute pace without adding any hashrate.
The attack is not free or instant. The published descriptions place the cost-effective minimum at roughly four weeks of sustained majority operation before meaningful exploitation. That is long enough that any real attempt would be visible to the rest of the network well before the difficulty distortion materialized — which is the main reason the bug has remained unfixed for so long: it is exploitable in principle but expensive in practice, and a coordinating majority that conspicuous would find far easier and more profitable mischief than gaming the retarget window.
2. Why this is in Satoshi’s code
Examination of the v0.1.0 source — preserved in trottier/original-bitcoin’s pinned src/main.cpp at commit 4184ab2, lines 685–707 — shows the bug present from the initial release in January 2009. The loop that walks the previous retarget window starts at the latest block and counts back 2,015 entries, then takes the time delta between that 2,015-block-earlier ancestor and the current block. The intent was clearly to span 2,016 blocks; the implementation spans 2,015. There is no surviving evidence that Satoshi was aware of the discrepancy. The bug was first publicly described on BitcoinTalk in 2011 and has been periodically rediscovered since.
3. The Great Consensus Cleanup
Antoine Poinsot has championed a soft-fork proposal known as the Great Consensus Cleanup that bundles a fix for the time-warp bug with several other long-known protocol curiosities. The proposal would constrain the timestamp of the first block of each retarget window so that the off-by-one cannot be exploited regardless of hashrate share. As of 2026 the proposal remains in active community discussion: it has support from several Bitcoin Core developers but has not reached the level of operator consensus that triggered SegWit (BIP148) or Taproot (BIP341). The bug this proposal targets is documented as one of two known quirks in the consensus design’s difficulty-adjustment section, alongside the related off-by-one in the retarget window count.
The pace of activation reflects Bitcoin’s institutional caution. Soft-fork changes to the consensus rules require both broad developer agreement and clear miner / node-operator readiness, and the bar for a “cleanup” fork — one that does not deliver any new user-facing feature — is higher than for capability-adding forks. The community has thus been content to leave a known but expensive-to-exploit bug in place rather than mobilize a fork that, in absolute terms, only closes an attack vector that has never been used.
4. Editorial significance
The time-warp bug is one of the most-cited examples of “Satoshi’s code as historical artifact”: a piece of running mainnet logic, seventeen years old and still in place, that nobody is in a hurry to touch. It illustrates both the resilience of Bitcoin’s design (a real bug that has not threatened the chain) and the conservatism that defines its protocol-evolution culture (no rush to fix what has not broken). A soft-fork correction would not be the first to fix a bug in Satoshi’s own consensus code — the 2010 value-overflow incident holds that place, patched within hours of discovery. What would distinguish the Great Consensus Cleanup, when and if it activates, is the opposite kind of urgency: a deliberated, years-long correction of a latent flaw that has never been exploited, rather than an emergency response to one already in progress.
