The Inflation Bug Postmortem | LearnBitcoin<br>Rabbit Hole · 10 min<br>The Inflation Bug Postmortem<br>August 15, 2010: someone created 184 billion BTC out of thin air. Five hours later, it was fixed. Here is the full story.

Where you're going: The closest point Bitcoin ever came to dying. Years later, it is the cleanest case study available for why "verify, don't trust" is not a slogan but a survival principle. Five hours of crisis, more than a decade of vindication.

Five hours of crisis, one strike-through, and the cap held. The full story below.<br>1. August 15, 2010

Bitcoin was nineteen months old. The network had a few hundred users, a couple thousand nodes, a price under a penny per BTC, and zero serious adversaries.

At 19:13 UTC, on a Sunday afternoon, an unknown actor broadcast a transaction that exploited a bug in Bitcoin's validation code. The transaction created 184,467,440,737.09551616 BTC - more than 8,000 times the total amount of bitcoin that should ever exist - and sent it to two addresses, splitting the supply nearly evenly.

The next miner picked up the transaction and mined block 74,638 , including it. The block was valid by the code that was running. Every node accepted it. For a few hours, Bitcoin had a supply problem in the exact opposite direction of its design promise.

This was the closest Bitcoin has ever come to dying. The fix arrived five hours later. It is worth understanding why it worked.

2. The Bug: Integer Overflow

The bug was in CTransaction::CheckTransaction, the function every node calls to validate that a transaction is well-formed. One of the checks: confirm that the sum of all output values does not exceed MAX_MONEY (21 million BTC, in satoshis).

The code that did this check used a signed 64-bit integer to hold the sum, and added each output value in sequence. If two outputs each had values near 2^63, their sum would overflow. Wrap around past the maximum representable positive number into the negative range. A negative sum is, of course, less than MAX_MONEY. The check passed.

The transaction had two outputs, each set to roughly 9.2 × 10^18 satoshis - just past the overflow threshold. Their sum overflowed to a small negative number. The validation function said "looks fine." The transaction got mined.

This is a textbook example of a class of bugs that has been understood since at least the 1970s. C and C++ allow signed integer overflow, the behavior is technically undefined, and writing checks that do not account for it is a known footgun. Satoshi wrote it anyway. So would any of us.

3. Block 74,638

The block looked normal at first glance. One mining reward (50 BTC), a few ordinary transactions, and one transaction that issued 184 billion BTC.

The chain accepted it. For five hours, every node that had downloaded the block was running a Bitcoin where roughly 9,200x the intended supply was now circulating.

If left to stand, this would have permanently destroyed Bitcoin. The promise of a 21 million cap is the only reason to hold any of it. If the cap had been broken once, demonstrably, in production, there would be no reason to believe it would not be broken again. Bitcoin would have ended in 2010.

4. Satoshi's Response: Five Hours

The bug was noticed within an hour. By 19:50 UTC, BitcoinTalk forum posts were flagging the strange transaction. By 23:30 UTC, Satoshi had committed a fix to Bitcoin's source code and released version 0.3.10. The fix: add an additional check that catches the overflow case before it can cause the validation to pass incorrectly.

In a forum post, Satoshi wrote:

"It was a bad block. Versions 0.3.10 and later will not accept it. Please upgrade ASAP."

The technical fix was small. The hard part was getting node operators to upgrade and coordinating a reorganization of the chain to remove the bad block.

5. The "Soft Fork" That Wasn't

Bitcoin documentation often describes the inflation-bug fix as a soft fork. Strictly, it was not. It was a hard fork with extremely rapid coordination.

A soft fork tightens the rules: new clients reject blocks the old clients would accept, but old clients still accept everything the new clients produce. The chain stays unified.

A hard fork changes the rules: new clients reject some blocks old clients accept (or accept blocks old clients reject). If both versions stay running, the chain splits.

The inflation-bug fix rejected block 74,638, which old clients had accepted. By definition: hard fork. The reason it did not split the chain into two permanent versions is that almost every node operator updated within hours, and the longer chain (the one without billions of bitcoin) ended up being the unanimous one.

This is the only successful hard fork in Bitcoin's history that the entire community accepted within hours of being proposed. The reason: the alternative was extinction.

6. The Reorg: 53 Blocks

To remove block 74,638 from history, the network needed to mine a longer chain that did not include it. This is a...