Skip to content

Before Bitcoin: Why Digital Cash Was Hard

The Blockchain Story · Lesson 1 of 12 · Beginner
Historical focus: before 2008 · About 4 minutes for the main story
Updated and sources reviewed: October 20, 2026 (UTC)

One question to carry through this lesson: how can digital money be spent once when digital messages can be copied?
Read straight through for the story. The three expandable questions are optional.

A photograph can be sent to two friends without disappearing from your phone. Money cannot work like that: paying a bookseller should leave you with less to spend at the café. Early digital-cash designs had to bridge that gap between a copyable message and a spendable balance.

The same ten units, promised twice

Imagine Mina has ten units of digital money. She sends one instruction to pay all ten to a bookseller, and another to pay the same ten to a café. This is double spending: trying to reuse funds that should be spendable only once.

A digital signature lets others check that an instruction was authorized using the relevant secret key. Mina can genuinely authorize both instructions. A signature does not, by itself, tell either merchant that the other instruction exists.

We also need a ledger: a record of who can spend what. Once a consistent ledger accepts the bookseller payment, Mina's original ten units must no longer be available for the café payment. Agreement on that record matters more than the order in which Mina says she clicked two buttons.

Who gets to keep the book?

A conventional payment service can keep one authoritative database and reject the second payment. People then depend on that operator to keep the service available, apply its rules and handle disputes.

What if there is no single operator? Giving everybody a copy of the book creates another question: what happens when different people receive the two payments in different orders? Consensus means reaching agreement under shared rules and assumptions. It does not mean everyone agrees that a purchase is sensible.

This is why the history is more interesting than a succession of coins. Different projects tackled different parts of the problem: the cost of abuse, the ownership record, and agreement about its history.

Two earlier ideas, two different questions

Hashcash, proposed in 1997, explored making abusive requests expensive by requiring computational work. Wei Dai's b-money proposal, published in 1998, explored money among participants known by digital identities. One helps us think about cost; the other about shared accounts. Neither should be read as simply “Bitcoin under an earlier name.”

Optional · Why did an anti-spam idea matter to digital money?

Hashcash made a stamp comparatively costly to produce and cheap to check. Bitcoin later referenced this kind of proof of work. The interesting step is how work becomes part of a shared history, rather than merely a ticket for sending a message.

Explore Hashcash: the problem, mechanism and limits →

Optional · What did b-money propose, and what remained difficult?

b-money explored replicated account records and, in a second protocol, a smaller set of servers. Its author explicitly identified difficult assumptions. Reading those limits helps explain why distributing an account book is only part of the task.

Explore b-money: shared balances and open questions →

Bitcoin brings the questions together

The 2008 Bitcoin whitepaper proposed a way to connect authorized transfers to a history participants could check without one financial institution keeping the payment ledger. The next lesson follows the move from a written design to running software.

For now, remember the distinction: “Mina authorized this” and “these funds are still available” are different claims. A working payment system has to address both. It also needs rules for choosing between competing versions of its history.

Optional · What did Bitcoin combine, rather than invent from nothing?

Signed transfers, linked blocks and proof of work play different roles. A rule for selecting a valid history connects them. Proof of work does not make an invalid spend acceptable. The companion explains these roles side by side and links to the original documents.

Compare the building blocks and follow the sources →

Agreement on a ledger still cannot promise stable purchasing power, recover a lost key or ensure a seller delivers. Those questions return later in the story as wallets, stablecoins and applications develop.

Can you explain the problem now?

Why can both of Mina's instructions carry genuine signatures while both payments cannot be accepted against the same ten units? If you can distinguish authorization from available funds and an agreed history, you have the foundation for the next chapter.

Sources: Back's Hashcash paper (2002, describing the 1997 proposal); Dai's b-money proposal (1998); Bitcoin whitepaper (2008). Dates refer to historical documents; this is a selected learning path, not an exhaustive genealogy. Mina's example is Blockchain808's teaching material.