Pre-Bitcoin Digital Cash Papers: Chaum, b-money, Bit Gold, Hashcash, RPOW

Bitcoin did not appear from nothing. Between 1982 and 2004, five designs attacked the problem of digital money without a bank, and each got part of the way. This guide reads them side by side: what each proposed, what it solved, and the specific obstacle that stopped it.

All five are short. Two are blog posts, one is a text file, one is a conference paper, one is a mailing list announcement plus a running server. Together they are perhaps forty pages of reading, and they contain nearly every idea in Bitcoin except the one that made it work.

1. David Chaum: Blind Signatures for Untraceable Payments (1982)

Document: Presented at CRYPTO '82, published in the proceedings by Plenum Press in 1983, pages 199-203. Listed on Chaum's publications page.

Chaum's problem was privacy, not decentralisation. He accepted that a bank would issue the money, and asked whether the bank could be prevented from tracing where it went.

The mechanism is the blind signature, which Chaum explains with an analogy: put a blank slip and a sheet of carbon paper inside a sealed envelope, hand it to the bank, and the bank stamps the outside. The stamp transfers through the carbon onto the slip. The bank has certified a note worth one dollar without ever seeing its serial number. When the note is later deposited, the bank verifies its own signature but cannot link it to the withdrawal.

Chaum founded DigiCash in Amsterdam in 1989 to build it. The first digital cash payment over a computer network went through in 1994, and Mark Twain Bank in St. Louis licensed the system in 1995. DigiCash filed for bankruptcy in 1998.

Solved: payment privacy that is mathematically enforced rather than promised. Left open: everything about the issuer. The bank still prevents double spending by checking every note against a database, so it can inflate, censor, or fail — and DigiCash failed.

2. Adam Back: Hashcash (1997/2002)

Document: Announced on the cypherpunks mailing list in March 1997; the reference paper Hashcash — A Denial of Service Counter-Measure came in 2002.

Hashcash was not designed as money. It was an anti-spam mechanism: to send an email, compute a hash with a required number of leading zero bits, tied to the recipient's address and the date. Finding one takes measurable CPU work; checking one takes a single hash. Legitimate senders pay a cost they do not notice, and bulk senders pay it a million times over.

Back's paper describes both interactive variants, where a server issues a challenge, and non-interactive ones for store-and-forward settings such as email. The economic framing — an unforgeable cost that anyone can verify — is what mattered later. Cynthia Dwork and Moni Naor had proposed the same principle in Pricing via Processing at CRYPTO '92; Back arrived at it independently and, crucially, shipped working code.

Solved: creating scarcity without an issuer. A hashcash token proves that real resources were spent. Left open: hashcash tokens are single-use and non-transferable, and their cost is fixed, so faster hardware silently devalues them. It is a stamp, not a currency.

3. Wei Dai: b-money (1998)

Document: b-money, posted to the cypherpunks mailing list in November 1998. Reference [1] in the Bitcoin whitepaper — the first citation Nakamoto lists.

Dai opens by naming his intellectual debt to Tim May's crypto-anarchy, then proposes a scheme in which untraceable pseudonyms pay each other and enforce contracts without outside help.

The first protocol is startlingly close to Bitcoin. Every participant keeps a copy of a database recording how much money belongs to each pseudonym. Money is created by broadcasting the solution to a previously unsolved computational problem, and the creator is credited with an amount equal to the cost of the computation. Transfers are broadcast and signed; every participant updates their copy.

Dai saw the impracticality immediately and offered a second protocol in which only a subset of servers maintain the accounts, with clients verifying by sampling servers and servers posting security deposits that are forfeited if they misbehave.

Solved: the shape of a cryptocurrency. Distributed ledger, proof-of-work issuance, pseudonymous accounts, broadcast transactions. Left open: how the copies stay in agreement. Dai assumed a synchronous, unjammable broadcast channel, and acknowledged the value-of-computation problem — pricing work against a basket of goods requires an oracle he did not have. There is no consensus rule, no chain, and no answer to conflicting broadcasts.

4. Nick Szabo: Bit Gold (2005)

Document: Bit gold, posted to Szabo's blog Unenumerated in December 2005. The archived page carries a later bumped date of December 2008; the idea itself is older than the post and was discussed on the cypherpunks list in the late 1990s.

Szabo starts from precious metals rather than from cryptography. Gold's value rests on unforgeable costliness — it is expensive to obtain and cheap to verify — and that property, not any government's decree, is what made it money. Bit gold aims to reproduce it in bits.

The procedure chains proof-of-work: a public challenge string is solved with a client puzzle function, the solution is timestamped and published, and it then becomes the challenge string for the next round. Ownership is recorded in a distributed property title registry, and Szabo proposes a Byzantine-fault-tolerant quorum of servers to maintain it. He explicitly names Hal Finney's RPOW as an implemented variant.

He also identifies the flaw that would sink it. Proof-of-work solutions are not fungible, because a puzzle solved in 2005 cost more than the same puzzle solved in 2008 as hardware improves. His proposed fix — dealers bundling different-vintage solutions into standard-value units — was a workaround, not a solution.

Solved: chained proof-of-work, and the framing of digital scarcity as unforgeable cost. Left open: the title registry. Deciding which quorum of servers is the real one is the same Sybil problem in a new place, and bit gold has no mechanism to answer it.

5. Hal Finney: RPOW — Reusable Proofs of Work (2004)

Document: Announced to the Cryptography mailing list on 15 August 2004. The original site is preserved in the Internet Archive.

Finney attacked hashcash's single-use limitation directly. Send a hashcash token to the RPOW server, and it returns an RSA-signed RPOW token. Pass that token to someone else, and they can exchange it for a fresh one. Each token is used once, but each use mints a successor, so value can move from person to person while remaining backed by the original proof-of-work.

The interesting part is the trust model. Finney ran the server on an IBM 4758 secure cryptographic coprocessor, which could produce a signed attestation of the exact software it was running. Anyone could hash the published source code, compare it with the attestation, and confirm the server had no back door and could not mint tokens without equal-value proof-of-work. Finney called this a "transparent server" and intended it as the first of a family.

Solved: transferability, and verifiable honesty of a server without trusting its operator. Left open: the server itself. It was one machine, in one place, dependent on one manufacturer's key. Compromise the hardware or unplug it and the system stops. Finney later wrote that the concept never attracted users; four years later he ran the second Bitcoin node.

The Comparison

Read across the bottom row: three of the five failed on the same thing. Not cryptography, not incentives, not privacy — agreement. How do mutually distrusting strangers, with no way to count identities, settle on one version of who owns what?

What Bitcoin Added

Nakamoto's whitepaper takes hashcash's proof-of-work, b-money's broadcast ledger, and Haber and Stornetta's hash chaining, and adds one rule: the valid history is the chain with the most accumulated work, and nodes signal agreement by building on it.

That rule does the work all five designs were missing. It makes agreement an economic outcome rather than an assumption, it makes Sybil attacks pointless because votes are bought in hashes rather than identities, and it turns the difficulty target into a supply schedule that survives hardware improvement — solving the fungibility problem Szabo could not.

The whitepaper cites b-money as [1] and hashcash as [6]. Bit Gold and RPOW are not cited; Nakamoto referenced both later in correspondence and forum posts. Chaum is not cited at all, which is telling about the whitepaper's priorities: it is not descended from the privacy line of research, but from the timestamping and proof-of-work lines.

Further Reading

• The Bitcoin Whitepaper, Annotated — section-by-section guide
• A Cypherpunk's Manifesto Explained — the community these designs came from
• Primary Sources Archive Index — the full chronological list