Bitcoin Value Overflow Bug — Bitcoin protocol — 2010-08-15 (block 74638)

Summary

On August 15, 2010, an attacker exploited an integer overflow vulnerability in Bitcoin Core's transaction validation code to create a transaction whose two output values summed to 184,467,440,737.09551615 BTC — approximately 8,784 times the total eventual 21 million BTC supply cap. The transaction was included in block 74638.

The vulnerability was in the CheckTransaction() function: the code summed the values of all transaction outputs in a loop using C++ integer arithmetic without checking for overflow. When the sum exceeded the maximum value of a 64-bit signed integer (9,223,372,036,854,775,807 satoshis, or approximately 92.2 million BTC), the integer wrapped around to a small or negative value. The attacker constructed a transaction with two outputs — each approximately 92.2 billion BTC — whose C++ sum wrapped to a small positive number, bypassing the "output sum ≤ input sum" validation check which would have rejected the transaction as creating value from nothing.

Satoshi Nakamoto and the small Bitcoin developer community of 2010 identified the bug within hours. Bitcoin Core 0.3.10 was released with a fix that added explicit overflow checks to CheckTransaction() and related functions. A chain reorganisation invalidated block 74638 and the exploit transaction. The 184.5 billion BTC ceased to exist on the canonical chain. No real BTC was lost.

The incident is historically significant as:

1. The first critical protocol-level vulnerability discovered and exploited in Bitcoin
2. The first emergency chain reorganisation (effectively a developer-coordinated soft fork) in blockchain history
3. The earliest demonstration that protocol-client arithmetic bugs are a distinct vulnerability class requiring their own defensive patterns (safe-math libraries, input-validation discipline, fuzzing) — patterns that would not be formalised for another 5-8 years

The incident is also structurally informative for OAK's coverage boundary: the bug was in C++ reference-client code (not a smart contract), exploited at the consensus layer (not the application layer), and fixed via developer-coordinated chain reorganisation (not a governance vote or multi-sig upgrade). OAK v0.1's Technique surface — focused on smart-contract exploits, DeFi protocol manipulation, and custody/signing infrastructure — does not cleanly capture this class. The case is documented as evidence for a future v0.x protocol-client-bug Technique class.

Timeline (UTC unless noted)

When	Event	OAK ref
2009-01 → 2010-08	Bitcoin Core's CheckTransaction() function sums output values in C++ integer arithmetic without overflow checks	(standing vulnerability)
2010-08-15 ~17:30	Block 74638 mined, containing transaction 1d40ca... with two outputs of ~92.2 billion BTC each; output sum wraps around via integer overflow, bypassing value-creation check	T9.014
2010-08-15 (within ~1 hour)	Bug identified by Satoshi Nakamoto and developer community; emergency fix development begins	(defender response — detection and fix development)
2010-08-15 (within ~5 hours)	Bitcoin Core 0.3.10 released with overflow check fix; miner community adopts the patched client	(fix deployment — version release)
2010-08-15 (following 0.3.10 adoption)	Chain reorganisation invalidates block 74638; the 184.5B BTC exploit transaction ceases to exist on the canonical chain	(chain reorganisation — recovery)
2010-08-16 onward	Bitcoin Core 0.3.10 becomes the mandatory client; the overflow fix is permanently integrated into Bitcoin's consensus rules	(fix institutionalisation)
Post-2010	The value overflow bug becomes the canonical case study for protocol-level integer-overflow vulnerabilities in blockchain systems; cited in academic literature, security curricula, and SafeMath library design discussions	(historical record — canonical reference)

Realised extraction

Zero on-chain loss. The 184.5 billion BTC created by the exploit transaction existed on-chain for approximately 5 hours (in block 74638) before being invalidated by the chain reorganisation. No real BTC was spent from the exploit outputs. The incident's structural significance is as a protocol-vulnerability class-establishing moment, not as a loss event.

What defenders observed

• Pre-event: the vulnerability was a C++ integer overflow in consensus-critical code. No overflow check existed in CheckTransaction() — the function performed output-sum validation using bare C++ integer arithmetic, and the Bitcoin codebase of 2010 did not include safe-math abstractions. The defender lesson is that consensus-code arithmetic must be overflow-checked at the language level or via safe-math wrappers — a lesson that Ethereum's Solidity formalised with SafeMath (pre-0.8) and built-in overflow checks (0.8+), and that Bitcoin Core itself subsequently addressed with explicit overflow guards.
• At-event: the attacker exploited the overflow via a deliberately constructed transaction with output values exceeding the 64-bit signed integer maximum. The attacker needed no special access — the vulnerability was in the open-source CheckTransaction() function, and the exploit required only constructing and broadcasting a valid-seeming transaction that triggered the overflow path. The defender lesson is that public-protocol arithmetic vulnerabilities are exploitable by any network participant who can construct a transaction — there is no access-control gate.
• Post-event: the fix was deployed via emergency client release (Bitcoin Core 0.3.10) and adopted via miner coordination — effectively an emergency soft fork. The response time (~5 hours from exploit to fix deployment) was enabled by 2010-era Bitcoin's small, tightly-coordinated developer and miner community. The defender lesson is that response-time-to-fix for protocol-level arithmetic bugs scales inversely with community size and implementation diversity — a multi-client, multi-implementation ecosystem in 2026 could not coordinate a consensus-code fix in 5 hours.
• Post-event (long-tail): the value overflow bug became the canonical reference case for protocol-level integer-overflow vulnerabilities. The patterns it established — emergency client release, miner-coordinated chain reorganisation, permanent integration of the overflow check into consensus rules — recurred in subsequent Bitcoin protocol bugs (2013 hard-fork-inducing LevelDB upgrade incident, CVE-2018-17144 duplicate-input inflation bug) and in Ethereum ecosystem protocol-level incidents.

