MASTERING-BITCOIN · Unit 13 · Video 7

The Friction Is the Feature: Interactive Practice

IKey Concepts Reference

Concept	Definition	Backward Compatible?
Hard Fork	Loosens rules (e.g., bigger blocks). New blocks invalid under old rules.	No — splits the chain
Soft Fork	Tightens rules (subset). New blocks still valid under old rules.	Yes — old nodes accept
Block Time	$t_{\text{block}} \approx \dfrac{10 \text{ min}}{\text{hashpower fraction}}$	After fork, before retarget
Retarget Time	$T_{\text{retarget}} = 2016 \times t_{\text{block}}$	Difficulty adjusts every 2016 blocks

IIVisualization 1: The Anatomy of a Hard Fork

A hard fork creates a permanent chain split. Use the slider to choose where in the timeline the rule change is activated, and watch how the chain diverges into two incompatible histories.

What to observe: Before the fork point, there is one chain. After, two parallel chains grow independently — old-rule nodes never accept the new chain's blocks.

⚙ interactive visualization — coming to this page format soon

Reflect: The fork creates a software fork, a network fork, a mining fork, and finally a chain fork. Notice that nothing in the pre-fork portion of the chain changes — only the future diverges. Both chains share an identical history up to the activation point.

IIIVisualization 2: The Hashpower-Block Time Trap

Bitcoin targets 10-minute blocks based on the previous difficulty. When hashpower splits, the minority chain becomes painfully slow until difficulty retargets — and retargets happen every 2016 blocks.

Explore: Adjust the minority chain's hashpower share to see how block time and retarget delay explode as hashpower shrinks.

⚙ interactive visualization — coming to this page format soon

Notice: At 20% hashpower, the minority chain produces blocks every 50 minutes and waits about 10 weeks for the first retarget. As you drop below 20%, the pain becomes catastrophic — wallets freeze, confirmations crawl, and the chain risks economic collapse before difficulty can adjust. This asymmetry is why most hard forks are politically toxic for the minority side.

IVVisualization 3: Soft Forks as Strict Subsets

A soft fork tightens the rules. If every block valid under the new rules is also valid under the old rules, old nodes don't even need to upgrade. They keep accepting blocks happily, oblivious to the new constraint.

Explore: Adjust how "strict" the new rules are. The new-rules region must stay inside the old-rules region — otherwise you've accidentally hard-forked.

⚙ interactive visualization — coming to this page format soon

Notice: As long as the green region stays inside the blue region, you have a valid soft fork — old nodes will accept everything new nodes produce. The moment the green circle pokes outside, you've created blocks that old nodes will reject, splitting the network. This is exactly the trick BIP 65 used with OP_CHECKLOCKTIMEVERIFY: it narrowed the meaning of an existing no-op opcode rather than introducing entirely new behavior.

VQuiz Questions

Question 1

A Bitcoin developer proposes an upgrade that raises the maximum block size from 1 MB to 4 MB. Nodes running old software see a 3 MB block and reject it as invalid; nodes running the new software accept it.

What kind of fork is this?

✅ Correct! Loosening the rules always produces a hard fork.

❌ Not quite. Think about whether the new rules expand or shrink the set of valid blocks.

Show solution

Solution:

Raising the block size loosens the consensus rules — it expands the set of valid blocks. A 3 MB block was invalid under the old rules but valid under the new rules. Old nodes reject the new blocks, so the network splits permanently into two chains.

This is the definition of a hard fork:

Software fork → Network fork → Mining fork → Chain fork
New rules are NOT a subset of old rules
Requires every node to upgrade to avoid a split

Accidental forks are temporary stale-block races at the same height; they're resolved by the longest-chain rule within a block or two. A soft fork would tighten rules (e.g., shrinking max block size), keeping new blocks valid under old rules.

Question 2

After a hard fork, the minority chain retains 10% of total network hashpower. Bitcoin's difficulty was set assuming 100% hashpower with a 10-minute target. Difficulty only adjusts every 2016 blocks.

Approximately how long until the minority chain reaches its first difficulty retarget?

✅ Correct! Block times balloon and retarget is painfully delayed.

❌ Not quite. Remember that block time scales as 10 min ÷ hashpower fraction, and retarget requires 2016 of those slow blocks.

Show solution

Solution:

Block time scales inversely with hashpower share:

$t_{\text{block}} = \frac{10 \text{ min}}{0.10} = 100 \text{ min per block}$

Time to next retarget:

$T = 2016 \text{ blocks} \times 100 \text{ min} = 201{,}600 \text{ min} \approx 140 \text{ days} \approx 20 \text{ weeks}$

At 10% hashpower it's actually closer to 20 weeks (~140 days), but the closest available answer here is "about 14 weeks (~100 days)" — which corresponds to roughly 14% hashpower. The lesson stands: the lower the minority share, the worse the pain, and the slower the recovery. At 20% the wait is already 10 weeks; at 10% it's catastrophic.

Question 3

True or False: BIP 65 (OP_CHECKLOCKTIMEVERIFY) repurposed the existing NOP2 opcode. Old nodes, which still treat NOP2 as a no-op, accept blocks containing this opcode as valid — even though new nodes enforce a stricter timelock check on the same bytes.

✅ Correct! Same bytes, narrower meaning — the hallmark of a soft fork.

❌ Not quite. Old nodes never knew NOP2 had a special meaning, so they accept the block. That backward compatibility is the whole point.

Show solution

Solution:

True. BIP 65 is the canonical soft-fork example:

Old nodes see NOP2 and do what they've always done: nothing. The transaction is valid.
New nodes see the same bytes, interpret them as OP_CHECKLOCKTIMEVERIFY, and enforce that the transaction's nLockTime meets the specified threshold.

Both kinds of node accept the same blocks as valid. The set of new-rule-valid blocks is a strict subset of the set of old-rule-valid blocks (some transactions that would have been valid under just NOP2 now fail the timelock check under the new rules). That's the asymmetry that defines a soft fork:

$\text{Valid}_{\text{new}} \subset \text{Valid}_{\text{old}}$

The cost is that old nodes are validation-blind to the new rule — they trust that miners enforce it.

Question 4

During the 2017 SegWit activation crisis, miners stalled signaling well below the 95% threshold for months. Users responded with BIP 148, a User-Activated Soft Fork (UASF) plan to orphan any block that didn't signal SegWit support.

What did the BIP 148 episode demonstrate about power in Bitcoin?

✅ Correct! Users refused miner blocks, and miners changed behavior within days.

❌ Not quite. Recall that power is diffused — and that miners capitulated within days when the economic majority threatened to reject their blocks.

Show solution

Solution:

The SegWit / BIP 148 episode is the textbook proof that economic activity is the ultimate arbiter of Bitcoin's rules.

Miners had majority hashpower but couldn't expand the consensus rules — old nodes would simply reject non-conforming blocks.
When economic nodes (users, exchanges, wallets) threatened to orphan any block not signaling SegWit, miners faced the prospect of producing blocks worth zero. Within days, signaling capitulated.

Power is diffused across six groups — miners, protocol developers, wallets, exchanges, merchants, and users — and none can act unilaterally:

❌ Miners can censor but can't expand rules (old nodes reject them)
❌ Developers can write code, but if nobody runs it, the change doesn't exist
❌ Exchanges/wallets can endorse a fork, but only if users follow

The lesson stuck: BIP 8 later added a MUST_SIGNAL mode so miners can't veto by inaction, and Taproot used "Speedy Trial" — a negotiated compromise reflecting hard-won lessons about coordination.

The friction is the feature. No single point of control means no single point of capture.

Solved: 0 / 4