Written by Dex Calloway, resident contrarian at Bitcoin Institute, an archive of Bitcoin's primary sources.
Hot take: the code that keeps Bitcoin's block time honest has an off-by-one error, it's been there since the very first release, and nobody's fixed it in seventeen years. Not "there was a bug once." It's still in the code you're running right now.
The bug
Bitcoin's difficulty-adjustment window is documented as 2,016 blocks — two weeks, at a target 10 minutes per block. The code that actually computes the elapsed time for that window measures the gap between block 0 and block 2,015. That's 2,015 blocks, not 2,016. The first block of every retarget window never gets counted.
The consequence isn't cosmetic. If a majority of hashrate cooperates, they can stamp the first block of a window with a far-future timestamp, then stamp the remaining 2,015 blocks with realistic ones. Because the off-by-one drops that first block from the elapsed-time calculation, the algorithm sees a shorter window than actually passed. Difficulty drops on the next retarget. Same hashrate, faster blocks, no extra work performed.
This is Satoshi's own code. It's present from the v0.1.0 release in January 2009, preserved verbatim in the archived source. The full mechanic, with a step-by-step trace of the attack, is in the archive. There's no evidence Satoshi knew about the discrepancy — the bug wasn't publicly described until 2011, two years after release.
"So it's not a real threat, why do you care"
Because that's not actually a defense of the code — it's a defense of the fact that nobody's bothered to run the attack. Published estimates put the cost-effective minimum at roughly four weeks of sustained majority hashrate before meaningful exploitation — a rough figure, dependent on exactly how much hashrate share an attacker holds. That's a real, if narrow, barrier. But "expensive to exploit" and "doesn't exist" are different claims, and Bitcoin's whole pitch rests on the code enforcing the rules, not on attackers being too lazy to try.
"Every codebase has bugs, this is a nothingburger"
Sure, if this were some feature flag. It's not — it's the exact mechanism that's supposed to guarantee blocks arrive roughly every 10 minutes regardless of hashrate swings. That's not a peripheral function. It's close to the core security property people cite when they say Bitcoin is trustless. An off-by-one sitting inside your trust-minimization guarantee for 17 years is not the same category of bug as a typo in a comment.
Why nobody's fixed it
There is an actual fix: the Great Consensus Cleanup, a soft-fork proposal authored by Antoine Poinsot that would constrain the timestamp of each window's first block so the gap can't be gamed regardless of hashrate share. It has support from several Bitcoin Core developers, but as of 2026 it hasn't reached the kind of broad operator buy-in that SegWit and Taproot each eventually got — through their own, different activation paths.
That's not incompetence — it's Bitcoin's whole governance culture on display. A soft fork that closes a theoretical, never-exploited attack vector doesn't clear the same bar as one that ships a new feature. The community would rather leave a known, narrow hole open than mobilize the coordination required to patch something that has never actually hurt anyone.
The part that should bother you more than the bug
Two competing facts sit next to each other and Bitcoin's culture is completely fine with it: the network markets itself on code being the final word, and the final word has had a measurable error in its core timing guarantee since day one that the ecosystem has had seventeen years to notice and prioritize — and didn't, because the cost-benefit didn't justify the coordination.
Maybe that's the correct call. Maybe "expensive and never used" really does mean "not worth the fork." But then the pitch isn't "the code is the law." The pitch is "the code is the law, except when fixing it costs more political capital than the bug is currently worth." That's a more honest sentence. It's also a much less quotable one.
Tell me why I'm wrong.
Top comments (0)