The 2010 Bitcoin Value Overflow Incident: When Billions Appeared
In August 2010 a bug created 184 billion bitcoins in one transaction. Learn how the integer overflow happened, how it was fixed in hours, and what it taught.
Bitcoin is designed to have a fixed supply of 21 million coins. On 15 August 2010, a single transaction briefly appeared to contradict that rule by creating more than 184 billion bitcoins out of nothing. The bug was fixed within hours, and it remains one of the most serious flaws found in Bitcoin's consensus rules, as well as a good case study in how small coding errors can have large consequences.
What happened
In block 74,638, a transaction contained two outputs of just over 92 billion bitcoins each, which was far beyond the intended supply. The network accepted the block, because the software's validation logic failed to notice the problem. Developers and users noticed the strange transaction in a block explorer and raised the alarm on the Bitcoin Talk forum.
The incident is recorded as CVE-2010-5139. It is sometimes called the value overflow incident, because the root cause was an integer overflow.
The cause: an integer overflow
Bitcoin amounts are stored internally as 64-bit signed integers measured in the smallest unit, later called a satoshi. When the software checked a transaction, it added up the output values and verified that the sum did not exceed the inputs. But the sum itself could overflow: if two huge numbers were added, the result could wrap around into a small or negative number, which would pass the check.
The attacker built outputs so large that their total wrapped around to a small value. The software then concluded that the outputs were less than the inputs and let the transaction through. A missing check on each output value, and on the total, let the invalid amounts pass.
How it was fixed
Bitcoin's developers responded quickly. Satoshi Nakamoto and Jeff Garzik were among those working on the problem that day. The response had two parts:
- A patched client. Version 0.3.10 added checks that rejected outputs above the maximum allowed value and prevented the overflow in the sum.
- A chain reorganisation. Because the invalid block had already been added, the network needed to abandon it. Participants upgraded to the fixed software, and miners built a longer valid chain that did not include the bad block, which meant the bad transaction was no longer part of the accepted history.
The patched release followed within hours, and the correct chain overtook the invalid one in less than a day. The fix was a soft fork, since the new rules were stricter than the old ones, and old nodes eventually followed the new chain.
What the incident showed
- The community can coordinate quickly. A small group of developers and miners acted in the same day, which is an early example of how decisions are made in an open protocol.
- Immutability has limits. The ledger is described as immutable, but in this case the participants agreed to roll back a block because it violated the protocol's own rules.
- Validation must check every assumption. The bug was not an exotic cryptographic weakness but an arithmetic edge case.
Limited damage
No known user lost funds as a result. The inflated coins were created in one transaction and never moved into general circulation, since the chain was reorganised before they could be used. Since then, the Bitcoin software has had extensive testing, though bugs have been found in other implementations and later versions. Another consensus bug, related to duplicate inputs, was found and fixed in 2018 before it was exploited.
Comparison with other consensus problems
| Event | Year | Problem | Outcome |
|---|---|---|---|
| Value overflow | 2010 | Arithmetic overflow in output sum | Fixed in hours, block rolled back |
| Duplicate input bug (CVE-2018-17144) | 2018 | Missing check for duplicated inputs | Patched before known exploitation |
The check that exists today
Modern Bitcoin software contains an explicit constant for the maximum amount of money, equal to 21 million coins expressed in the smallest unit. Every output value must fall within the range from zero to that maximum, and so must the running total of outputs in a transaction. The check is simple, but it closes the gap that the 2010 transaction used. Many security flaws arise from missing bounds of this kind, and validating input at every boundary is one of the most dependable defences in software generally. Our security page explains how Zebra Hosting approaches protection at the server level.
Why it matters for software in general
The same class of bug appears across the software industry. Integer overflow has been a cause of vulnerabilities in operating systems, web servers and applications for decades. Developers defend against it with range checks, safe arithmetic libraries and careful code review. The Bitcoin episode is useful because the consequence was so easy to understand: a number that should not exist was accepted as valid.
A practical lesson for site owners
The fast fix worked because users noticed, reported and updated. The same applies to your website: security patches only help if you apply them. If you run WordPress or other software, keep it updated and check our security page to see what Zebra Hosting does on the platform side.