What this example tells contributors writing future Technique pages

• Protocol-client bugs are a distinct vulnerability class from smart-contract bugs. The Bitcoin value overflow was in C++ reference-client code, exploited at the consensus layer, and fixed via miner-coordinated chain reorganisation. Contributors writing future OAK v0.x Technique pages should consider whether a dedicated "Protocol-Client Consensus Bug" Technique class is warranted, with the Bitcoin value overflow as the foundational 2010 anchor.
• The 5-hour response window is a historically bounded pattern, not a generalisable expectation. 2010-era Bitcoin's small-community coordination enabled a response speed that modern multi-client ecosystems cannot replicate. Contributors writing response-time analysis for protocol-level incidents should treat the 2010 value-overflow response as a historically-bounded anchor, not as a benchmark for modern protocol security.
• Chain reorganisation as recovery instrument is established by this incident. The invalidation of block 74638 via miner-coordinated reorganisation is the earliest use of chain reorganisation as a protocol-level recovery instrument. The pattern recurs at VeriCoin 2014 (MintPal hot-wallet drain recovery via hard-fork rollback) and Ethereum DAO 2016 (hard fork). Contributors writing recovery-mechanism analysis should treat the Bitcoin 2010 value-overflow reorganisation as the chronological anchor.

Public references

• [bitcointalkoverflow2010] — BitcoinTalk forum. "Strange block 74638" thread, August 15, 2010. Primary-source contemporaneous discussion of the value overflow bug: https://bitcointalk.org/index.php?topic=822.0
• [bitcoincore0310] — Bitcoin Core. Release notes for Bitcoin 0.3.10. August 15, 2010. The fix release that added overflow checks to CheckTransaction() and related functions.
• [nakamotoresponse2010] — Satoshi Nakamoto. BitcoinTalk and source-code commit messages, August 15, 2010. Primary-source developer response to the value overflow incident.
• [cve20105139] — CVE-2010-5139. National Vulnerability Database entry for the Bitcoin value overflow vulnerability. (Assigned retroactively; the bug was fixed in 2010, the CVE identifier was assigned later as part of the broader CVE documentation effort for historical Bitcoin protocol vulnerabilities.)
• [bitcoinwikioverflow] — Bitcoin Wiki. "Value overflow incident." Community-maintained documentation of the 2010-08-15 event.
• [antonopoulosmastering] — Andreas M. Antonopoulos. Mastering Bitcoin, 1st and 2nd editions, O'Reilly Media. Discussion of the 2010 value overflow bug in the context of Bitcoin protocol security history.
• [narayanantextbook] — Narayanan, Bonneau, Felten, Miller, and Goldfeder. Bitcoin and Cryptocurrency Technologies, Princeton University Press, 2016. Academic treatment of the value overflow bug as the canonical early-Bitcoin protocol vulnerability.
• [safemathevolution] — OpenZeppelin, ConsenSys Diligence, Trail of Bits. SafeMath and Solidity overflow-check evolution — the Ethereum-ecosystem response to integer-overflow vulnerabilities (SafeMath library pre-0.8, Solidity 0.8+ built-in overflow checks, Solmate / Solady fixed-point arithmetic libraries). The 2010 Bitcoin value overflow bug is the intellectual predecessor to the Ethereum overflow-check formalisation.

Discussion

The Bitcoin value overflow bug (2010-08-15, block 74638) is the foundational protocol-vulnerability anchor on the OAK public record. The incident established the template for how consensus-level arithmetic bugs are discovered, exploited, and patched in permissionless blockchain networks, and the structural patterns — emergency client release, miner-coordinated chain reorganisation, permanent integration of the fix into consensus rules — have recurred across Bitcoin (CVE-2018-17144), Ethereum (DAO 2016 hard fork), and VeriCoin (2014 chain rollback).

The case is documented in OAK as the canonical T9.014 anchor — the foundational worked example establishing the Protocol-Client Consensus Bug Technique class. OAK-T9.014 captures C++/Rust/Go reference-client arithmetic and validation bugs at the consensus layer, distinct from smart-contract exploits (T9.001–T9.013). See techniques/T9.014-protocol-client-consensus-bug.md.

For OAK's year-coverage strengthening, the value overflow bug provides a third 2010 anchor alongside Mt. Gox launch (2010-07) and the Navinder Sarao CME spoofing case (2010-2015). The case is historically load-bearing: it documents that protocol-level arithmetic vulnerabilities predate smart contracts by 5+ years, and that the defensive patterns (safe-math, overflow-checked arithmetic, input-validation discipline) the Ethereum community formalised in 2017-2020 were retro-engineered against a vulnerability class that Bitcoin first encountered in 2010.

The case's attribution surface is structurally narrow — the attacker has never been publicly identified — but the incident itself is one of the most heavily documented protocol-vulnerability events in blockchain history, with primary-source contemporaneous records (BitcoinTalk, developer mailing list, source-code commits) and extensive secondary coverage in academic literature and security textbooks. Contributors writing attribution-strength analysis for early-Bitcoin incidents should preserve the distinction between the public-record documentation tier (extensive and primary-source-anchored) and the actor-attribution tier (pseudonymous and unresolved).