Famous Incidents & Attacks

Theory tells you what should happen. These incidents and attacks tell you what did — and what an adversary will actually try. Each one is a lesson that’s hard to forget once you’ve seen it, and most engineers have never heard of half of them.

The Value Overflow Incident (CVE-2010-5139)

On 15 August 2010, block 74638 contained a transaction that created over 184 billion BTC out of thin air — more than 8,000× the entire intended 21-million supply — splitting it across a couple of outputs.

The bug was a classic integer overflow. Bitcoin checks that a transaction’s outputs don’t exceed its inputs, but the output values were summed into a signed 64-bit integer. By crafting outputs whose sum wrapped around past the maximum back to a tiny number, the attacker made the total appear valid:

output 1: 92,233,720,368.54 BTC   ┐
output 2: 92,233,720,368.54 BTC   ┘  sum OVERFLOWS the 64-bit accumulator
                                     → wraps to a small/negative value
                                     → "outputs ≤ inputs" check PASSES �both

The response is the real lesson. Within ~5 hours Satoshi and others released a patched client that rejected the overflow, and the network coordinated a soft fork: miners adopted the new rules, built an alternative chain that excluded the bad block, and that chain — by accumulating more work — became the truth. The bogus 184 billion BTC was erased from the canonical history.

Why this is reassuring, not scary

This is the only time the 21-million supply was ever violated, and it’s the most powerful live demo of how Bitcoin self-heals. “Truth = the most-work valid chain” (see Satoshi’s synthesis) means a critical bug doesn’t require a trusted authority to roll back — it requires the economic majority to run corrected software and let the honest chain out-work the bad one. A new value-overflow check (MoneyRange) has guarded every amount since.

The double-spend family

“You can’t double-spend Bitcoin” is shorthand for “you can’t double-spend a deeply confirmed transaction cheaply.” Against unconfirmed or shallow transactions, several attacks exist — which is the real reason the zero-conf myth is dangerous.

Race attack (0 confirmations)

The attacker sends two conflicting transactions almost simultaneously: one paying the merchant, one paying themselves. They ensure the merchant’s node sees the payment first (so goods are released) while pushing the self-paying version to the rest of the network, hoping it gets mined.

Finney attack (0 confirmations, requires mining)

A miner pre-mines a block containing a transaction that pays themselves, but doesn’t broadcast it. They then make a conflicting payment to a merchant; the moment the merchant accepts the zero-conf payment and hands over goods, the miner releases the withheld block, which confirms the self-paying version and orphans the merchant’s. Named after Hal Finney, who first described it.

The 51% attack (deep reorgs)

With a majority of hash power, an attacker can mine a longer, conflicting chain in secret and release it to reorg away confirmed history — double-spending coins that looked settled, and censoring transactions. What 51% cannot do: steal coins from addresses they don’t have keys to, or forge signatures, or inflate the supply. Smaller chains with low hash power get 51%-attacked regularly; Bitcoin’s hash rate makes it astronomically expensive, which is the entire economic security argument.

confirmations     cost / difficulty to reverse
   0 (mempool)    trivial — race / RBF / Finney
   1              low — a lucky single block
   3              meaningful
   6              very high (the classic "settled" bar)
  100+ (coinbase) effectively impossible

Selfish Mining

A subtle, beautiful, and unsettling result (Eyal & Sirer, 2013): a miner with a large minority of hash power can earn more than their fair share by withholding blocks instead of publishing them honestly.

1. Selfish miner finds a block → keeps it SECRET, mines on it privately (now 1 block ahead).
2. Honest network is unknowingly working on the OLD tip, wasting effort.
3. When honest miners publish a block, the selfish miner releases their longer secret chain,
   orphaning the honest block and claiming the rewards.

By strategically revealing a pre-built lead, the selfish miner makes honest miners waste work on doomed blocks, raising the selfish miner’s relative revenue above their hash-rate share. The disturbing implication: the “everyone publishes immediately” honest strategy isn’t obviously a Nash equilibrium, so block propagation, tie-breaking rules, and pool dynamics matter for security — not just raw hash power. (In practice, detection risk, reputation, and the difficulty of the required network position have kept it from being a routine strategy.)

Transaction Pinning (the modern Lightning threat)

This one is current and few understand it. Recall RBF and CPFP: to rescue a time-sensitive transaction you must be able to fee-bump it. Pinning is an attack that removes that ability at the worst possible moment.

The attacker exploits mempool policy limits — e.g. the rule that an unconfirmed transaction can only have a bounded size/number of descendants, or that a low-fee replacement can be blocked:

A time-critical tx (e.g. claiming a Lightning HTLC before its timelock expires)
        │
        ▼
Attacker attaches a HUGE, LOW-fee child to it ("pins" it):
   • the package is now too big to bump cheaply, OR
   • replacement rules refuse the honest party's higher-fee version
        │
        ▼
The honest party CAN'T get their claim confirmed in time → timelock expires
        │
        ▼
Attacker sweeps the funds via the now-valid timeout branch.

Because Lightning’s safety depends on getting certain transactions confirmed before a deadline, pinning can translate “I jammed the mempool” into “I stole channel funds.” Mitigations are an active area of protocol work: package relay, ephemeral anchors, and v3 transaction relay are all recent changes designed to make HTLC claims reliably bumpable and to neuter pinning. This is the frontier of Bitcoin’s adversarial engineering today.

The thread

How does this help untrusting strangers agree on one ledger? Every attack here is an attempt to make the ledger say something false — mint coins, reverse a payment, jam a claim, profit from withheld truth. Bitcoin’s defenses are almost never “a trusted party fixes it.” They’re economic: make attacking cost more than it earns (PoW, deep confirmations), or structural: change the rules so the attack stops working (overflow checks, v3 relay). Studying the attacks is how you learn why each defensive design decision exists.

Check your understanding

1. What kind of bug caused the 184-billion-BTC incident, and what does the recovery teach you about where Bitcoin’s authority actually lives?
2. Distinguish a race attack from a Finney attack. Which one requires the attacker to mine?
3. What can a 51% attacker do — and, precisely, what can it not do?
4. In one sentence, why does selfish mining earn more than fair share despite producing no extra blocks overall?
5. Explain how transaction pinning converts a mempool-policy quirk into theft of Lightning funds, and name one mitigation.