Skip to content

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.

A changed fingerprint reveals changed data. It does not tell you whether the payment was allowed.

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.

One changed transaction changes its path to the root.

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.

Make it yours

A moment to try it.

Take your time. Explain the reason, not only the answer.

1 of 4

Someone records a hash of a fake shipping receipt on a blockchain. What does that prove by itself?

Choose the best explanation

Answers stay in this browser. Use examples only—never enter recovery words, keys, account details, or real balances.

Up next · Lesson 4.5The race to write the next page.
Sources & a little more detail

Illustrative stories and example numbers teach the mechanism. They are not forecasts or live market quotes.