Dossier 02 Source-led history · Edition 1.0
Bitcoin Consensus Incidents: Inflation Bugs, Chain Splits and Repairs
Bitcoin’s transaction history is governed by deterministic rules, but those rules are implemented by fallible software. Four incidents show why proof-of-work, validation, implementation compatibility, and human coordination cannot be treated as interchangeable.
In this dossier
At a glance
Verified record
| Date | Incident | Verified record | Disposition | Source |
|---|---|---|---|---|
| 15 August 2010 | Value overflow | A transaction in block 74,638 created outputs totaling more than 184 billion BTC by exploiting arithmetic validation. | Patched clients rejected the transaction and accumulated work moved to a corrected history. | [2] Block 74,638 repair |
| 11–12 March 2013 | 0.7/0.8 chain split | Bitcoin 0.8 accepted a block that some older Berkeley DB-based nodes could not process, producing two competing chains. | Major pools moved production to the 0.7-compatible branch; BIP 50 documented the event. | [3] March 2013 chain-fork post-mortem |
| 4 July 2015 | BIP66 invalid chain | After strict-DER enforcement began, miners extending a block without full validation produced a six-block invalid branch. | Fully validating nodes rejected it; miners lost the rewards on the invalid branch. | [5] Some Miners Generating Invalid Blocks |
| 5 July 2015 | Second BIP66 fork | A further invalid branch extended for three blocks while some miners were still not fully validating parents. | The valid chain again became strongest; users of affected software were advised to wait additional confirmations. | [5] Some Miners Generating Invalid Blocks |
| 17–20 September 2018 | CVE-2018-17144 | Developers discovered that affected versions could crash and, in a narrower case, accept inflation through an intra-block double spend. | Versions 0.16.3 and 0.17.0rc4 fixed the bug; no exploitation was known at disclosure. | [7] CVE-2018-17144 full disclosure |
‘Bitcoin was hacked’ hides several different failure classes
A consensus exploit creates or accepts state forbidden by the intended rules. An implementation divergence occurs when software versions disagree about what the rules mean in practice. An invalid-chain incident occurs when miners build proof-of-work on a block that fully validating nodes reject. A vulnerability can threaten consensus without ever being exploited. Exchange thefts and wallet compromises are different again: they may lose coins without changing the rules or accepted chain.
Keeping these categories separate is not an attempt to minimize harm. It identifies the control that failed and the evidence required to reconstruct it. Block records can show an invalid creation or competing branches. Source diffs can show the validation mistake. Release notices and post-mortems can establish the recovery procedure. Claims about an exploit’s absence must remain bounded by what maintainers reported knowing.
The 2010 overflow exploit violated the intended monetary boundary
At block 74,638, a transaction exploited integer arithmetic in output-value checking and created two enormous outputs whose total exceeded the intended supply by orders of magnitude. The transaction passed the software then in use. The episode is therefore stronger than a hypothetical bug: invalid monetary state entered the chain recognized by unpatched participants.
The repair introduced an explicit maximum-money constant and checked the accumulated output total. Patched software rejected the offending transaction. As miners and nodes adopted the correction, more proof-of-work accumulated on the valid replacement history and the old branch was abandoned. The sequence combined an intended rule, a code correction, software distribution, and renewed mining; no one of those steps was sufficient alone.
In 2013, a database limit became a consensus rule by accident
Bitcoin 0.8 replaced Berkeley DB with LevelDB. A block with an unusually large number of transaction inputs was processed by 0.8 but exceeded lock limits for some older nodes. The result was a network-wide split: both sides considered their own branch valid, and the 0.8 branch initially had more hash power. The familiar ‘most work’ shorthand could not unite nodes that disagreed about validity.
Developers and major pool operators coordinated a temporary return to the 0.7-compatible branch. BTC Guild and Slush downgraded, sacrificing expected revenue so the branch accepted by older software would overtake the other. BIP 50 later documented both the technical cause and the intervention, including an experimental double spend. Compatibility behavior that had never been designed as consensus had become consensus in practice.
BIP66 exposed the risk of mining without validating
BIP66 tightened signature encoding rules. Once its threshold was reached in July 2015, upgraded nodes began rejecting version-2 blocks. A miner produced an invalid block, and substantial hash power extended it without independently validating the parent. The first invalid branch reached six blocks; another three-block fork followed the next day.
The miners had signaled readiness to enforce the new rule but did not behave as their signals implied. Fully validating current nodes rejected the branches immediately, while lightweight and older software could assign them misleading confirmation weight. The public warning advised affected users to wait 30 additional confirmations. The lesson was not that hash power was irrelevant, but that hash power without validation could deepen an invalid history.
The 2018 inflation vulnerability was repaired before known exploitation
CVE-2018-17144 arose from an optimization that removed a duplicate-input check from an early validation stage. Depending on version and transaction construction, an invalid block could crash a node or allow a miner to spend the same prior output twice within one block, inflating the accepted state. The bug affected released versions, but Bitcoin Core’s disclosure said maintainers were unaware of an attempt to exploit it.
The reporter contacted developers on 17 September 2018. Maintainers first treated the report as a denial-of-service issue, recognized the inflation consequence, privately contacted miners and businesses, and released 0.16.3 on 18 September. Full technical disclosure followed on 20 September after the upgrade effort was under way. The record illustrates a security trade-off between immediate transparency and limiting an exploitation window.
Recovery depends on validity rules before it depends on accumulated work
Across the four cases, participants did not vote directly on a historical narrative. They installed or ran software whose validation behavior accepted one set of blocks and rejected another. Miners then supplied work to a branch compatible with that behavior. Communication mattered because it changed software adoption and mining decisions, but messages and prominent developers could not make an incompatible block valid to an unchanged node.
This history cuts against two simple slogans. ‘The longest chain always wins’ omits the prior validity test. ‘Code is law’ omits the need to diagnose defects, choose repairs, and coordinate deployment when implementations fail to express intended rules. A precise account can recognize Bitcoin’s recovery record while preserving the difference between deterministic validation and the social process that maintains its implementations.
Four consensus incidents, four different failure paths
The ordered record distinguishes exploitation, implementation divergence, invalid-parent mining, and an unexploited vulnerability.
- Overflow exploited
Invalid creation entered block 74,638; patched validation rejected it and a replacement history overtook the branch.
- Database divergence
0.8 and older nodes disagreed; miners intentionally redirected work to the 0.7-compatible branch.
- Invalid parent extended
Miners signaling BIP66 readiness built six blocks on a parent that fully validating nodes rejected.
- Second invalid branch
A three-block repeat showed the risky mining practice had not yet ended.
- Vulnerability reported
A crash report was recognized as including a possible inflation path.
- Patched release
Bitcoin Core 0.16.3 shipped while maintainers contacted affected infrastructure.
- Full disclosure
Maintainers described the inflation consequence and reported no known exploitation.
Evidence discipline
What the record establishes
The 2010 exploit created outputs far above the intended monetary limit and was removed from the ultimately accepted history.
[1] Overflow incident report · [2] Block 74,638 repairThe 2013 0.8 branch initially had majority hash power, and major pools downgraded to restore the older-compatible branch.
[3] March 2013 chain-fork post-mortemThe July 2015 invalid branches lasted six and three blocks respectively.
[5] Some Miners Generating Invalid BlocksNo attempt to exploit CVE-2018-17144 was known when Bitcoin Core published its full disclosure.
[7] CVE-2018-17144 full disclosureLimits
What this record does not establish
- ‘Rollback’ is descriptive but can mislead: incompatible nodes did not edit the same database in place; they followed competing branches and later converged through validation and accumulated work.
- An absence of known exploitation in a maintainer disclosure is not proof that no attempt occurred anywhere.
- Exchange, custodian, wallet, and key-management failures should not be added to a consensus-incident count unless they changed accepted protocol state.
Source register
Primary records and technical references
Retrieved and reviewed 8 August 2026- Overflow incident reportBitcoinTalk · primary contemporaneous discussion
Participants publicly identified the anomalous output transaction and coordinated investigation.
Open source - Block 74,638 repairBitcoin source repository · primary source-code commit
The patch added explicit accumulated-output bounds for the overflow incident.
Open source - March 2013 chain-fork post-mortemBitcoin Improvement Proposals · primary technical post-mortem
The cause, branch behavior, pool downgrade, double spend, resolution, and follow-up actions.
Open source - BIP 66Bitcoin Improvement Proposals · primary specification
The strict-DER consensus change whose activation exposed invalid-parent mining.
Open source - Some Miners Generating Invalid BlocksBitcoin.org · primary contemporaneous alert
The six- and three-block forks, affected software, validation behavior, and public safety advice.
Open source - Bitcoin Core 0.16.3 releaseBitcoin Core · primary software release
The date and initially disclosed denial-of-service fix.
Open source - CVE-2018-17144 full disclosureBitcoin Core · primary security disclosure
The inflation path, affected versions, disclosure timeline, mitigation, and no-known-exploitation statement.
Open source
Cite this dossier
A stable, versioned reference
Degrees of Satoshi editorial project. “Bitcoin Consensus Incidents: Inflation Bugs, Chain Splits and Repairs.” Degrees of Satoshi, version 1.0, 8 August 2026. https://degrees-of-satoshi.pages.dev/history/bitcoin-consensus-incidents/
Contemporary primary records are preferred. Protocol behavior, business failures and government policy are treated as separate evidence categories. Interpretive claims are explicitly bounded; corrections should cite a source at least as strong as the record being revised.
Read the research standards