Module 4 · The Bitcoin Machine / 4.4
How a blockchain remembers.
Change one line and watch the links stop matching.
Imagine a notebook in which the top of each page contains a short fingerprint of the previous page.
You quietly change an old payment. The next page still remembers the original version. The two no longer match. This is the first part of what a blockchain does.
A fingerprint made from data.
A hash function takes data and produces a fixed-size result. Bitcoin uses SHA-256 in several places. Its result contains 256 bits, commonly written as 64 hexadecimal characters.
The same bytes give the same result. Change the bytes, even slightly, and the result will usually look completely different. Recomputing and comparing hashes makes unexpected changes easy to notice.
A hash is not encryption. It has no secret decryption key. Nor is it a certificate that the original message was true. You can hash a false claim just as easily as a true one.
Same message bytes, same result. “Pay 10” produces the displayed SHA-256 prefix.
Because there are more possible messages than fixed-size results, different messages must sometimes share a hash. The security requirement is that finding useful collisions or reversing the function is computationally infeasible. A small predictable message can still be guessed and checked.
Open one block.
A Bitcoin block contains transactions and a compact header. The header includes a reference to the previous block, a summary of the current transactions, a timestamp, and fields used to verify proof of work.
That transaction summary is called a Merkle root. It is built by hashing transaction identifiers together in pairs, then pairing those results, until one result remains.
Change one transaction and its branch of this tree changes, all the way up to the root. Because the root is in the header, the block’s own fingerprint changes too.
This tree also allows a compact inclusion proof. A verifier can combine a transaction’s identifier with the neighbouring hashes along its path and check the expected root. That shows inclusion in a particular block; it does not independently establish that the whole block obeyed every Bitcoin rule.
Hash transaction identifiers in pairs, then hash the pair results together. The drawing omits real hash strings.
The next page remembers this one.
Each block header contains the previous block header’s hash. Now the notebook picture becomes concrete: transactions affect the root, the root affects the header, and the header’s hash is written into the next block.
If someone edits an old transaction, the following block still points to the old fingerprint. To construct a consistent replacement history, they must update the link and rebuild the descendants.
Hashing alone makes this inexpensive. Anyone can calculate new hashes. The expensive part in Bitcoin is producing the required proof of work for the replacement blocks while other miners continue extending the accepted history.
These labelled fingerprints are a simplified illustration, not real block hashes.
Full nodes also reject transactions that violate their rules. An attacker cannot make a forged signature acceptable simply by attaching a long chain of hashes.
A durable record has conditions.
People often call blockchains immutable. For Bitcoin, it is more precise to say that accepted history becomes increasingly costly to replace as valid work accumulates, under its security assumptions. Recent reorganizations can happen. Software flaws and human coordination also belong in an honest account.
And a blockchain does not verify a fact outside its own rules. Recording “this box contains gold” does not put gold inside the box. A reliable connection to the outside world is a separate problem.
The history also consumes storage and bandwidth. A full node validates the chain; a pruned full node can discard old block data after validation while retaining what it needs to keep checking. Full validation and permanent storage of every old block are different choices.
The idea to keep
A blockchain links blocks through hashes. In Bitcoin, the transaction tree, previous-block reference, proof of work and independent validity checks work together. None of those pieces alone makes every recorded statement true.