The pieces before Bitcoin.

Can a digital payment preserve privacy?

David Chaum’s early work on blind signatures showed how an issuer could sign a payment token without being able to link every later use back to its withdrawal. Think of the purpose as getting a valid payment credential without attaching a complete shopping history to it.

His company DigiCash explored commercial digital cash with banks in the 1990s. The payment system could protect privacy while still relying on an issuer to create or redeem money and prevent reuse of spent tokens.

That is a different goal from eliminating the issuer. A centralized arrangement can have strong privacy techniques. A public blockchain can reveal a great deal about transactions.

DigiCash’s commercial difficulties do not mean its cryptographic ideas failed. Business survival, privacy, and control over issuance are separate questions.

What if the token represents gold?

E-gold took a different path. Its digital balances represented gold, and transfers were managed by companies responsible for the service and the backing.

That made it another example of the distinction from Module 1: a convenient digital claim still relies on somebody honoring the claim.

In 2008, the companies and their operators pleaded guilty to charges involving money laundering and unlawful money transmission. The enforcement action was about their operation and legal obligations. It was not proof that the gold was imaginary or that every centralized payment business must end the same way.

The design lesson is narrower and useful: where an organization controls access, reserves, and transfer records, its legal and operational risks matter to users.

Can sending a message require effort?

Adam Back’s Hashcash, proposed in 1997, asked a sender’s computer to do some computational work. Producing a valid result required repeated attempts, while a recipient could check the result cheaply.

For legitimate low-volume use, the cost could be modest. Repeating it across a large volume of abusive messages made the cost larger. This was part of a wider history of research into pricing abuse through computation.

Hashcash was not a ledger that resolved ownership of a transferable currency. It supplied a building block: proof of work, evidence that a result meets a condition designed to require effort to find.

Bitcoin adapted that shape of work to publishing blocks. The connection is explicit in its white paper’s references.

Can scarce digital records have shared owners?

Wei Dai’s 1998 b-money proposal described people maintaining balances and creating money through computational work. It discussed more than one design and made assumptions about communication, participants, and enforcement. It was a proposal to study, not a running Bitcoin network under another name.

Nick Szabo’s bit gold proposal linked proof-of-work results with timestamping and an ownership registry. It explored how costly-to-produce digital records might become transferable property. The published design is often associated with ideas developed in the late 1990s; Szabo’s surviving essay was published in 2005.

Other researchers developed digital signatures, cryptographic hashes, linked timestamps, and ways to combine many records into compact checks. Bitcoin did not replace mathematics with economics. It combined cryptography, networking rules, and economic incentives.

The next lesson shows the combination that matters for conflicting histories: checking the rules first, then using accumulated work to decide which valid branch to extend.

The idea to keep

Ask what each earlier design contributed, what it relied on, and whether it was a proposal, a tool, or an operating service.

That habit is useful far beyond history. A project can solve one problem well while leaving another problem for someone else.