Ralph Merkle

You want to send an encrypted message. The recipient needs a secret key to read it, but how do you deliver that key when someone watches every message? In his 1978 paper, Ralph Merkle described a surprising approach: the sender prepares many encrypted puzzles, the recipient randomly solves one and publicly returns the identifier hidden inside it. Both now know a shared key. The listener sees the identifier too, but does not know which puzzle contained it. In the model described, the listener therefore needs much more work: the cost grows quadratically with the size of the task, while the participants’ work grows linearly. This is a quadratic gap, not an exponential one; a historical breakthrough is not a present-day recommendation for encrypting messages. [1]

The adversary’s permissions matter in the 1978 paper. Eavesdropping is allowed, but alterations and forgeries are still assumed to be detectable. Imagine someone who reads letters, then someone who also rewrites them and signs your name. The latter case needs another protection: establishing whom you are actually talking to. A difference in computational work does not settle that question. The puzzles therefore do not imply that arbitrary communication through an active intermediary is safe. Their contribution is showing how agreement can be possible without a previously shared secret key, under the stated assumptions. [1]

A Merkle Tree tackles a different problem. This authentication tree appears in Merkle’s 1979 dissertation. Imagine an archive of contracts: you want to check a particular contract without downloading the whole archive. Each item is hashed to produce a short digital fingerprint. Pairs of fingerprints are combined and hashed again until a single root remains. Hashing does not encrypt the contents; it supports checking a match. For the check to mean anything, you need a previously authenticated root: a fingerprint already verified as belonging to the correct archive. If a fraudster could supply both a document and an arbitrary root, a match between them would establish nothing about the original archive. [2]

Take a balanced binary tree containing 8 items. To check a chosen leaf, you need 3 sibling hashes: one fingerprint of the neighbouring branch at each level. Starting with your leaf and these fingerprints, you calculate the root and compare it with the authenticated root. The leaf itself and root are not included in those supporting hashes. You must also know the tree’s structure and the order of combination: whether each sibling goes on the left or right. This saving is not a trick with hidden data. Distant parts of the archive are represented by their fingerprints, so their complete documents are unnecessary for this particular check. [2]

A Merkle Tree establishes a relationship between an item and a particular dataset. It does not make an incorrect statement true. Our archive could contain a contract with the wrong name; a proof could correctly establish its inclusion without detecting the mistaken name. Likewise, a fingerprint does not establish the authority of whoever created the document. Separate the questions: does this item match this root, how do I know the root, and what rules govern acceptance of the contents? This distinction helps explain what the same technique can do in Bitcoin and what other parts of the system must provide. [2]

Bitcoin uses a Merkle Tree to connect transactions to a block header, the block’s compact record. The root is part of the header; changes to the included transactions affect their combined fingerprint. Satoshi Nakamoto describes this construction in section 7 of the whitepaper and lists Merkle’s work among the references. This documents technical influence, not authorship of Bitcoin. A Merkle tree does not select a valid history or check transaction signatures on behalf of nodes. Bitcoin combines it with other rules, including transaction verification and Proof of Work, evidence of computational effort. Understanding one component is more useful than attributing the powers of the whole system to it. [3]

Section 8 of the whitepaper describes SPV, simplified payment verification. A lightweight client uses block headers and a tree branch linking a transaction to a chosen block. This saves data but relies on assumptions about the chain with the greatest cumulative work and miners’ behaviour. An inclusion proof alone does not check every transaction rule as a Full Node, a fully validating node, does. Nor does it establish whether an output was later spent: that requires knowledge of subsequent activity. For a beginner, the important distinction is that “this payment is in this block” is not a complete check of funds available now. [3]

The 1979 dissertation also uses an authentication tree for a finite number of one-time signatures. A digital signature lets someone verify that the holder of a particular secret key approved a message; it is not a picture of a handwritten signature. The tree can connect many verification values to one known root. In the described construction, however, the supply of signatures is finite and the root must eventually be renewed. This does not permit unlimited reuse of the same one-time key. This more advanced part of Merkle’s work illustrates a recurring idea: verify the part you need with a small proof, while being precise about what that verification depends on. [2]