Bitcoin's security rests on economic and cryptographic foundations. This chapter examines the attacks that could threaten these foundations: 51% attacks that enable double-spending, chain reorganizations that reverse confirmed transactions, selfish mining that distorts incentives, and network-level attacks that isolate nodes. Understanding these threats is essential for evaluating Bitcoin's resilience.
36.1 The 51% Attack
Definition 36.1 (51% Attack)
A 51% attack (majority attack) occurs when an entity controls more than half of the network's mining power, enabling:
- Double-spending confirmed transactions
- Preventing transactions from confirming
- Preventing other miners' blocks from remaining in the best chain
Definition 36.2 (Double-Spend Attack)
A double-spend uses the same coins twice:
- Attacker sends coins to victim (Transaction A)
- Victim sees confirmations, delivers goods/services
- Attacker mines secret chain spending same coins to self (Transaction B)
- Attacker releases longer secret chain
- Network reorganizes; Transaction A is reversed
Theorem 36.1 (Attack Success Probability)
Let q be attacker hashrate fraction, p = 1 − q honest hashrate, and k the number of confirmations. The probability of a successful double-spend (Nakamoto, 2008) is:
P(success) = 1 if q ≥ 0.5
and, if q < 0.5, the value given by Nakamoto's formula, stated as Theorem 14.2 and derived by the gambler's-ruin argument of Theorem 26.3. In that case the probability decreases geometrically in k, dominated by the catch-up factor (q/p)ᵏ.
Numerical values are tabulated in Section 14.8. Two readings of that table matter for security policy. First, confirmations buy exponential safety only against a minority attacker: at q = 0.10, six confirmations leave a success probability of about 0.02%, but at q = 0.40, even twelve confirmations leave about 31%. Second, no confirmation count protects against a majority attacker: the q ≥ 0.5 case of Theorem 36.1 is the formal content of the term "51% attack". Exchanges and merchants therefore scale confirmation requirements with the value at risk and with their estimate of plausibly attainable hashrate (Chapter 37).
36.2 Chain Reorganizations
Definition 36.3 (Chain Reorganization)
A reorg occurs when a node switches to a different chain with more cumulative proof-of-work:
- Depth: Number of blocks replaced
- Natural reorg: Competing blocks found simultaneously (1-2 blocks)
- Attack reorg: Intentional, deeper reorganization
Example 36.1 (Historical Reorgs)
| Date | Depth | Cause |
|---|---|---|
| August 2010 | 53 blocks | Value overflow bug (184B BTC created) |
| March 2013 | 24 blocks | Version 0.8 bug (accidental fork) |
| Normal | 1 block | <0.05% of blocks today (stale blocks; ~0.5% before compact-block relay) |
Remark 36.1 (Reorg Probability)
Under honest mining with network delay δ and block time T, the following approximations hold:
- P(1-block reorg) ≈ δ/T; with modern relay δ/T < 0.0005 (<0.05%, Example 36.1), historically ~0.005–0.01
- P(2-block reorg) ≈ (δ/T)² < 10⁻⁶ at the modern δ/T
- P(k-block reorg) ≈ (δ/T)ᵏ (approximately)
In particular, P(6-block honest reorg) ≈ (δ/T)⁶ < 10⁻¹⁹ at δ/T = 0.0005.
36.3 Selfish Mining
Definition 36.4 (Selfish Mining)
Selfish mining is a strategy where miners withhold blocks:
- Find a block; withhold it
- Continue mining on secret chain
- When honest miners find block, release secret chain
- Goal: Waste honest miners' work, gain unfair advantage
Theorem 36.2 (Eyal and Sirer, 2014)
Selfish mining is profitable when attacker hashrate q satisfies:
q > (1 − γ) / (3 − 2γ)
where γ is the fraction of honest miners who mine on the attacker's block during a race. With γ = 0: q > 1/3 ≈ 33%. With γ = 1: q > 0 (any hashrate suffices). The strategy and threshold are due to Eyal, I. and Sirer, E. G. (2014), "Majority Is Not Enough: Bitcoin Mining Is Vulnerable," Financial Cryptography and Data Security, where the result is proved by Markov-chain analysis of the withholding strategy.
Remark 36.2 (Selfish Mining in Practice)
No selfish-mining episode has been conclusively identified on mainnet. Contributing factors:
- Requires sustained >25-33% hashrate
- Detectable through orphan rate analysis
- Risk of losing secret chain to honest miners
- Damages network, potentially harming attacker's investment
36.4 Eclipse Attacks
Definition 36.5 (Eclipse Attack)
An eclipse attack isolates a node from the honest network:
- Attacker floods victim's peer table with attacker-controlled IPs
- Victim restarts or all connections drop
- Victim connects only to attacker nodes
- Attacker controls victim's view of blockchain
The attack and its feasibility against Bitcoin's peer selection were analyzed by Heilman, E., Kendler, A., Zohar, A., and Goldberg, S. (2015), "Eclipse Attacks on Bitcoin's Peer-to-Peer Network," USENIX Security Symposium.
Remark 36.3 (Eclipse Attack Consequences)
An eclipsed node can be:
- Double-spent against: Fed fake confirmations
- Censored: Transactions not propagated
- Delayed: Kept on stale chain
- Exploited: For N-confirmation attacks with 0 hashrate
Remark 36.4 (Eclipse Mitigations)
Bitcoin Core includes mitigations:
- Outbound connection diversity (different /16 networks)
- Anchor connections (persist across restarts)
- Peer rotation limits
- Feeler connections to discover new peers
36.5 Other Attack Vectors
36.5.1 Transaction Censorship
Definition 36.6 (Transaction Censorship)
Miners can refuse to include specific transactions:
- Soft censorship: Some miners refuse; tx eventually confirms
- Hard censorship: >50% refuse; tx never confirms normally
36.5.2 Block Withholding
Definition 36.7 (Block Withholding Attack)
In pool mining, a malicious miner:
- Submits partial proofs of work (shares)
- Withholds full solutions (valid blocks)
- Receives pool payments without contributing blocks
- Damages pool profitability
36.5.3 Time-Dilation Attack
Definition 36.8 (Time-Dilation Attack)
Against Lightning Network nodes:
- Eclipse the victim
- Slowly feed them blocks (delayed)
- HTLCs time out on victim's view before actual expiry
- Steal funds from payment channels
The attack is described by Riard, A. and Naumenko, G. (2020), "Time-Dilation Attacks on the Lightning Network."
36.6 Attack Economics
Remark 36.5 (51% Attack Cost)
The cost of a 51% attack includes:
- Hardware: ASICs to achieve majority hashrate
- Electricity: Ongoing operational cost
- Opportunity cost: Could mine honestly instead
- Market impact: the expectation that attack discovery would depress the price
Example 36.2 (Attack Cost Estimation)
Rough 51% attack cost (mid-2026, ~360+ EH/s network, cf. Chapter 14):
| Component | Cost |
|---|---|
| Hardware (~360+ EH/s to match) | $10–20 billion |
| Electricity (per day) | $20–50 million |
| Rental attack (if possible) | $1–5 million/hour |
These figures are rough, order-of-magnitude estimates, and the attack is hardware-availability-bound: neither purchasable nor rentable hardware exists at this scale for Bitcoin.
Exercises
Exercise 36.1
Calculate the probability of a successful double-spend with 30% hashrate after 6 confirmations. How many confirmations would reduce this to <0.1%?
Exercise 36.2
Model a selfish mining attack with 35% hashrate and γ = 0.5. What is the expected revenue advantage over honest mining?
Exercise 36.3
Design an eclipse attack against a Lightning node. What information would you need? How would you exploit the time-dilation?
Exercise 36.4
Research the Bitcoin Gold 51% attacks. How much was stolen? What was the estimated attack cost? Why was BTG more vulnerable than BTC?