The Inflation Bug First Announced as a Crash

The rule that was being broken

Every transaction input points to a previously created unspent output, and an output can be spent only once. The check passes through several layers: transaction pre-checks, block validation, and updates to the UTXO set.

The vulnerability allowed one transaction inside a block to reference the same input twice. Some versions would terminate. Under other conditions, internal state could accept both spends and leave excess value in the transaction’s outputs.

How an optimization opened the path

Bitcoin Core 0.14 removed a repeated duplicate-input check from early block processing. Later UTXO logic was expected to catch the violation, and one code path did fail an assertion.

A redesign in 0.15 subtly changed that assertion. When the duplicated output came from an earlier block, the second spend could pass without a crash. An optimization removed layered protection; a later refactor altered the remaining guard.

Why an ordinary peer could not exploit it directly

The invalid transaction had to appear inside a block. A normal peer could not simply relay it through the mempool because standard checks would reject it. Exploitation required a miner willing to construct the special block.

That raised the cost but did not make the risk acceptable. If economically important vulnerable nodes accepted the block, a chain containing BTC outside the schedule could emerge while patched nodes rejected it.

The first hours

An anonymous reporter described the crash at 14:57 UTC on September 17 to developers from several Bitcoin projects. At 17:47 the inflation consequence was identified. Work began to contact mining pools and important infrastructure.

At 21:57 a patch and a denial-of-service test were published. Version 0.16.3 was tagged overnight, with binaries and an urgent upgrade announcement following on September 18.

Why the announcement mentioned only a crash

Immediate inflation details would also have served as guidance for an attacker. Developers disclosed the less severe crash effect and used the same patch to give the network time to upgrade.

This was a compromise, not perfect transparency. Users learned the true need for an urgent update but temporarily not the maximum consequence. Full disclosure followed on September 20 after information began spreading and a large share of mining had upgraded.

What happened in practice

The official disclosure said developers knew of no mainnet exploitation. The vulnerability was later exercised on testnet: old nodes crashed or accepted an invalid branch and then required manual intervention.

The testnet event showed that the danger was not imaginary. The lack of a known mainnet attack also shows the value of rapid reporting, coordinated updates, and restrained early disclosure.

What survived the patch

Consensus code is dangerous to optimize even when a check looks redundant. Defensive layers can depend on one another in ways that become visible only after a later change.

Open development does not guarantee every bug will be found before release. The flaw existed across multiple public versions despite review.

Decentralization does not eliminate human coordination during an emergency. Developers could not force upgrades, but they could publish a fix, communicate urgency, and contact operators whose response affected network risk.

Disclosure policy today

Bitcoin Core now publishes severity levels and disclosure timing. Low-severity issues are described soon after fixes; medium and high issues generally wait until the affected branch reaches maintenance end. Critical cases may need an ad-hoc process.

Delay should not become permanent secrecy. Its purpose is to give users a real chance to update and then preserve a public record of the bug, fix, and decisions.