Step 6 / The Bitcoin Machine
Fingerprints that connect a payment to history.
Follow a payment’s digital fingerprint into a block, then into the chain.
Maya’s payment sits among other payments in a proposed block. A computer needs a way to notice if someone changes one of them. It can calculate a digital fingerprint from the data.
Next, it can combine fingerprints into one result for the group. We will build that result with four payments, then see how it helps check whether a payment belongs in a particular block.
A small change makes a different fingerprint
Imagine a message that says “Pay 10.” A calculation turns its data into a fixed-size code. Run the exact same data through the same calculation again, and you get the same code. This calculation is a hash function, and its result is a hash.
Now change the message to “Pay 11.” The result will normally look very different, even though only one digit changed. That makes hashes useful for checking whether supplied data matches a recorded fingerprint.
A hash is not an encrypted copy of the message. You cannot use it to recover any original document you want. It is a way to check data you have, not a box holding the whole document.
It also cannot tell you whether a statement is true. A fake shipping receipt has a hash just as a real receipt does. Recording that hash does not prove a delivery happened or a payment was allowed.
Same message bytes, same result. “Pay 10” produces the displayed SHA-256 prefix.
Check one payment in a group of four
Picture four transaction identifiers, labeled A, B, C, and D. Each identifier is a fingerprint of transaction data. Maya’s transaction is C. We want to connect C to a single fingerprint for the whole group.
First, put A and B together and hash that pair. Then put C and D together and hash that pair. Finally, put the two pair results together and hash them. The last result is called the Merkle root, and the branching pattern is called a Merkle tree.
To check C’s path to the root, start with C and the neighboring identifier D. Hash them in the correct left-to-right order. Then combine that result with the hash of the A-and-B pair, again in the right order. Check whether the result matches the stated root.
The checker needs D’s identifier and the A-and-B pair hash, but not the full contents of A, B, or D. This small path is called a Merkle proof. It shows how C connects to that root.
The path stays small as a balanced tree grows. With 256 transaction identifiers, there are eight pairing steps from one identifier to the root. The checker needs one neighboring hash at each step, for eight in total.
This proves a connection to a particular root. It does not yet prove that the root belongs to a block in the accepted chain. It also does not check every payment, tell us whether Maya’s new output is still unspent, or prove her friend delivered anything.
Hash transaction identifiers in pairs, then hash the pair results together. The drawing omits real hash strings.
The written example follows C’s proof path. The interactive tree does a different job: it shows what changes when the first payment is edited. Both use four items, but neither displays every field in a real block.
The next block points to this block’s fingerprint
A Bitcoin block contains transactions and a compact summary called its header. The header includes the Merkle root and the previous block’s hash. That previous hash links the new block to a particular earlier block.
Suppose someone edits an old payment amount. Its transaction identifier changes, which changes the Merkle root. Because the root is in the header, the header’s hash changes too.
The next block still points to the old hash. Its link no longer matches the edited block. This mismatch makes the edit visible.
An owner of a private database could recalculate hashes and rebuild links. Hashing alone does not make that hard. Bitcoin adds proof of work and independent rule checks. Those extra parts make an accepted replacement history difficult to establish.
These labelled fingerprints are a simplified illustration, not real block hashes.
An inclusion check is only one check
A Merkle proof connects an identifier to one stated root. You still need to establish that the root belongs to a block in the accepted chain. Fully checking that block means checking more than the path.
The proof also cannot tell you whether an output was spent later. It cannot prove a real-world delivery. Each of those questions needs other information.
Real Bitcoin has another detail beyond our four-item model. Ordinary transaction identifiers leave out witness data, which includes information used to prove spending permission. SegWit adds a separate commitment that connects that witness data to the block. The small tree teaches the path idea, not every part of this real structure.
Checking data and keeping it are different jobs
A full node can check the rules and later delete eligible old block data to save space. This is called pruning. Keeping every old raw block forever is different from checking it.
A lightweight wallet may use information supplied by other computers instead of doing every full-node check itself. That gives it different things to trust. A smaller storage need alone does not tell you which checks were performed.
The idea to keep
Start with one identifier, combine it with its neighboring hash, and repeat until you can compare the root. In a balanced tree with 256 identifiers, that path needs eight neighboring hashes. It establishes inclusion under that root, with further checks still needed.
Fingerprints reveal changes. Next, we will see the work a miner does to find a block-header result that meets Bitcoin’s target.