I. The Bug That Almost Destroyed Bitcoin

On the evening of August 15, 2010, Bitcoin’s network was 19 months old. The blockchain stretched 74,637 blocks deep. Only roughly 3.5 million BTC had been mined — a fraction of the eventual 21 million supply cap. Bitcoin had survived its first GPU mining crisis, the launch of BitcoinMarket.com, and the July 2010 mini-bubble. But nothing had prepared it for what was about to happen.

At 17:05 UTC, an anonymous miner produced Block 74638. Its coinbase hash recorded the moment: 0000000000790ab3f22ec756ad43b6ab569abf0bddeb97c67a6f7b1470a7ec1c. The block contained a single transaction — and that transaction threatened to destroy Bitcoin’s most fundamental property: its supply cap.

The block included a transaction that created 184,467,440,737.09551616 BTC — more than 8,000 times the total supply that should ever exist. If the network accepted this block, Bitcoin’s scarcity — the very feature that underlies its value proposition — would have been permanently compromised.

II. The Mechanics of the Exploit

The vulnerability, later classified as CVE-2010-5139, was an integer overflow bug in Bitcoin’s transaction validation logic — specifically in the CheckTransaction() and ConnectInputs() functions of the original Bitcoin client.

The Flaw

Bitcoin’s transaction outputs used a signed 64-bit integer (int64) to represent values in satoshis (1 BTC = 100,000,000 satoshis). The code correctly checked that individual output values were non-negative:

if (tx_out.nValue < 0)  // Check 1: individual output not negative
    return state.Invalid(...);

But it did not check whether the sum of all outputs could overflow. The attacker realized that by creating two outputs, each with a carefully chosen value, their sum would exceed the maximum representable value of a signed 64-bit integer — causing the arithmetic to wrap around to a negative number.

The attacker chose output values of 92,233,720,368.54277039 BTC each — exactly 2^63 / 10^8 satoshis, the largest positive value representable in int64. When summed:

• 2^63 + 2^63 = 2^64
• In int64 arithmetic, 2^64 wraps to 0
• 2^64 - 1 wraps to -1 (represented as -0.01 BTC = 1 satoshi)
• The code interpreted this negative sum as a transaction fee — a valid spending condition

The attacker spent a single input of 0.5 BTC (from a known faucet transaction) and sent the output to two addresses, creating 184.47 billion BTC from nothing.

III. Discovery: ‘Strange Block 74638’

At 23:08 UTC on August 15, 2010 — approximately six hours after the malicious block was mined — Bitcoin Core developer Jeff Garzik (jgarzik) posted a message on BitcoinTalk that would set off a chain reaction across the small community:

“The ‘value out’ in this block #74638 is quite strange: Value out: 92233720368.54277039? Is that UINT64_MAX, I wonder?”

The thread, titled “Strange block 74638” (Topic 822), immediately drew responses from the most technically active members of the community. lachesis quickly identified the number:

“It’s 2^⁶³⁄₁₀^8, so it looks like it’s INT64_MAX, not UINT64_MAX.”

Within minutes, theymos — the forum administrator who still manages BitcoinTalk today — recognized the gravity:

“This could be a serious problem.”

lfm dissected the exact technical mechanism, identifying why the code’s checks had failed:

“The code checks each transaction output for negative numbers individually (if (tx_out.nValue < 0) return;), but forgot to check that the sum of two outputs (or more specifically, that total output minus total input) is negative.”

The BitcoinTalk thread reveals a community that was simultaneously alarmed and methodical. There was no panic — just focused technical analysis, block explorer queries, and coordination toward a fix. In retrospect, this incident was the first major security crisis in cryptocurrency history, and the community’s response established a template for every emergency response that followed.

IV. Satoshi’s Emergency Fix

The response from Satoshi Nakamoto was swift and decisive. At 21:35 UTC on the same day — approximately 4.5 hours after Garzik’s initial report — Satoshi committed a fix to the Bitcoin SVN repository.

The commit (d4c6b90ca3f9b47adb1b2724a0c3514f80635c84) introduced three critical validations:

1. Added MAX_MONEY constant: A new system constant defined as 21000000 * COIN — exactly 21 million BTC in satoshis.

2. Output value validation (CheckTransaction()): Added checks that each individual output value was non-negative, did not exceed MAX_MONEY, AND that the cumulative sum of all outputs did not exceed MAX_MONEY.

3. Input validation (ConnectInputs()): Added analogous checks for input values — ensuring no input was negative, no single input exceeded MAX_MONEY, and the cumulative input sum was within bounds.

The version was bumped from 309 to 310, and Bitcoin v0.3.11 was released within hours — marking the fastest security patch in Bitcoin’s history. In the commit message, Satoshi wrote simply:

“Add checks for overflow, huge transactions, etc.”

This brief message understated the gravity of what had just been contained. Without this fix, Bitcoin’s 21 million supply cap — the cornerstone of its value proposition — could have been permanently violated.

V. The Chain Reorganization: A Soft Fork Resolves the Crisis

