Decentralized Systems · Blockchain PoW

Key Question

What attacks threaten the security of proof-of-work blockchains?

Deep Dive

51% Attack

If an entity controls >50% of total hashpower:

Can Do	Cannot Do
Reverse own transactions (double-spend)	Create coins out of thin air
Prevent transactions from confirming	Steal coins from others
Censor other miners’ blocks	Change the protocol rules

51% attack timeline:

  Honest chain:   ──A──B──C──D──E──F  (merchant ships goods after 6 confs)
  Attacker chain: ──A──B──C──D'─E'─F'─G' (attacker mined secretly, longer!)
                  ↑  ↑  ↑
                Blocks D, E, F replaced!
                Attacker's old transaction (which paid the merchant)
                never happened in the attacker's chain → coins returned.

Mitigations: monitoring services (Blockchain.info alerts), checkpointing, reputable mining pools avoiding consolidation.

Selfish Mining (Eyal & Sirer, 2014)

A miner with >25% of hashpower can gain more than their fair share by strategically withholding blocks:

Selfish mining strategy:

  Honest miners (public):     ──A──B──C──D──E (working on latest)
  Selfish miner (secret):     ──A──B──  C──D (withheld C and D)

  1. Selfish miner finds block C but doesn't broadcast it
  2. Honest miners find their own block C' (wasting work)
  3. Selfish miner now has a private lead of 1-2 blocks
  4. If honest miners catch up, selfish miner broadcasts their chain
  5. Honest miners see the selfish chain as longest → switch to it
  6. Selfish miner's blocks get included; honest C' is orphaned

Result: the selfish miner earns revenue greater than their hashpower percentage, making mining more profitable for attackers. With ~33% hashpower, a selfish miner can destabilize the entire system.

Hashpower	Selfish Revenue (vs honest)
25%	~25% (threshold begins)
33%	~40% (profit > fair share)
50%	100% (monopoly)

Other Attacks

Attack	Description	Mitigation
Eclipse attack	Fill a node’s peer table with attacker-controlled peers, isolate it from the real network	Random selection, test connections, diversifying peer sources
Sybil attack	Create many fake identities to surround a target	Identity cost (PoW for node IDs in S/Kademlia)
Long-range attack	In PoS: create a fork from the genesis to rewrite history	Checkpointing, weak subjectivity
Feather forking	Threaten to orphan any block containing a specific address	Reputation systems, out-of-band enforcement
Timejacking	Lie about timestamps to desync nodes	Reject timestamps >70 min from local time

Why PoW Security Holds

Despite these attacks, Bitcoin has never been successfully 51% attacked (it’s economically irrational — the attack destroys the value you’d steal). The security model is: it’s cheaper to mine honestly than to attack.

Check Your Understanding

What can a 51% attacker do? What can’t they do?
Explain selfish mining: how does >25% hashpower give unfair revenue?
How does Bitcoin’s current hashpower (~200 EH/s) make a 51% attack economically impractical?

The “So What?”

No system is perfectly secure. The genius of Nakamoto consensus is that it aligns incentives so that attacking the network costs more than the attack is worth. The threat model isn’t “nobody can attack” — it’s “attacking is economically irrational.”

✏️ Exercises

Exercises: Blockchain & Proof of Work

Exercise 1

If the Bitcoin network has 200 EH/s (2 × 10^20 hashes per second) and you have 1 PH/s (10^15 hashes per second), what is your probability of mining the next block?

Exercise 2

What prevents someone from changing a transaction in block #100,000? Be specific — mention the cryptographic structures involved.

Exercise 3

Why is selfish mining with 25% hashpower dangerous? What revenue advantage does the attacker gain?

Exercise 4 (Challenge)

Suppose Bitcoin’s block time is 10 minutes on average. You’re a merchant who waits for 6 confirmations before shipping. If the attacker has 40% of the total hashpower, what’s the probability they could produce a longer chain than the honest miners after 6 blocks? Assume the honest miners have 60% and blocks follow a Poisson process. (Hint: this is a variant of the “gambler’s ruin” / race problem described in the Bitcoin whitepaper.)

👁️ View Solutions

Solutions: Blockchain & Proof of Work

Exercise 1

Probability of mining the next block.

P = your_hashpower / total_hashpower P = (1 × 10^15) / (200 × 10^18) P = 1 / 200,000 P = 0.000005 = 0.0005%

In plain terms: you’d expect to mine a block once every 200,000 blocks. At 10 min/block, that’s about 3.8 years of continuous mining.

Exercise 2

Why block #100,000 transactions can’t be changed.

Each block contains the hash of the previous block in its header. Block #100,000 links to block #99,999’s hash. Changing a transaction in block #100,000 changes the Merkle root of the transaction tree, which changes the block header, which changes the block’s hash. That hash is referenced by block #100,001. You’d need to:

Recompute PoW for block #100,000 (new nonce)
Recompute PoW for block #100,001 (different prev_hash now)
Recompute PoW for all blocks up to the current tip (~857,000+ blocks)

That’s more than 757,000 blocks of PoW — computationally infeasible without >50% of the total network’s hashpower.

Exercise 3

Selfish mining danger.

With 25% hashpower, the selfish miner can gain more than 25% of block rewards by:

Withholding found blocks instead of broadcasting immediately
Letting honest miners waste work on competing blocks
Broadcasting their private chain at the right moment to orphan honest blocks

This breaks the core security assumption (“one-CPU-one-vote” means fair share). A rational miner with 25% hashpower is incentivized to become selfish, which degrades network security for everyone. At 33% hashpower, the attacker earns ~40% of rewards — a significant unfair advantage.

Exercise 4 (Challenge)

Attacker probability after 6 confirmations with 40% hashpower.

This is Nakamoto’s race: attacker catches up from z blocks behind, where z=6.

q = attacker hashpower = 0.4 p = honest hashpower = 0.6

Probability attacker catches up from z blocks behind:

P = (q/p)^z   when q < p
P = 1         when q ≥ p

P(attacker catches up from 6 behind) = (0.4/0.6)^6 = (0.667)^6 ≈ 0.0879 ≈ 8.8%

That’s an uncomfortably high probability for a $10M transaction. This is why:

Exchanges wait 30+ confirmations for large deposits
Zero-confirmation transactions are risky with >0% attacker hashpower
The whitepaper formula assumes the attacker works continuously; real attackers may be less patient

With q=0.3 (30%), P = (0.3/0.7)^6 = (0.429)^6 ≈ 0.62% — much safer.