Historical Hard Forks: BTC vs. BCH vs. BSV

The history of Bitcoin is defined by its ability to resist Hard Forks that would dilute its scarcity or centralize its protocol. However, several significant splits have occurred, each providing a case study in consensus.

1. The Bitcoin Cash (BCH) Split (2017)

The most famous hard fork occurred on August 1, 2017. The primary disagreement was over "Scaling":

• BTC Side: Wanted to scale via SegWit and Layer 2 (Lightning Network). They prioritized low node-running costs (small blocks).

• BCH Side: Wanted to scale by increasing the base Block Size limit (initially to 8MB).

The result was a permanent split. Bitcoin (BTC) maintained the vast majority of hashrate and market value, while Bitcoin Cash (BCH) became a separate altcoin.

2. The Bitcoin SV (BSV) Split (2018)

In 2018, the Bitcoin Cash community itself split again.

• BCH ABC: Wanted to add new opcodes and technical features.

• BSV (Satoshi Vision): Wanted to remove all limits on block size (massive blocks) and revert to a "locked" version of the 0.1 protocol.

This "Hash War" resulted in another permanent split, creating Bitcoin SV.

3. The SegWit2x Failure

Not all proposed hard forks succeed. In late 2017, a group of large businesses and miners proposed SegWit2x, which would have hard-forked Bitcoin to 2MB blocks.

• The Conflict: Users and small-node runners (the "UASF" movement) refused to upgrade.

• The Result: Lacking community consensus, the developers cancelled the fork just days before it was scheduled to happen. This solidified the idea that in Bitcoin, users (nodes) have more power than miners.

4. Why BTC Rarely Hard Forks

Bitcoin's extreme resistance to hard forks is seen as a feature, not a bug. It ensures that the rules of the money cannot be changed easily by any small group of developers or corporations.

Property	BTC	BCH	BSV
Max Block Size	4MB (Weight)	32MB	Unlimited
Consensus Philosophy	Decentralization	Throughput	Enterprise Scale
Nodes	Easy to run	Expensive to run	Data-center only

In the final article of this module, we will build a Python Fork Validator to see how nodes detect and reject hard-forked blocks.