A useful history of Bitcoin asks more than who came first. It asks what each design made possible, what it assumed, and what another design still had to supply. Hashcash and b-money are two documented reference points, not a complete family tree of digital money.
A timeline of documents, not a chain of product launches
| Date | Record | What the date establishes |
|---|---|---|
| 1997 | Hashcash proposal | The earlier proposal date reported in Back's later paper. |
| November 1998 | b-money | A published protocol proposal, not a Bitcoin launch. |
| August 1, 2002 | Hashcash paper | A technical account of the mechanism and subsequent work. |
| 2008 | Bitcoin whitepaper | A system design; running software belongs to the next chapter. |
The primary documents are linked in the sections below. Chronological proximity alone does not prove direct influence. A citation establishes a documented reference; a claim that one project directly became another needs additional evidence.
Hashcash: make repeated requests cost something
Adam Back's 2002 Hashcash paper describes computational stamps for limiting abuse of services such as email. Generating a qualifying stamp requires repeated computation; checking it is comparatively cheap. Stamps are bound to a service, and a spent-token record helps reject reuse. These are properties of an anti-abuse mechanism, not by themselves a transferable currency.
Try a fictional help-desk example. Imagine a desk that receives ten ordinary requests and ten thousand automated requests. Requiring an expensive-to-create, easy-to-check ticket changes the sender's cost. It does not tell the desk whether a request is honest. Nor does the ticket tell two independent shops which of Mina's conflicting payments to accept.
This gives us a useful design test: separate the cost of making a claim from the rules that make the claim acceptable. A costly message can still be invalid. A cheap message can still be useful. “Work was done” is an answer to one question, not a substitute for every other check.
b-money: distribute the account book
Wei Dai's November 1998 b-money proposal describes pseudonymous money and contracts. Its first protocol gives participants their own balance databases and uses signed broadcast transfers. Dai explicitly calls its communication assumption impractical. The second uses a subset of servers, with deposits and published account records as accountability measures. The appendix also identifies difficulties in agreeing on computation costs for money creation.
Return to Mina's ten units. Suppose two bookkeepers receive her bookseller instruction and café instruction in opposite orders. Each can apply a “never allow a negative balance” rule to its local book. Yet the books can disagree about which merchant was paid. This is our teaching example, not a simulation of Dai's entire protocol. It isolates the question a reader should ask of any shared ledger: what makes independent records converge?
Reading an unfinished design is valuable precisely because its assumptions remain visible. Instead of dismissing a proposal as a failed coin, mark what it specifies and what it leaves dependent on communication, accountability or agreement. That habit will help when later projects advertise a new consensus mechanism.
Bitcoin: connect valid transfers to a shared history
The Bitcoin whitepaper cites both b-money and Hashcash. It explicitly relates its proof of work to Hashcash, then combines signed transfers, linked blocks and a chain-selection rule. Nodes still check validity; accumulated work is not permission to break spending rules. The paper's security reasoning depends on assumptions about honest computational power.
Our reading of those documents is a synthesis of components, not a claim that Hashcash was renamed b-money or that b-money became Bitcoin software. Keep the relationship labels precise: Hashcash is an explicitly referenced technical mechanism; b-money is a cited earlier money proposal. That evidence does not make every feature identical.
| Check | Mina's example | What it does not establish |
|---|---|---|
| Authorization | Was the required key used to approve the instruction? | That the same funds were not promised elsewhere. |
| Validity | Are those funds spendable against this history? | That everyone currently sees the same history. |
| History selection | Which valid history do the agreed rules select? | That the merchant delivers, or the purchase was wise. |
Use the comparison yourself. When you encounter a new project, write one sentence for each row. If its explanation answers all three with “cryptography” or “decentralization,” ask for the missing mechanism. Then ask how the design behaves when messages arrive late or participants disagree. A good historical comparison produces better questions about the present.