BLOCKCHAIN & WEB3 FUNDAMENTALS - Chapter 3, Exercise 2 Solution
==========================================================
Why Altering an Old Block Cascades Forward

PROBLEM
-------
Explain precisely why an attacker who wants to secretly alter a
transaction from 5 blocks ago can't just recompute that one block's
hash and move on - walk through what actually breaks, block by block,
and what the attacker would have to redo to fix it.

SOLUTION
--------
Call the block the attacker wants to alter Block N, with five more
blocks (N+1 through N+5) already built on top of it by the honest
network.

Step 1: The attacker changes a transaction inside Block N. Because of
the avalanche effect, Block N's own transactions produce a different
Merkle root, and Block N's own header hash changes to something
completely different and unrelated to the original.

Step 2: Block N+1's header contains a field, "previous block hash,"
that was set to Block N's ORIGINAL hash when N+1 was originally mined.
That stored value no longer matches Block N's new, altered hash - the
link between N and N+1 is now broken and inconsistent.

Step 3: To make Block N+1 valid again, the attacker has to update its
"previous block hash" field to match Block N's new hash. But changing
any field in Block N+1's header changes Block N+1's OWN hash too - so
now Block N+1's hash has changed as well.

Step 4: This exact same problem repeats for Block N+2, since it stored
Block N+1's original hash - which the attacker just changed. And then
for Block N+3, N+4, and N+5, in the exact same cascading way.

So the attacker can't stop at recomputing Block N's hash alone - they
have to re-mine (redo the proof-of-work for) Block N and all five
blocks built on top of it, one after another, just to produce one
internally consistent alternate chain.

The attacker also has to do all of this faster than the honest network
adds new legitimate blocks on top of the real chain, or their
five-block-plus rewrite will still be shorter than - and therefore
rejected in favor of - the honest chain by the time they're done.

ANSWER: Recomputing Block N's hash alone isn't enough, because every
block built after it stored N's original hash as part of its own
header, and changing that stored value changes each of those blocks'
own hashes in turn - forcing the attacker to redo the proof-of-work for
every single block from N through the current tip, all while racing
the honest network's own continuing progress.

----
WHY THIS WORKS AS AN ANSWER

This walks through the exact cascading mechanism the chapter describes
(previous-block-hash storage plus the avalanche effect) step by step
for a concrete 5-block scenario, showing precisely why "just fix one
block" doesn't work rather than only asserting that it doesn't.