What Is a Blockchain? It Is a Chain of Hashes, Not a Chain of Blocks.

In 1991, two researchers at Bellcore published a paper called How to Time-Stamp a Digital Document. Stuart Haber and W. Scott Stornetta described a scheme for linking documents into a chain of hashes so that their order could be proved without a trusted timestamp authority. Seventeen years later, the Bitcoin white paper cited their work three times in its reference list, and the same chain of hashes appeared in the fifth section of a nine-section document whose subject was something else entirely: who gets to write the next page.

Reading the design that way — as a citation chain rather than a product category — explains why so many arguments about blockchains go nowhere. The papers that make up the technology answer two different questions from two different decades. The first is how to prove that a record has not been altered. The second is how to pick a writer for the next record without appointing one. Almost every claim about “the blockchain” is a claim about one of those two, and the two have different costs, different failure modes and different consequences for anyone building on top of them.

1991: what the paper actually solved

The problem was narrow and practical. If two parties disagree about when a document was written, how can one prove the date without asking a central authority to vouch for it? The authors’ answer relied on two properties of a good hash function that had nothing to do with keeping secrets: it is one-way, so the hash reveals nothing useful about the document, and it is collision-resistant, so two different documents cannot produce the same hash.

Their scheme linked each new record to the previous one by including the previous hash in what gets hashed next. The consequence is that the order of records becomes a cryptographic fact rather than a matter of record-keeping. A record cannot be inserted retroactively without changing every record after it, and no participant has to be trusted to report the sequence correctly, because the sequence is inside the data.

The paper is also explicit about what it does not do, and that limit is what the next seventeen years were spent on. A chain of hashes makes alteration detectable. It does not make alteration difficult, and it says nothing about who is entitled to add the next entry. A single party can rewrite its own chain and recompute every hash in it, and the structure would still be internally consistent. The 1991 paper proved an integrity property; it did not buy an ordering guarantee from a network of mutually suspicious participants.

1979 to 1994: the tree that makes proofs small

Underneath the chain sits a second structure, older than the chain itself. Ralph Merkle’s work on hash trees, published in the late 1970s, described how to combine many items into one value by hashing them in pairs, level by level, until a single hash remains. The authors of the timestamping work adopted it in later revisions, which is why a modern block header contains a merkle root rather than a list.

The reason a tree is used instead of a flat hash of everything is the size of the proof. To demonstrate that one transaction was in a block, a verifier does not need the block; it needs the transaction, the handful of sibling hashes on the path to the root, and the root itself, which is already in the header. The proof grows with the logarithm of the number of items instead of with the number of items, which is the difference between a wallet that can confirm a payment on a phone and a wallet that has to download a ledger.

Two design choices in this structure are worth naming because they recur in every specification written since. The first is that the commitment is to a set, not to its order: the tree proves that a transaction is in a block, and the order inside the block is a separate matter that the chain itself settles. The second is that the proof is verifiable by anyone without trusting the party who supplied it, which is the property that makes the whole architecture auditable rather than merely audited.

2008: the half the earlier work left open

The white paper’s contribution was not a data structure. Sections one through three restate the problem of double spending and describe transactions as chains of digital signatures, and by the end of section three a reader has a system in which every payment is authorised and no ordering problem has been solved. Section four is where the new idea appears: make the right to append a block expensive, and pay for the expense with the coins the block creates.

The mechanism it specifies is deliberately simple. A participant that wants to propose a block produces a hash below a target that the network publishes, which requires computation rather than permission. The rule for resolving competing versions is the chain with the most accumulated work, which replaces the earlier proposals that relied on one-address-one-vote or on a rotating set of known participants. And the difficulty of the target is adjusted periodically, so the cost of proposing a block rises and falls with the number of participants rather than with their identities.

Two things were borrowed and one was new. The proof-of-work idea came from Hashcash, a scheme for making email spam expensive, which the paper cites directly. The timestamping and tree structures came from the 1991 and 1994 work. What was new was the coupling: work that is expensive to produce is nearly free to verify, and a reward paid by the protocol itself turns that asymmetry into a reason for strangers to keep producing it.

The header, as the specification writes it

The specification reduces the whole structure to eighty bytes. A block header contains the protocol version, the hash of the previous block, the merkle root of its transactions, a timestamp, an encoded difficulty target and a nonce. Any change to the transaction list changes the root, any change to the root changes the block’s own hash, and the next header records the previous hash. The link is therefore not a pointer copied by software but a value that could not exist if the earlier block were different.

Reading the header field by field explains what the system does and does not guarantee. It guarantees that a given history is internally consistent and verifiable by anyone who downloads it. It does not guarantee that the history is the only one that exists: two valid blocks can be produced at nearly the same moment, and the network resolves the ambiguity by extending one branch and discarding the other after a few blocks. That resolution is not in the data structure; it is in the rule that every node applies to the structure.

A small detail in the design is worth flagging because it recurs in later debates. The nonce field is only 32 bits, which at modern hash rates is exhausted in a fraction of a second, so the search space is extended by varying the coinbase transaction — the transaction that pays the reward — which changes the merkle root and therefore the header. A specification written in 2008 anticipated a problem that only became real when hardware improved by orders of magnitude, and the fix was already in the field layout.

Section eight: verification by machines that cannot store everything

The white paper includes a section for light clients, and it is the part of the document most often misread. A client that cannot store the chain keeps only the headers, requests a merkle path for a transaction it cares about, and checks that the path leads to a root in a header it already has. The proof is real and small, and it establishes inclusion in a particular block.

