Hashcash

Anna wants to email Pavel. Sending another copy usually costs her almost nothing, but a sender of millions of advertisements enjoys the same advantage. Hashcash adds a small hurdle: the sender’s computer first produces a computational stamp. The cost is time and energy, rather than a payment to a postal service. Adam Back announced his implementation on 28 March 1997 and published a technical paper in 2002. Cynthia Dwork and Moni Naor had explored a similar computational-postage idea in 1992. Hashcash belongs to this history of attempts to limit network abuse. [1] [12]

A hash is a fixed-length fingerprint calculated from data. Anna’s program changes a trial value in the stamp and recalculates its fingerprint until the result starts with enough zero bits. A bit is a binary digit: zero or one. Requiring b zeros gives each attempt an approximate success probability of 2^-b, with an average of 2^b attempts. For b = 20, that means 1048576 calculations on average, not a mandatory exact count. Sometimes the program gets lucky early; sometimes it takes longer. Pavel checks the finished stamp with one hash calculation, but must also check its contents and the rules for accepting it. [10] [11]

If Anna could attach one stamp to a million messages, the hurdle would lose its purpose. A stamp therefore identifies a recipient or service and includes a date. The recipient checks validity and records accepted stamps to reject repeat use, known as replay. A date alone, or even binding a stamp to the message’s contents, cannot prevent that same message being sent again. Hashcash has no shared global spending registry: the receiving service provides the necessary check. A correct hash does not, by itself, make a stamp acceptable again. [11] [12]

The receiving service chooses the required difficulty. Each additional zero bit roughly doubles the average work. A weak requirement barely slows a spammer; a strong one burdens ordinary users too. The number 20 is therefore an example, not a permanent security standard. The same number of attempts also takes different amounts of time on an old phone and a fast computer. A service must consider device performance, expiry and its own capacity. Hashcash does not enforce a universal number of seconds on everyone. [10] [11]

Computational work cannot distinguish a considerate person from an attacker. A spammer with many computers or a botnet, a network of compromised devices, can distribute the work and shift part of the cost to other people. Meanwhile, an ordinary user loses battery power. Hashcash seeks to change the economics of an attack, not guarantee the disappearance of spam. A stamp does not encrypt the message, establish a person’s legal identity or guarantee delivery. It is one acceptance condition that a service can combine with other defenses. [10]

Version 1 uses the format 1:bits:date:resource:ext:rand:counter. The fields specify the version, claimed difficulty, date, recipient or service, extensions, a random value and a changing counter. The bits field states how many leading zero bits the sender claims the fingerprint has, not how many attempts the computer actually made. These field names belong to the technical format and are not translated. The classic implementation applies SHA-1 to the entire string. The actual fingerprint must qualify; merely writing a number in bits is not enough. This describes a historical format, rather than recommending SHA-1 for new security designs. Bitcoin uses a different data format and hash function. [11] [13]

Here the task is to find an input whose fingerprint has a specified beginning. Such an input is called a partial preimage: its fingerprint matches the specified part of the pattern, while the remaining part can be anything. A collision, by contrast, is two different inputs with the same fingerprint. Some historical texts use the looser phrase partial collision, but the distinction matters when explaining the work. An attack that finds SHA-1 collisions does not automatically solve the required-prefix problem. That does not make SHA-1 a suitable general-purpose security choice today. [10] [11] [13]

In 2004, Hal Finney introduced RPOW, Reusable Proofs of Work. A user could submit a proof of work and receive a new token; a later transfer invalidated the old token and replaced it with another. Reuse therefore did not mean freely copying the same stamp. The system relied on a server with an IBM 4758 secure module and remote verification of the running program. This reduced trust in the operator but retained assumptions about the hardware and its manufacturer. RPOW was an experimental predecessor, not Bitcoin’s decentralized consensus. [7] [15]

Bitcoin Whitepaper explicitly cites Back’s Hashcash. Satoshi used the same basic asymmetry: finding a suitable result requires repeated attempts, while others can check it easily. Bitcoin miners search for a valid block header, which summarizes a block of transactions and references the previous block. They use double SHA-256, two successive applications of SHA-256, and compare the result against a numerical limit called the target. This is not a SHA-1 email stamp placed in a wallet. The shared element is the principle, not the entire system. [8] [14]

Postage prices an individual request. Money also needs an answer to a different question: which of two conflicting transfers is valid? Bitcoin links blocks together, and its nodes select the chain with the greatest cumulative work among valid branches. Nodes, the computers checking the rules, also verify transactions and the permitted issuance of coins. Even enormous work cannot make an invalid transaction valid. Hashcash supplied an important building block; combining it with other rules made a shared monetary history without a central operator possible. [8] [9]