The transaction that crossed Bitcoin’s supply limit—and the nodes that rejected it
Block 74,638 carried two outputs of 92,233,720,368.54275808 BTC each. The repair took a code patch, upgraded miners and nodes, and a replacement chain that overtook the faulty history the next day.
3-Minute Fast Briefing
- The ParadoxAt 17:05:57 UTC on August 15, 2010, block 74,638 included two outputs of 92,233,720,368.54275808 BTC each, totaling 184,467,440,737.08551616 BTC.
- The Turning PointJeff Garzik reported the anomaly; forum participants traced it to the sum of individually valid outputs wrapping below zero. Gavin Andresen posted a preliminary fix before Satoshi uploaded the consensus patch.
- The LegacyVersion 0.3.10 made the transaction invalid, but recovery depended on miners and node operators adopting it. Satoshi reported the corrected chain had overtaken the faulty one around height 74,689 on August 16.
Chronological Timeline
Two individually positive outputs total 184,467,440,737.08551616 BTC; their aggregate wraps below zero in the old validation path.
Garzik publishes the block data and asks whether the enormous value is the integer limit.
After limited testing, Andresen proposes rejecting outputs above the monetary range.
At 21:40 Satoshi uploaded revision 132, checking each output and the running total against the monetary range. At 23:48 he announced version 0.3.10 binaries that rejected the overflow transaction and asked operators to upgrade.
Satoshi reports that the accepted chain passed the faulty branch around height 74,689, allowing older nodes to reorganize to it.
1. The block explorer showed an impossible amount
At 17:05:57 UTC on August 15, block 74,638 recorded a transaction with a 0.5 BTC input and two outputs of exactly 92,233,720,368.54275808 BTC.[1]
Together they were 184,467,440,737.08551616 BTC. “184 billion” is a useful headline scale, not the exact amount.[1]
The two outputs were each just below the signed 64-bit ceiling. When the old client added them, the running total wrapped to minus 0.01 BTC. That made a transaction spending far more than its input pass a check designed for ordinary amounts; the block’s miner consequently collected 50.51 BTC, including the apparent 0.51 BTC fee.[1]
2. A public thread turned surprise into a diagnosis
Jeff Garzik posted the block data at 18:08.[1][2]
Other participants reproduced the transaction printout, identified the negative aggregate, stopped generation on some nodes, and warned people not to make or accept transactions while the fault was unresolved. The surviving record identifies neither the transaction author nor that person’s motive, so calling the actor a hacker or miner goes beyond the evidence.[1][2]
Gavin Andresen posted a minimally tested proposal at 20:39. Twenty minutes later Satoshi showed a broader draft that rejected any output above 21 million BTC and also rejected a running total above that range. Gavin replied that the change looked good and asked whether the bad block could be orphaned without forcing everyone to download the chain again.[2]
3. The code changed first; the accepted history changed later
At 21:40 Satoshi announced that SVN revision 132 had been uploaded.[2][4]
The historical commit adds the monetary-range guard to each output and to their aggregate. The rule was stricter than what older clients enforced: patched software rejected the transaction that older software had already accepted.[2][4]
Satoshi then built version 0.3.10 and announced it at 23:48. Operators were asked to stop, upgrade, and rebuild from the last valid history. Forum participants shared older chain snapshots and known upgraded peers; miners running the patched client began extending a branch from block 74,637. The release supplied a rule, while those independent choices supplied the proof of work that made it effective.[2][3]
4. Recovery continued through the night
At 02:16 on August 16, Satoshi reported fourteen new blocks and said more than half of the nodes connected to him were already on 0.3.10, but he still described the corrected branch as probably having more power.[2]
At 12:59 he reported that it had overtaken the bad branch somewhere around height 74,689 and that older clients had been following the current height for hours.[2]
That sequence separates two milestones often collapsed into one phrase. A source patch appeared roughly four and a half hours after the block timestamp and the packaged release followed later; confirmation that the corrected proof-of-work history had overtaken came the next day. Ordinary transactions from the abandoned branch could re-enter and regain confirmations, while immature mining rewards from blocks after 74,638 disappeared. Satoshi published the repair, and independent miners and node operators completed the coordinated recovery.[2][3]
Key Takeaways for Investors & Builders
A limit must hold for every value and their sum
The old path checked individual outputs but let their aggregate wrap. The repair added monetary-range checks during accumulation.
Publishing a patch did not rewrite the ledger
The new rule mattered only after miners and node operators ran it and accumulated enough proof of work on the corrected branch.
Fast recovery still displaced confirmations and rewards
Transactions could return with fresh confirmations, while immature block rewards mined on the abandoned branch disappeared. Recovery changed real operator state.
Continue reading
Explore the topic through other cases and contexts.
Sources & References
- [1]Source 1: Bitcointalk: Strange block 74638Bitcoin Forum archive · 2010-08-15
- [2]Source 2: Bitcointalk: overflow bug SERIOUSBitcoin Forum archive · 2010-08-15
- [3]Source 3: Bitcointalk: Version 0.3.10 — block 74638 overflow PATCH!Satoshi Nakamoto / Bitcoin Forum archive · 2010-08-15
- [4]Source 4: Bitcoin source: fix for block 74638 overflow output transactionBitcoin source repository · 2010-08-15
- [5]Source 5: CVE-2010-5139 DetailNational Vulnerability Database, NIST