Written by Marlowe Finch, archival bloodhound at Bitcoin Institute.
Bitcoin has been decentralized and trustless since block zero. No CEO, no committee, no kill switch, no single person who can rewrite the rules. That's the pitch. It's why the whitepaper still gets quoted like scripture.
Block 74638 does not agree with the pitch.
What actually shipped in that block
On August 15, 2010, a transaction landed in the Bitcoin blockchain with two outputs. Each one paid out 92,233,720,368.54277039 BTC. Combined: over 184 billion BTC — roughly nine thousand times the 21 million BTC that will ever exist, created in a single transaction.
The validation code, CheckTransaction(), checked that each individual output was non-negative. It never checked whether the sum of the outputs overflowed. Two values chosen just under INT64_MAX, added together, wrapped around to a negative number in signed 64-bit arithmetic. A 0.5 BTC input, compared against that negative sum, satisfied the "input covers output" check. The transaction validated. The block got mined. Every rule the network was running said this was fine.
That's CVE-2010-5139. It is also, by any dollar value you want to apply, the most expensive missing bounds-check ever shipped to production.
So who hand-builds a transaction engineered to overflow a signed 64-bit integer, and what does a currency with a hard 21-million-coin cap do when someone mints nine thousand times that in one block? The archive's full account of the incident lays it out block by block.
The receipts
18:08 UTC, August 15 — Jeff Garzik opens a BitcoinTalk thread titled "Strange block 74638", pastes the raw block dump, and closes with one question:
"92233720368.54277039 BTC? Is that UINT64_MAX, I wonder?"
20:38 UTC — Satoshi Nakamoto, to the bitcoin-list mailing list, network-wide:
"*** WARNING *** We are investigating a problem. DO NOT TRUST ANY TRANSACTIONS THAT HAPPENED AFTER 15.08.2010 17:05 UTC (block 74638) until the issue is resolved."
20:39 UTC — Gavin Andresen, testing an emergency patch of his own:
"Until there is a better fix... after a very small amount of testing this seems to work:"
Then, on where the clean chain came from:
"I started with knightmb's blockchain snapshot."
21:23 UTC — Satoshi, endorsing that same community-hosted snapshot to the entire thread:
"Once you have an update, you could download knightmb's block chain. You'll want one that's old enough that it ends before block 74000 so the most recent security lockin will check it. Can someone find the link for that?"
23:48 UTC — Bitcoin v0.3.10 ships. Five hours and forty minutes after Garzik's first post, Satoshi has written the official patch, built it for Windows, Linux, and macOS, and posted it to SourceForge.
02:16 UTC, August 16 — Satoshi again, with a live head count of the fix taking over the network:
"The bad chain is also slowed down as more nodes upgrade. We've already generated 14 blocks since 74638. The builds of 0.3.10 were uploaded about 2 and 3 hours ago. Of the nodes I'm connected to, more than half are already 0.3.10. I would say we probably already have more power than the bad chain."
09:00 UTC — Block 74691. The patched chain now carries more accumulated work than the bad one. Every node, upgraded or not, follows the longer chain by its own pre-existing rule. The 184 billion BTC vanish from canonical history. No vote. No signature campaign. No governance process. Just one chain winning a footrace the other chain didn't know it was running.
How the fix actually worked
v0.3.10 added two checks to CheckTransaction(): each output must be no greater than 21,000,000 BTC, and the sum of all outputs must be no greater than 21,000,000 BTC. Simple, in hindsight. It's a soft fork — the new rules are a strict subset of the old ones, so upgraded and un-upgraded nodes could still agree on which chain was longest without every operator on Earth acting in the same hour. That's the only reason one developer could out-race a live exploit: the fix didn't need unanimous, simultaneous adoption. It needed to win a hash-power race, and it had roughly fifteen hours to do it before the bad chain calcified into everyone's history.
The part the origin myth skips
For about fifteen hours, "decentralized" and "trustless" meant: trust one developer's patch, trust one blockchain snapshot from a forum regular going by knightmb, and trust that enough node operators would upgrade fast enough to out-mine a chain nobody had voted to reject. There was no review queue. Gavin had a stopgap, but there was no second opinion with equal authority. There was Satoshi at the release switch, and everyone else waiting on his word.
Was a network that ran on exactly one person's unreviewed patch, adopted on his say-so alone, actually decentralized during the fifteen hours that mattered most? The archive's structural read on the incident calls this the centralization paradox — and argues it was never resolved, only inherited by everyone who came after Satoshi.
By 2018, an analogous bug — CVE-2018-17144, a duplicate-input flaw that could have inflated the supply again — took a coordinated, multi-developer disclosure process to fix quietly before anyone could weaponize it on mainnet. Nobody could ship a five-hour patch on one person's authority to a network that size anymore, and nobody tried. Block 74638 is the only time Bitcoin's trustless network was saved on one person's word. It worked. It only ever worked once.
Top comments (0)