Learn · episode 02

Blocks & chains

In episode 1 you made fingerprints and mined for lucky ones. Now we stack those fingerprints into linked records. Editing an earlier record changes its fingerprint, exposing a mismatch when someone checks the stored links. Everything runs in your browser.

First look · fictional records · SHA3-256 calculated here

Why does an old edit affect later links?

Three payment records form a chain. Before changing the first amount, predict: which stored link will stop matching first?

  1. Record 1

    Start of this example

    Ali pays Siti 5 coins

    Stored fingerprint of previous record
    start
    This record’s fingerprint · unchanged
    bcb95949c109929c073cc7108609d4b3daa0f19d365de3204b96eef22ca0505d

  2. Record 2

    Link matches

    Siti pays Devi 2 coins

    Stored fingerprint of previous record
    bcb95949c109929c073cc7108609d4b3daa0f19d365de3204b96eef22ca0505d
    This record’s fingerprint · unchanged
    51fa884a5ff09d9dc73a3efa17dc178f85acda045267236b4962ec539da16ad7

  3. Record 3

    Link matches

    Devi pays Raju 1 coin

    Stored fingerprint of previous record
    51fa884a5ff09d9dc73a3efa17dc178f85acda045267236b4962ec539da16ad7
    This record’s fingerprint · unchanged
    21a56773c6231ee455a885041ece45f2354fb8e2ddacbb438c46e47be3a0c00f

Step 0 of 3. Both links match. Each later record stores the fingerprint of the record immediately before it.

These are local hash links, not Bitcoin blocks. There are no signatures, balance checks, mining targets or network participants here. Recalculating fingerprints does not authorise a payment or replace other people’s history. A real network also checks its transaction and consensus rules.

Bitcoin’s block links and validation rules ↗

Explain it back: someone repairs their own copy

Someone changes an earlier payment and recalculates every later link on their laptop. Why does that not establish that everyone else has accepted the changed payment?

Compare with an explanation

Their copy can be internally consistent while failing the network’s other rules. Other participants validate transactions and apply consensus rules to competing histories. Matching links show a relationship between records, not permission to spend or agreement from a network.

01 · anatomy

What’s inside a block

This toy block focuses on three fields: some data (say, a ledger entry), the previous block’s hash (its lineage), and a nonce (a value the miner varies). A hash meeting the target demonstrates the proof of work. Real block headers include additional fields; the historical example below shows Bitcoin’s format.

block #7

✗ invalid

prev hash: the lineage

000a3fc8b7e21d904c55f10287e6f3b19d2c4a8e0f6b5d3c2a190807e6d5c4b3

the fingerprint of block #6, baked into this block’s own hash

nonce: varied by the miner

0

hash: the fingerprint

sealed only while it starts with “000”

Edit the data and the seal breaks instantly, because the old nonce is worthless against the new fingerprint. That’s the avalanche effect from episode 1, now guarding a ledger entry.

02 · the chain

Chain them together

Here’s the trick that turns blocks into a blockchain: every block includes a reference to the hash of the block before it. That reference links the records. Try changing any ledger entry below, especially an early one, and watch what happens downstream.

forging the chain, mining 5 blocks…

block #1 Genesis

✗ broken

nonce 0

prev 000000 (genesis)

block #2

✗ broken

nonce 0

prev

block #3

✗ broken

nonce 0

prev

block #4

✗ broken

nonce 0

prev

block #5

✗ broken

nonce 0

prev

03 · the real thing

A real one

The toy chain illustrates links between hashes; Bitcoin uses a more detailed header and consensus rules. Here is the most famous block ever mined, the very first, with every header field annotated. You’ll recognise all of them.

Bitcoin block #0, the genesis block

Real, historical block
version
1
which rule-set the miner followed
prev block hash
0000000000000000000000000000000000000000000000000000000000000000
all zeros: there is no block before the genesis block, exactly like block #1 in your chain above
merkle root
4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
one hash summarising every transaction in the block; real blocks carry thousands at once
timestamp
2009-01-03 18:15 UTC
the timestamp recorded in the block header
bits (difficulty)
0x1d00ffff
compact encoding of the proof-of-work target
nonce
2,083,236,893
the successful nonce value; it does not reveal how many attempts the miner made
hash
000000000019d6689c085ae165831e9934ff763ae46a2a6c172b3f1b60a8ce26
ten leading hex zeros; every Bitcoin block since chains back to this fingerprint

Inside its single transaction, Satoshi Nakamoto left a newspaper headline as a timestamp proof: “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks.” The first block’s data field was already making a point about the system it replaced.

Bitcoin targets an average interval of about 10 minutes; actual intervals vary

transaction counts vary with transaction size and block capacity

anyone, anywhere can re-verify the entire history, and that’s the point

next up

Episode 03: Consensus & proof of work Play now →

You have checked local links. Next: how network participants choose between competing histories under shared rules.

Building something that needs this to be right? →