The flaw was in the implementation of a validation rule, not in cryptography or the issuance schedule. Each output was positive, but their sum overflowed to a negative value. The difference between the input and that negative total then appeared to be a fee. Version 0.3.10 added upper bounds for individual outputs and the running total; after a reorganisation onto the repaired branch, the faulty block left the active history.
On 15 August 2010, developer Jeff Garzik drew attention to the strange block 74 638. Transaction 1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9 spent a single input of 0.50 BTC and created two enormous outputs. The contemporary printblock output lists each as 92 233 720 368.54275808 BTC. The exploit transaction’s author has not been reliably identified: the public record documents its data, not the identity or motive of its creator. [1]
Bitcoin then represented amounts as signed 64-bit integers in satoshis. The integer value of each output, also documented in hexadecimal as 0x7ffffffffff85ee0, was positive and just below the int64 maximum. Their sum of 18 446 744 073 708 551 616 satoshis exceeded the range and wrapped to −1 000 000 satoshis. The old validation accepted this negative total when comparing it with the input. This was an arithmetic flaw, not a defeat of signatures. The first JSON listing in the discussion has different final decimal digits; for exact arithmetic, this entry uses the integer value supported by both printblock and the hexadecimal notation. [1]
The negative output total of −0.01 BTC against an input of 0.50 BTC produced an apparent fee of 0.51 BTC. The miner therefore claimed 50.51 BTC in the coinbase instead of the base reward of 50 BTC. After subtracting the spent input and including the excess coinbase, the two huge outputs increased the faulty branch’s supply by exactly 18 446 744 073 709 551 616 satoshis: 2^64 satoshis, or 184 467 440 737.09551616 BTC. That figure is therefore not simply the sum of the two outputs. [2]
The community responded publicly and under time pressure. Lfm called the bug serious, Gavin Andresen proposed a quick check of each output against 21 million BTC, and Satoshi Nakamoto published a broader form: reject a negative or excessive output and reject an excessive running total after every addition. Satoshi also asked miners to stop temporarily so that a new valid branch could catch up with and replace the faulty branch more quickly. [2]
Satoshi announced version 0.3.10 on 15 August 2010 at 23:48 forum time, roughly five hours and forty minutes after Garzik’s report. Updated nodes treated the exploit transaction and block 74 638 as invalid and built on the last common valid block. The contemporary announcement later said that the good branch had overtaken the bad one, so an upgraded client could reorganise automatically without manually deleting blockchain files. [3]
No old block was edited in a central database. Two competing histories existed: old nodes accepted the block under the original rules, while patched nodes rejected it and accepted only work above the valid ancestor. Once the repaired branch accumulated more Proof of Work, the network followed it and the inflation block left the active history; the decisive factors were users and miners installing the new rules and the work that followed, not an order from one administrator. [3]
The protection introduced then remains visible in Bitcoin Core today. CheckTransaction rejects a negative output, an output above MAX_MONEY and a running total outside MoneyRange; checking after every addition prevents a dangerous sum from wrapping before it is compared. A source comment explicitly cites CVE-2010-5139, while the separate duplicate-input check recalls the distinct CVE-2018-17144 incident. [4]
The incident shows that the 21 million limit is not a magic constant protected by hashing alone: it is enforced by precise validation rules and their correct implementation. An audit must cover individual ranges, safe addition, coinbase and fees, ordering of checks, boundary test vectors and agreement among independent implementations. The history also demonstrates both the early community’s ability to repair a flaw quickly and its high dependence at the time on a few developers, miners and manual coordination. [5]
For the clearest picture, read this entry together with Bitcoin Core, Consensus Rules, Transaction, UTXO, Reorg, Soft Fork.
01Did 184 billion BTC ever exist in valid Bitcoin?+
They briefly existed on the then-mined faulty branch as the result of the exploit block. Patched nodes rejected that branch and the valid branch reorganised it away, so the huge outputs are not part of today’s active blockchain or UTXO set. The historical incident cannot be denied, however: the block and the contemporary response are documented.
02Did the incident permanently break the 21 million limit?+
Not in the history accepted today, because the patched consensus rules rejected the faulty block and its outputs disappeared in the reorganisation. The event did show that the limit depends on correct validation and on the software participants actually run; a statement in documentation cannot enforce the supply by itself.