1997 / 2002 / REFERENCE
Hashcash: proof of work before Bitcoin
A computational postage stamp for internet abuse became one ingredient in a different system: public transaction ordering.
Texto de referencia en inglés · Navegación en 7 idiomas
En esta página
The problem was cheap abuse
Adam Back’s 2002 paper dates the original Hashcash proposal to May 1997. Its target was the low cost of abusing services such as email and anonymous remailers. A sender performs a computational task and presents a token that a recipient can check cheaply. The asymmetry matters: making every attempted message slightly expensive can change the economics of bulk abuse without making verification equally expensive. [1]
Work is a cost, not a truth detector
A proof of work establishes that a computational condition has been satisfied. It does not establish that a message is honest, that its sender has a good reputation or that the requested action is safe. An attacker with sufficient resources can still perform the work. The useful question is therefore which behaviour the added cost discourages, and at whose expense. A project describing something as “secured by proof of work” still needs to explain what is being verified.
Before Bitcoin: privacy, digital cash and the missing agreement →
What Bitcoin added
Bitcoin’s white paper explicitly draws on Hashcash for its proof-of-work construction, then connects work to a chain of transaction records and a rule for selecting the history with the most accumulated work. That addresses a different problem from pricing an email: agreeing on transaction order without asking a central payment operator to choose it. Hashcash itself should not be described as an earlier Bitcoin blockchain. [2]
Read the dates correctly
The proposal and the later paper have different dates: 1997 and 2002. A historical timeline should preserve that distinction instead of treating publication of the paper as the first appearance of the idea. The broader lesson for research is to separate a primitive, its implementation and the system built around it. A reusable technical ingredient is not evidence that 2 systems have identical security assumptions.
