Forks and Upgrades

Module 3 of Blockchain Fundamentals

What Is a Fork?

A fork occurs when the blockchain diverges into two potential paths. This can happen:

• Naturally (temporary disagreement)
• Intentionally (protocol upgrade)
• Contentiously (community split)

Types of Forks

1. Temporary Forks (Orphan Blocks)

Normal operation — two miners find blocks simultaneously.

        Block N
       /       \
  Block N+1a   Block N+1b  ← Two valid blocks
       |
  Block N+2
       |
  (Chain A wins, Block N+1b orphaned)

Resolution: Longest chain wins. Orphaned blocks are discarded.

Frequency: Happens regularly (Bitcoin: ~1-2 per day)

2. Soft Forks

Backward-compatible upgrades. Old nodes still work but don't understand new features.

Old rules: "Blocks up to 2MB are valid"
New rules: "Blocks up to 1MB are valid"

New blocks satisfy BOTH old and new rules
Old nodes accept new blocks (they're valid)
New nodes reject old-style blocks (if >1MB)

Key property: Tightens rules (subset of previous valid states)

Examples:

• SegWit (Bitcoin, 2017) — new transaction format
• Taproot (Bitcoin, 2021) — improved scripts and privacy

Activation: Typically requires miner/validator signaling

3. Hard Forks

Non-backward-compatible changes. Old nodes reject new blocks.

Old rules: "Blocks up to 1MB are valid"
New rules: "Blocks up to 8MB are valid"

Old nodes: REJECT new 8MB blocks (invalid!)
New nodes: ACCEPT new 8MB blocks
→ Chain splits permanently (unless old nodes upgrade)

Key property: Loosens or changes rules

Examples:

• Ethereum Constantinople — new opcodes
• Bitcoin Cash fork — increased block size

Requirement: All nodes must upgrade or be left behind

4. Contentious Forks

Hard forks where the community disagrees, resulting in two surviving chains.

Result: Two separate cryptocurrencies with shared history up to fork point.

Soft Fork vs Hard Fork

Fork Activation Mechanisms

1. Flag Day

Activate at a specific block height or date.

if (block.height >= 500000) {
  useNewRules();
}

Pro: Simple, predictable Con: No guarantee of miner support

2. Miner Signaling (BIP9)

Miners signal readiness in block headers.

Activation threshold: 95% of blocks in period
Signaling period: 2016 blocks (~2 weeks)

If 95% signal: Activate after delay
If not: Try again or give up

Pro: Ensures miner support Con: Gives miners veto power

3. User-Activated Soft Fork (UASF)

Nodes enforce new rules regardless of miner signaling.

August 1, 2017: Nodes reject non-SegWit blocks
Miners forced to comply or mine worthless blocks

Pro: Economic nodes have power Con: Contentious, risky

4. Speedy Trial (BIP8)

Hybrid approach — quick signaling window, then UASF.

3-month signaling period
If 90% signal: Activate
If not: UASF activates anyway after delay

Used for: Taproot (2021)

The DAO Fork: A Case Study

What Happened (2016)

1. The DAO: A $150M decentralized investment fund
2. The Hack: Attacker exploited reentrancy bug, drained $60M
3. The Debate: Should we "undo" the hack?

Arguments

For rollback (eventually Ethereum):

• Obvious theft should be reversed
• DAO was 14% of all ETH
• Attacker shouldn't profit

Against rollback (eventually Ethereum Classic):

• "Code is law"
• Sets dangerous precedent
• Who decides what's "theft"?

Result

• Hard fork to recover funds → Ethereum (ETH)
• Original chain continues → Ethereum Classic (ETC)
• Both chains still exist today

Lessons

1. Immutability has nuances
2. Social consensus can override code
3. Controversial decisions split communities
4. Both positions have legitimate arguments

Bitcoin's Block Size War

The Conflict (2015-2017)

Bitcoin hit ~7 TPS limit. Two camps emerged:

Big Blockers:

• Increase block size (2MB, 8MB, unlimited)
• On-chain scaling
• Bitcoin as payment system

Small Blockers:

• Keep 1MB blocks
• Layer 2 scaling (Lightning)
• Bitcoin as settlement layer

Key Events

• 2015-2016: Debate intensifies
• Feb 2016: Hong Kong Agreement (failed)
• May 2017: New York Agreement (failed)
• Aug 2017: SegWit activates via UASF
• Aug 2017: Bitcoin Cash forks off

Result

• Bitcoin: 1MB blocks + SegWit + Lightning
• Bitcoin Cash: 8MB→32MB blocks
• BTC remains dominant by market cap

Lessons

1. Governance is hard without authority
2. Economics (market cap) resolves disputes
3. Both visions can coexist as separate chains
4. Soft forks can avoid splits

Upgrade Governance Models

Bitcoin: Conservative

• Slow, deliberate changes
• High bar for activation (95%)
• Prioritizes stability
• Major upgrades rare

Ethereum: Progressive

• Regular hard forks (every ~6 months)
• Core devs coordinate upgrades
• More willing to change
• "Move fast" mentality (relatively)

Comparison

How to Survive a Fork

For Users

1. Don't transact during uncertainty
2. Control your keys (not on exchange)
3. Wait for clarity before moving coins
4. Back up before fork (you'll have coins on both chains)

Replay Attacks

After a fork, transactions might be valid on both chains.

You send 1 BTC on the BTC chain
Attacker replays same transaction on BCH chain
You lose 1 BCH too

Protection: Forks should implement replay protection (different transaction formats).

Key Takeaways

1. Forks are normal — temporary forks happen constantly
2. Soft forks are safer — backward compatible, lower split risk
3. Hard forks can split chains — contentious ones create new coins
4. Governance is the real challenge — who decides what changes?
5. Market resolves disputes — value flows to preferred chain
6. Both positions can be valid — forks let communities diverge

Questions to Consider

1. Should The DAO hack have been reversed?
2. Who should have power to change Bitcoin?
3. Is "code is law" realistic or desirable?
4. How many Bitcoin forks can you name?