The most dramatic consequence of the overflow incident was a chain reorganization — the first of its kind in Bitcoin’s history. The network split into two competing chains:

Nodes running unpatched Bitcoin v0.3.10 continued mining on top of block 74638, generating approximately 53 additional blocks (74638 through ~74690) before the issue was fully resolved. Meanwhile, patched nodes running v0.3.11 rejected block 74638 entirely and built a competing chain starting from block 74637, the last valid block.

The fork was resolved at Block 74691 (hash: 00000000005c22d199706df1c38b38d76f8401920dcbe91edf3417f8847da707), generated on August 16, 2010. At this block height, the good chain — built by patched nodes — accumulated more proof-of-work than the bad chain, and the network converged. The bad chain was orphaned and its blocks — including the malicious transaction — were permanently excluded from the canonical blockchain.

This chain reorganization has profound implications for vintage coin archaeology. The ~53 blocks that were orphaned represent a ghost stratum — blocks that existed temporarily in Bitcoin’s history but were erased by the network’s consensus mechanism. The miners who produced those orphaned blocks lost their block rewards and transaction fees, a cost paid to preserve Bitcoin’s monetary integrity.

VI. The 0.5 BTC: A Frozen Vintage Artifact

Among the most remarkable aspects of this incident is the fate of the 0.5 BTC input used in the malicious transaction. This input came from a known Bitcoin faucet transaction — one of the earliest free-distribution mechanisms where early adopters could claim small amounts of BTC.

The input was consumed in the malicious transaction on Block 74638. When the chain reorganized and Block 74638 was orphaned, that 0.5 BTC was returned to the unspent state — technically, it remained in the UTXO set where it was before the attack.

But here is the archaeological detail: that 0.5 BTC has never been moved since August 15, 2010.

For over 16 years, this specific output has sat frozen — a permanent timestamp capsule of the moment Bitcoin’s supply cap was almost breached. It carries a unique on-chain provenance: the 0.5 BTC that was spent to create 184.47 billion BTC, consumed in a transaction that was ultimately erased from history.

This output is one of the most archaeologically significant vintage artifacts in Bitcoin. Unlike coins that simply aged through inactivity, this coin has a narrative signature — it was the input to an attack that nearly destroyed Bitcoin, survived the chain reorg, and has remained untouched ever since. It is money with a memory.

The First Emergency Security Response in Crypto History

The overflow incident also established the operational template for every subsequent cryptocurrency security crisis:

1. Discovery: A technically sophisticated community member detects an anomaly
2. Disclosure: Public reporting on a community forum (BitcoinTalk)
3. Diagnosis: Rapid peer review by other technical experts
4. Patch: The core developer (Satoshi) produces a fix within hours
5. Coordination: Network operators update their nodes
6. Resolution: A chain reorganization neutralizes the attack

This pattern — discovery, disclosure, diagnosis, patch, coordination, resolution — has been repeated dozens of times since 2010, from the Ethereum DAO hack (2016) to countless DeFi exploits. But the overflow incident was the first, and it happened when Bitcoin was still operating with fewer than 100 active nodes, a sub-cents price, and a community that could fit in a single IRC channel.

VII. Archaeological Stratification of the Incident

For the vintage coin archaeologist, the value overflow incident creates a distinctive time stratum in Bitcoin’s history:

Coins mined immediately before the incident (blocks 74630–74637) share a unique property: they are the last coins created in a Bitcoin that had no explicit supply-cap enforcement in its code. After block 74691, every Bitcoin created carries the cryptographic guarantee of MAX_MONEY validation — a protection that did not exist for the first 19 months of the network’s existence.

This distinction may seem abstract, but it is real: a coin from block 74630 was mined in a network where the 21 million cap existed only as a social contract and mining schedule agreement, while a coin from block 74692 was mined in a network where the cap was enforced by explicit code. The overflow incident transformed Bitcoin’s supply cap from a convention into a technical invariant.

VIII. The Legacy of the 184 Billion BTC Block

The Bitcoin value overflow incident of August 15, 2010, remains one of the most consequential events in cryptocurrency history — not because it succeeded (it did not), but because it revealed how fragile the network’s most fundamental property was at the time.

Today, every Bitcoin node enforces MAX_MONEY as part of its transaction validation. The fix that Satoshi committed in 4.5 hours has become part of Bitcoin’s permanent codebase, inherited by hundreds of cryptocurrency projects. The 0.5 BTC input sits frozen in the UTXO set, a 16-year-old witness to the crisis it triggered.

For the vintage coin collector, the coins that predate this incident — particularly those mined between January 2009 and August 15, 2010 — carry a unique premium. They were created in a Bitcoin that had never been tested by a supply-cap attack. They are coins from the innocent era, before Bitcoin’s scarcity was hardened into code. And the 0.5 BTC faucet coin, frozen since it was spent in the attack, remains one of the most archaeologically significant individual outputs in the entire blockchain — a single satoshi carrying the memory of 184 billion.

— Encryption Archive · coinage-history.com