Part 3 · Blocks & the Blockchain
A “blockchain” is a humble idea once you have hashing: a linked list where each link is glued by a hash. Change anything in the past and every later hash breaks. This part shows exactly how — from the anatomy of a single block up to what happens when two miners collide.
It comes after Transactions and leans on hashing and Merkle trees from Cryptography. It sets up Proof of Work & Mining, where the “most work” rule becomes mechanics you can compute.
Roadmap for this part
Section titled “Roadmap for this part”- Anatomy of a Block — a block = header + transaction list; the coinbase transaction that comes first; size vs weight (vbytes, weight units, the witness discount); how the Merkle root commits to every transaction.
- The Block Header (80 bytes) — the six fields (version, prev block hash, Merkle root, timestamp, bits, nonce), why exactly these, and why the header is the thing miners hash.
- Merkle Trees & SPV Proofs — how one root commits to all transactions, how a Merkle proof shows inclusion in O(log n), and how light clients verify payments without the full chain.
- Chaining Blocks: prev-hash & immutability — why editing block N invalidates blocks N+1, N+2, …; how this makes rewriting history expensive instead of trivial.
- Block Validation Rules — every check a full node runs (proof of work, Merkle root, no double-spends, scripts, conservation, limits, timestamps, coinbase value) — and why each node verifies independently.
- Orphans, Stale Blocks & Reorgs — what happens when two miners find a block at once, why the most-work chain wins, and why we wait for confirmations.
The recurring question, applied here
Section titled “The recurring question, applied here”How does chaining blocks with hashes help untrusting strangers agree on one ledger? It makes the order and contents of history tamper-evident, so “rewriting the past” is detectable — and rejected — by everyone, with no authority in charge.
Start with Anatomy of a Block →