Module 08 gave you keys that own coins and signatures that spend them — but it leaned on a phrase it never earned: "entries on a shared public ledger." Two questions were left open. What is this ledger, and why can no one rewrite it? And what stops you from spending the same coin twice? This module answers both by building the structure that holds every transaction: the blockchain. It is, at heart, the tamper-evident chain of fingerprints you already built and broke in Module 02 — now carrying real transactions, bundled into blocks, hash-linked into a history that cannot be quietly altered. You will tamper with a working chain and watch it shatter downstream, then try to spend a coin twice and watch the ledger refuse. The humble hash, doing the deepest work in all of cryptocurrency.
Module 08 established that coins are entries on a shared public ledger, controlled by keys. But it deliberately left two questions hanging, and they are the questions a digital currency must answer to work at all. We tackle them head-on here.
First: what is this ledger, and why can no one rewrite it? In Bitcoin there is no master database at a bank. The ledger is the complete history of every transaction ever made, and copies of it are held by thousands of computers around the world. Your "balance" is not a number stored somewhere; it is whatever that shared history implies your keys can spend. But if the ledger is just data copied across thousands of machines, what stops someone from editing their copy — adding a transaction that pays themselves a million coins, or erasing one where they paid you?
Second, and even more fundamental: what stops double-spending? A digital signature proves you authorized a transaction — but nothing about a signature alone stops you from signing two transactions that spend the same coin, one paying Bob and one paying Carol, and sending each to a different person. Physical cash prevents this naturally: hand over a banknote and you no longer have it. But a digital coin is just data, perfectly copyable, and a signature can be made twice. This double-spending problem defeated every attempt at digital cash for decades — because solving it seemed to require exactly the central authority (a bank checking "has this coin already been spent?") that Bitcoin set out to eliminate.
Both answers lie in one structure, and it is built from a primitive you have already mastered. The blockchain uses hashing — the tamper-evident chain of fingerprints from Module 02 — to make the ledger's history practically impossible to rewrite, and it uses that same single shared history to establish an order of transactions, so the network can say which spend of a coin came first and reject any later one. The hash makes the ledger tamper-evident; the shared order makes double-spending detectable. Let us build it.
The ledger is the complete transaction history, copied across thousands of computers — raising two questions: why can no one rewrite it, and what stops spending a coin twice? The blockchain answers both with hashing: a chain of fingerprints (Module 02) makes history tamper-evident, and the single shared ordered history lets the network reject any second spend of a coin. No central authority required.
Transactions are not added to the ledger one at a time but gathered into batches called blocks. Roughly every few minutes (in Bitcoin, about ten), the recent transactions are bundled into a new block, which is appended to the end of the growing chain. Each block contains its batch of transactions, a timestamp, and — the crucial ingredient — the hash of the previous block.
That last element is the whole trick, and it is exactly the hash-linking you saw in Module 02, now carrying real money. Because each block embeds the fingerprint of the block before it, and that fingerprint depended on its contents (which included the fingerprint of the block before it), every block's hash effectively depends on the entire history that came before. The blocks are welded together into a chain by these fingerprints — hence "blockchain." The chain has a definite order: block 1, then block 2 referencing block 1, then block 3 referencing block 2, all the way to the latest. That ordering is what will solve double-spending.
And the chain is tamper-evident for the precise reason you discovered in Module 02's demo. Suppose someone alters a transaction in an old block — say, to erase a payment. That changes the old block's contents, so (by the avalanche effect) its hash changes completely. But the next block stored the old hash, which no longer matches — so the chain visibly breaks at that point. To repair it, the attacker must recompute that block's hash, which breaks the next block, and the next, all the way to the present. Altering one past transaction means rewriting every block from that point forward. The hash-linking turns the entire history into a single interlocked structure where no past entry can be quietly changed without visibly shattering everything after it.
Transactions are bundled into blocks, and each block contains the hash of the previous block, welding them into an ordered chain. Because every block's hash depends on all the history before it, altering any past transaction changes that block's hash and breaks every block after it — so the past cannot be quietly rewritten. It is Module 02's hash-linked chain, now carrying real transactions in a definite order.
A block may hold thousands of transactions, and the chain needs each block's hash to depend on every one of them, so that changing any single transaction changes the block's fingerprint. You could simply hash all the transactions together in a lump — but blockchains use a more elegant structure called a Merkle tree, and it is worth a look because it is hashing applied beautifully.
The idea: hash each transaction to get its fingerprint (the "leaves"), then hash those fingerprints together in pairs to get a smaller set, then hash those in pairs, and so on, until you are left with a single fingerprint at the top — the Merkle root. That one root value summarizes every transaction in the block: because of the avalanche effect, changing any single transaction changes its leaf hash, which changes its parent, and so on up to a completely different root. The block stores this Merkle root, and the block's own hash depends on it — so the block's hash commits to every transaction it contains, through one compact value.
Beyond efficiency, the Merkle tree has a lovely property: it lets someone prove a specific transaction is included in a block without downloading every transaction — they only need the handful of hashes along the path from that transaction up to the root. This is what allows lightweight wallets on your phone to verify a payment without storing the entire blockchain. For our purposes, the key point is simpler: the Merkle root is a single fingerprint of all the block's transactions, and the block's hash depends on it, so tampering with any transaction inside a block changes the block's hash — which, as we saw, breaks the whole chain after it. The demo next puts this together.
A Merkle tree hashes transactions in pairs, level by level, up to a single Merkle root that summarizes them all. Changing any transaction cascades up to a completely different root, and the block's hash depends on that root — so the block commits to every transaction it holds. It also lets a light wallet prove one transaction is in a block using only a few hashes, without the whole chain.
Here is the real thing: a working blockchain where each block holds actual transactions, computes a Merkle root over them, carries the previous block's hash, and computes its own hash from both (all real SHA-256, live). Every block is green and valid. Now edit any transaction — redirect a payment, change an amount — and watch that block's Merkle root change, which changes its hash, which no longer matches what the next block stored, turning every block from there to the end red.
Each block: real transactions → Merkle root → block hash (which includes the previous block's hash). Change a transaction and the break cascades to every later block. Real SHA-256, computed live.
The cascade is the whole point, and you have now seen it with genuine transactions rather than toy data. Tampering with one payment in block 2 does not just corrupt block 2 — it severs the chain from block 2 onward, because every later block's stored "previous hash" no longer matches. To make the forgery stick, an attacker would have to recompute block 2's hash and rebuild every block after it, faster than the rest of the world is extending the honest chain. Hashing alone makes tampering instantly visible; what makes it practically impossible to get away with is the work required to rebuild the chain and the race against everyone else — which is the subject of the consensus module. For now, hold the result: the past of a blockchain cannot be quietly edited, and that property comes entirely from the hash.
Now the deeper problem. Tamper-evidence stops someone editing the past, but double-spending is about the present: nothing stops you signing two valid transactions that each spend the same coin. Both signatures are genuine; both would verify. How does the network decide which one counts?
The answer falls out of the chain's single ordered history. When you spend a coin, your transaction is broadcast to the network and eventually included in a block — and from that moment, the shared ledger records that coin as spent. Every node, checking any new transaction, first asks: according to the ledger, is this coin still unspent? A transaction trying to spend a coin the ledger already shows as spent is simply rejected by everyone. Because all honest nodes share the same ordered chain, they all agree on which transactions have happened and in what order — so there is a definite, network-wide answer to "was this coin already spent?" The double-spend is caught not by a central bank checking a database, but by a shared history that everyone holds and validates.
See it directly. Below, Alice owns one coin. She spends it to Bob, and the ledger records it. Then she tries to spend the very same coin again, to Carol — the classic double-spend. Watch the network reject it, because the ledger already shows that coin spent.
Alice owns Coin #1. Spend it to Bob first, then try to spend the same coin to Carol. The shared ledger remembers.
The first spend was recorded; the second was rejected on sight, because the ledger every node holds already showed Coin #1 spent. This is the decades-old double-spending problem solved without a central authority: the shared, ordered, tamper-evident history is the authority. There is a subtlety we are glossing for now — what if Alice broadcasts both transactions at the exact same moment, before either is in a block, so different nodes see them in different orders? Resolving that race — deciding whose block, and whose ordering, becomes the agreed truth — is precisely the job of consensus, the next module. But once a transaction is settled into the chain, double-spending it is over.
Double-spending is solved by the single ordered history every node shares: once a coin is spent in the ledger, every node rejects any later transaction spending it. There is a definite, network-wide answer to "is this coin still unspent?" — enforced not by a central bank but by a shared chain everyone holds and checks. (Settling ties when two spends arrive at once is the job of consensus, next.)
We keep saying "every node holds the ledger," and that replication is itself a pillar of the design, so it is worth making explicit. There is no master copy of the blockchain anywhere. Instead, thousands of independent computers around the world — called full nodes — each store a complete copy of the entire chain and independently validate every block and transaction against the rules. No company, government, or server holds the authoritative version; the authoritative version is whatever the network of nodes collectively agrees on.
This is why tampering with the ledger is futile, beyond the hash-cascade problem. Suppose you edit your own copy of the chain to credit yourself extra coins. Your copy now disagrees with the thousands of others, and every other node, validating against the same rules, rejects your version as invalid. You have not changed "the ledger"; you have merely produced a copy that no one else accepts. To actually change the shared truth, you would need to convince the majority of the network to accept your altered chain — which, as the next module shows, requires out-working the entire rest of the network combined. Replication turns the ledger from a database that could be hacked in one place into a consensus that would have to be overpowered everywhere at once.
It also gives blockchains their striking transparency. Because the whole history is public and replicated, anyone can inspect every transaction ever made — the flows are completely open. This is a double edge worth noting honestly: it enables remarkable auditability (you can verify the system's total supply and rules yourself, trusting no one), but it also means privacy depends on the fact that addresses are not obviously tied to real identities — a property called pseudonymity, which is weaker than it sounds, since analysis of the public flows can often link addresses to people. We will return to genuine privacy in the final module on zero-knowledge proofs.
Thousands of independent full nodes each store and validate a complete copy of the chain; there is no master copy. A node that edits its own copy simply disagrees with everyone else and is rejected. To change the shared truth you would have to overpower the majority, not hack one database. Replication also makes the full history public — enabling self-verification, but only pseudonymous privacy.
It is tempting to say a blockchain is "immutable" — that its history can never be changed. In the evenhanded spirit of the course, the precise truth is more interesting: blockchain history is not mathematically impossible to change, it is practically infeasible to change, and understanding the difference matters.
Here is the honest version. Hashing makes any alteration to the past instantly detectable — that part is near-absolute, and you saw it. But detection is not prevention. In principle, an attacker could rewrite history: alter an old transaction, recompute that block's hash, and rebuild every block after it. What stops them is not that it is impossible but that it is staggeringly expensive — rebuilding the chain requires redoing all the work that went into those blocks, and doing it faster than the entire honest network is extending the real chain. As long as honest participants control the majority of the network's effort, an attacker simply cannot keep up, and their rewritten chain never becomes the accepted one. The immutability is economic and probabilistic, not a law of mathematics: it holds because attacking it costs more than it could ever yield, and because no one controls a majority of the network.
This is an important honesty, because it points exactly at the system's real risk and at the next module. If someone did amass a majority of the network's power — the notorious 51% attack — they could, in principle, rewrite recent history and double-spend. Bitcoin's security ultimately rests on the assumption that no single party controls a majority, and on the enormous cost of trying. So "immutable" really means "it would cost more to rewrite than anyone could rationally gain, as long as power stays sufficiently distributed." That is a strong guarantee in practice and a genuinely different kind of guarantee from the pure mathematics of a hash — and it is precisely the question the consensus module takes up: how a leaderless network agrees on the one true chain, and what it would take to subvert that agreement.
You now have the ledger: transactions bundled into blocks, hash-linked into a tamper-evident chain, replicated across thousands of nodes, establishing the single ordered history that solves double-spending. The data structure is complete. But a glaring question remains, and it is the one that turns a clever data structure into a working currency.
Who gets to add the next block? In a system with no central authority, no bank, no server in charge — who decides which pending transactions go into the next block, in what order, and gets to append it to the chain? If anyone could add blocks freely, an attacker could flood the network with their own blocks and rewrite history at will. If no one can, the chain never grows. And when two honest participants propose different next blocks at the same moment — or when an attacker proposes a fraudulent one — how does a leaderless network spread across the globe agree on which single block becomes the next link, so that everyone shares one history and not a thousand conflicting ones?
This is the problem of consensus, and it is the genuinely ingenious heart of Bitcoin — the part that had never been solved before 2008. The blockchain structure you built in this module is necessary but not sufficient; it tells you how to store an agreed history tamper-evidently, but not how to reach that agreement among mutually distrustful strangers with no leader. The next module answers it: proof-of-work and mining, how they make adding a block costly and adding a fraudulent chain hopeless, the alternative of proof-of-stake, and what the 51% attack really threatens. It is how the ledger you just built actually grows, securely, with no one in charge.
Six questions on the blockchain — what the ledger is, blocks and hash-linking, Merkle trees, how double-spending is solved, replication, and what "immutable" really means. The questions test the concepts you just saw in action.