What it does not establish is that the block is part of the history the rest of the network considers canonical, because that would require validating the chain of work behind it. The paper is honest about this: the security of the light client rests on the assumption that the majority of validating power is honest, whereas a full validator checks the rules and trusts nobody. Both are part of the specification, and they are different products with the same name.

This distinction has aged well as an engineering principle even where the specific balance has shifted. Almost every consumer wallet today does not run a light client in the described sense; it queries a service run by a company. That is a legitimate product decision and a different trust assumption from the one the paper describes, and the gap between the two is one of the few places where the specification and the market have diverged in the direction of more trust rather than less.

What the specifications added after 2008

The original document describes one type of output and a simple scripting language. Everything that followed it is a specification change, and each one was a response to a limitation somebody hit in production.

Two observations about that list matter more than the details. The first is that the changes arrived as a series of backward-compatible or coordinated upgrades rather than as a rewrite, which is a consequence of how the append-only structure handles rule changes: the code is new, the history it must be consistent with is not. The second is that the market has converged on consensus rules that the 2008 paper did not specify. Proof-of-stake replaces the work with a bond at risk, and permissioned deployments replace the open competition with a known validator set, and both are legitimate answers to the question the paper posed rather than departures from the data structure it described.

The questions the papers never answered

A specification can be complete about a data structure and silent about the things users care about most. Four of those gaps are worth naming, because they are still argued about as though a document settled them.

The first is governance: who decides that a rule should change, and what happens when the answer is not unanimous. The papers describe validation rules as fixed, and every real network has had to invent a process for modifying them, which is why forks are a feature of the field rather than an accident in it. The second is what belongs on chain. The structure is expensive by design, and the division of labour between a base layer, a compressed layer and ordinary storage is an engineering decision that the citation chain does not make for anyone.

The third is privacy. A transparent ledger was a feature of the original design, because auditability was the point, and the same property makes the record permanently traceable by anyone running an analytics cluster. The fourth is the meaning of a balance. The specification describes outputs and account state; it says nothing about who owns what at law, which is why a token balance can be a claim on a company in one arrangement and a key-held asset in another with identical interface and different consequences.

One structure, three deployments

The same hash-linked log appears in three very different products, and reading them as one category is what makes most comparisons useless. A public chain pays for open appending with electricity and latency, and buys ordering that no institution controls. A permissioned deployment replaces the competition with a known validator set, which makes it fast, cheap and governable, and gives up the property that no single party can rewrite history. A rollup inherits the base layer’s ordering guarantees and moves execution to a cheaper venue, with the base layer still settling the result.

All three are described by the same papers and are not substitutes for each other. The distinguishing questions are short: who may append, what does misbehaviour cost them, who must verify, and who can read the data. A public chain answers them with computation, a bond or a vote, every full node, and everyone. A permissioned network answers them with a contract, a committee, the named members, and the members. Neither answer is wrong; they are answers to different problems, and the words on the marketing page are identical in both cases.

The reference list, read as a genealogy

A specification’s bibliography is a compressed history of the problem it is solving, and the Bitcoin paper’s list is unusually instructive because each entry answers part of the question and leaves the rest open. Reading four of them in order explains why the design that eventually shipped looks the way it does.

The pattern across that table is a familiar one in systems design: each piece solved a local problem and introduced a dependency on a party whose honesty the rest of the system had to assume. Digital cash assumed a bank. The timestamp chain assumed a publisher. Proof of work alone, as used against email spam, assumed nothing about a shared ledger because there was no ledger. The step the 2008 paper took was to make the writer’s identity irrelevant by making the writer’s cost measurable, which is why it is often described as a consensus mechanism rather than as a payment system.

What changed when the specification became code

Papers describe rules; deployments have to decide what happens when those rules encounter people who disagree. Three things appeared in the implementation layer that no specification could settle in advance, and all three are still visible in how the networks are run today.

The first is that validation and production are separate roles with separate incentives. The nodes determine what a valid block is, and the producers compete to supply one. That asymmetry turns out to be the load-bearing part of the governance arrangement, because it means the participants who spend the most money cannot change what counts as valid by spending more of it. A change to the rules requires the software that validating nodes run to change, which is a political process rather than a hash rate competition.

The second is that upgrades need a process, and the process that emerged is a numbering convention with a review culture attached. Proposals are written down, given identifiers, reviewed publicly and implemented by client teams, and the network activates them by a mechanism the proposal itself defines. The convention is a contribution of the implementation layer rather than of the paper, and it is the reason a rule change can be discussed for years before it is deployed without any single party being able to force it.

The third is that a disagreement about rules can be resolved by duplication. A hard fork that fails to achieve consensus does not corrupt the chain; it produces two chains, each with its own history from the point of divergence and its own community. That is a strange property to describe as a feature, and it is the honest answer to the question of what happens when a network cannot agree: the network splits, the market assigns a price to each side, and the participants discover which of them was in the majority by watching which chain keeps its liquidity.

The citation chain

Read in order, the documents describe an unusually clean division of labour. A 1979 tree made small proofs possible. A 1991 chain made alteration detectable. A 2008 rule made appending costly and paid for it. A series of specifications from 2012 onward made the result usable by ordinary software without changing the rule beneath it. Each layer answers a question the previous one did not ask, and each layer’s guarantee stops exactly where the next one begins.

That is also the most practical thing to take from the literature. When somebody claims something about a blockchain, the useful response is to ask which paper the claim comes from. If it is about integrity, the answer is 1991 and the machinery is hashing. If it is about ordering, the answer is 2008 and the machinery is an economic incentive. If it is about who owns the coins or who can freeze them, no paper answers it at all — the design is silent by construction, and the silence is a feature that the market has spent a decade trying to sell as a guarantee.