Bitcoin and the Genesis Files

How David Chaum's ECash Spawned a Cypherpunk Dream

"You can pay for access to a database, buy software or a newsletter by email, play a computer game over the net, receive $5 owed you by a friend, or just order a pizza. The possibilities are truly unlimited."

This quote is not from a 2011 Bitcoin introduction video. In fact, the quote is not about Bitcoin at all. It is not even from this millennium. The quote is from cryptographer Dr. David Chaum, speaking at the first-ever CERN conference in Geneva in 1994. What he's talking about is eCash.

If the cypherpunk movement has a forefather, the bearded, ponytailed Chaum is it. To say that the cryptographer – now 62 or 63 years old (he won't reveal his exact age) – was ahead of the curve is an understatement. Before most people had heard of the internet, before most homes had personal computers, before Edward Snowden, Jacob Appelbaum, or Pavel Durov were even born, Chaum concerned himself with the future of online privacy.

"You have to let your readers know how important this is", Chaum once told a Wired journalist. "Cyberspace doesn't have all the physical constraints. […] There are no walls … it's a different, scary, weird place, and with identification, it's a panopticon nightmare. Right? Everything you do could be known to anyone else, could be recorded forever. It's antithetical to the basic principle underlying the mechanisms of democracy".

Chaum, who started his career as a computer science professor at Berkeley University, was not just a digital privacy advocate. He designed the tools to realize it. First published in 1981, Chaum's paper "Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms" laid the groundwork for research into encrypted communication over the internet, which would eventually lead to privacy-preserving technologies like Tor.

But privacy of regular communication was not at the top of Chaum's priority list. He arguably had an even bigger idea. The Berkeley professor wanted to design a privacy-preserving digital money.

"The choice between keeping information in the hands of individuals or of organizations is being made each time any government or business decides to automate another set of transactions", Chaum would explain in the Scientific American in 1992. "The shape of society in the next century may depend on which approach predominates".

Ten years prior, by 1982, Chaum had already solved the puzzle, which he had published in his second major paper: "Blind signatures for untraceable payments". At a point in time when today's Bitcoin veterans like Dr. Pieter Wuille, Erik Voorhees or Peter Todd had yet to take their first breath, the cryptographer had designed a solution to realize an anonymous payment system for the internet.

 

Blind Signatures

At the heart of Chaum's digital money system lies his innovation of "blind signatures".

To understand blind signatures, it's important to first remember how public key cryptography works and, in particular, what (regular) cryptographic signatures are.

Public key cryptography uses key pairs. Such a pair consists of a public key, which is a seemingly random string of numbers that is mathematically derived from the other, truly random string of numbers: the private key. With the private key, it's trivial to generate the public key. But with only the public key, it's practically impossible to generate the private key: it's a one-way street.

Public key cryptography can be used to establish private communication between two people – in academic circles usually referred to as "Alice" and "Bob" – who only share their public keys with one another. Their private keys remain private.

But private communication is not all Alice and Bob can do. Alice can also cryptographically "sign" any piece of data (and so can Bob). To do so, Alice must mathematically combine her private key with this data. The result will be another seemingly random string of numbers known as the "signature". Once again, it's impossible to recreate Alice's private key from the signature (with or without the piece of data). It's all still a one-way street.

The interesting thing about this signature is that Bob (or anyone else) can check it against Alice's public key. This tells Bob that it was indeed Alice that created the signature with her private key (and the added piece of data). This can, in turn, mean whatever Alice and Bob want. For example, it can mean that Alice agrees with the content of the data (just like a handwritten signature).

A blind signature then takes all this one step further. This time, Bob first generates a random number, called a "nonce", and mathematically combines this with the piece of data. This "scrambles" the piece of data to make it seem like yet another random string of numbers. Bob can then give the scrambled data to Alice for her to sign. Alice cannot tell what the original data looks like, so she is "blind signing" it. The result is a "blind signature".

Now, the interesting thing about this blind signature is that it's not just linked to Alice's keys (like any signature would be) and the scrambled data. The same blind signature is also linked to the original, unscrambled data. Using only Alice's public key, anyone can check that Alice signed a scrambled version of the original data – including, of course, Alice herself, if she does get to see the original data later on.

 

eCash

This blind signature scheme is the trick that Chaum used to create a digital money system.

To realize this, Alice from the above example would actually be a bank: Alice Bank. This is a regular bank, like banks exist today, where customers have bank accounts with (in this example) U.S. dollar deposits.

Let's say Alice Bank has four customers: Bob, Carol, Dan, and Erin. And let's say that Bob wants to buy something from Carol.

First, Bob requests a "withdrawal" from Alice Bank. (Ideally, he had already made this withdrawal earlier – but never mind that for now.) To make this withdrawal, Bob actually creates "digital banknotes" himself, in the form of unique numbers: "serial numbers". On top of that, he scrambles these banknotes, as shown above. These scrambled banknotes are sent to Alice Bank.

Having received the scrambled banknotes from Bob, Alice Bank then blind signs each scrambled banknote and sends them back to Bob. For each signed, scrambled banknote that she sends back, Alice Bank subtracts one dollar from Bob's bank account.

Now, because Alice Bank blind signed the scrambled banknotes, her signature is also linked to the original, unscrambled banknotes. So, Bob can now use the original, unscrambled banknotes to pay Carol by simply sending them to her.

As Carol receives the banknotes, she should forward them to Alice Bank. Alice Bank then checks that she indeed blind signed each of the banknotes, which her blind signatures allow her to do: they are linked to her own keys. Alice Bank also checks that the same banknotes (serial numbers) haven't already been deposited by someone else in order to ensure that they haven't been double-spent.

As the banknotes check out, Alice Bank adds the equivalent number of dollars to Carol's bank balance, and lets Carol know. Upon this confirmation, Carol knows she's been paid valid banknotes by Bob and can safely send him whatever he was buying from her.

The basic idea behind eCash. Source: faculty.bus.olemiss.edu/

Of key importance, Alice Bank will see the unscrambled banknotes for the first time only when Carol deposits them! As such, Alice Bank has no way of knowing that the banknotes were Bob's. They could just as well have come from Dan or Erin.

As such, Chaum's solution offers privacy in payments. This was not new in itself, of course: private payments were the norm in those days. But it was new in digital form. Hence, Chaum's analogy: cash. Electronic cash. eCash.

 

DigiCash

By 1990, a little under 10 years after finishing his first papers (younger cryptocurrency developers like Matt Corallo, Vitalik Buterin and Olaoluwa Osuntokun still hadn't been born), David Chaum founded DigiCash. The company was based in Amsterdam, where Chaum had been living for a couple of years, and specialized in – indeed – digital money and payment systems. These included a government project to replace toll booths (which was eventually canceled) and smart cards (akin to what we call hardware wallets today). But DigiCash's flagship project was its digital cash system, eCash. (The system was called eCash, while the money in the system was dubbed "CyberBucks", comparable to using capital-letter Bitcoin for the protocol and lower case bitcoin for the currency.)

The technical team in the early days of DigiCash. (Chaum not pictured.) Source: chaum.com/ecash

At a time that Netscape and Yahoo! were leading the tech industry to new heights, and where some thought micropayments, not advertisements, would be the revenue model for the web, DigiCash was considered a rising star by tech entrepreneurs of the day. Of course, Chaum and his team had much faith in their technology as well.

"As payments on the network mature, you're going to be paying for all kinds of small things, more payments than one makes today", Chaum told the New York Times in 1994, of course, emphasizing the importance of privacy in such a world. "Every article you read, every question you have, you're going to have to pay for it".

That year, after four years of development, the first successful payments were tested, and later that same year eCash trials began: Banks could acquire a license from DigiCash to use the technology.

Interest was significant. By late 1995, eCash was licensed to its first bank: the Mark Twain Bank in St. Louis. Moreover, by early 1996, one of the biggest banks in the entire world got on board: Deutsche Bank. Credit Suisse, a second major player joined later, and several other banks across different countries – including the Australian Advance Bank, Norway's Norske Bank, and Bank Austria  – would follow suit.

Yet, what's perhaps more interesting than the deals DigiCash struck are the deals it did not. Two of the three major Dutch banks – ING and ABN Amro – are said to have made DigiCash partnership deals worth tens of millions of dollars. Similarly, Visa reportedly offered a $40 million investment, while Netscape had interest as well: eCash could have been included in the most popular web browser of that era.

Still, the biggest offer of all probably came from none other than Microsoft. Bill Gates wanted to integrate eCash into Windows 95 and is said to have offered DigiCash some $100 million to do so. Chaum, so the story goes, asked for two dollars for each version of Windows 95 sold. The deal was off.

While a rising star in the minds of technologists of the day, DigiCash seemed to have trouble making a financial deal that would help it to realize its full potential.

By 1996, DigiCash employees had seen one failed deal too many and wanted a change in policy. This change came in the form of a new CEO: Visa veteran Michael Nash. The startup also got a fund injection, while MIT Media Lab founder Nicholas Negroponte was made chairman of the board. (Through its Digital Currency Initiative, the MIT Media Lab employs several Bitcoin Core contributors today.) The DigiCash headquarters were moved from Amsterdam to Silicon Valley. Chaum remained part of DigiCash, but now as CTO.

It wouldn't make much difference. After several years of trials, eCash wasn't catching on with the general public. The banks that got on board were experimenting but did not really push the technology; by 1998, Mark Twain Bank had only enrolled 300 merchants and 5,000 users. While a final deal with Citibank came close – it could have given the project a good push – this bank ended up walking out for unrelated reasons.

"It was hard to get enough merchants to accept it, so that you could get enough consumers to use it, or vice versa", Chaum told Forbes in 1999, after DigiCash had finally filed for bankruptcy. "As the Web grew, the average level of sophistication of users dropped. It was hard to explain the importance of privacy to them".

 

The Spawning of a Cypherpunk Dream

DigiCash failed, and eCash failed with it. But even though the technology did not succeed as a business, Chaum's work would inspire a group of cryptographers, hackers and activists, connected through a mailing list. It was this group – which included DigiCash contributors like Nick Szabo and Zooko Wilcox-O'Hearn – that would come to be known as the cypherpunks.

Perhaps a bit more radical than Chaum himself ever was, the cypherpunks kept the dream of an electronic cash alive, proposing alternative digital currency systems throughout the 1990s and early 2000s. In 2008, about 10 years after DigiCash's demise, Satoshi Nakamoto sent his proposal for an electronic cash to the de-facto successor of the then-defunct cypherpunk mailing list: Bitcoin.

Bitcoin and eCash have little in common from a design perspective. Crucially, eCash was centralized around DigiCash and could not really be its own currency. Even if every single person in the world would only use eCash for all their transactions, banks would still be necessary to offer account balances and confirm transactions. This also means that eCash – while providing privacy – was not as censorship-resistant. Where Bitcoin was able to keep WikiLeaks funded even through a banking blockade, for example, eCash could not have done the same thing; banks could still have blocked WikiLeaks' accounts.

Still, Chaum's work on digital currency, dating back to the early 1980s, remains relevant. While Bitcoin itself does not employ blind signatures, scaling and privacy layers on top of the Bitcoin protocol could. Bitcointalk forum and  r/bitcoin subreddit moderator Theymos, for example, has been a champion of an eCash-like scaling sidechain for Bitcoin for some time. Adam Fiscor, a leader in the domain of Bitcoin transaction privacy today, is realizing coin-mixing services utilizing blind signatures, as once proposed by Bitcoin Core contributor Greg Maxwell. And yet-to-be-announced Lightning Network technology could utilize blind signatures to improve security.

And Chaum himself? He returned to Berkeley, where he is responsible for a long list of publications, many in the field of digital elections and reputation systems. Perhaps, some 20 years from now, an entirely new generation of developers, entrepreneurs, and activists will look back at these as the groundwork for a technology that is about to change the world.

This article is partly based on two articles published in the 1990s: "E-Money (That's What I Want)" by Steven Levy for Wired, and "Hoe DigiCash alles verknalde" (Translated: "How DigiCash Blew Everything") by an unknown author for Next! Magazine. There is also a wealth of information on chaum.com/ecash.

---

This text was provided to Saylor Academy with the permission of Aaron van Wirdum. You can find the original work at https://bitcoinmagazine.com/articles/genesis-files-how-david-chaums-ecash-spawned-cypherpunk-dream.

Hashcash or How Adam Back Designed Bitcoin's Motor Block

The date is March 28, 1997, when the 2,000-or-so subscribers of the Cypherpunks mailing list receive an email with the above header in their inbox. The sender is a 26-year-old British postdoc at the University of Exeter, a young cryptographer and prolific contributor to the mailing list named Dr. Adam Back. The email includes a description and early implementation of what he describes as a "partial hash collision based postage scheme" – a sort of stamp equivalent for emails, based on a nifty cryptographic trick.

"The idea of using partial hashes is that they can be made arbitrarily expensive to compute", wrote Back, explaining the advantage of his system, "and yet can be verified instantly".

This proposal by the cryptographer who would go on to become the current Blockstream CEO did not immediately garner much attention on the email list; just one reader responded, with a technical inquiry about the hashing algorithm of choice. Yet, the technology underlying Hashcash –  proof of work – would shape research into digital money for more than a decade to come.

 

"Pricing via Processing or Combatting Junk Mail"

Back's Hashcash was actually not the first solution of its kind.

By the early 1990s, the promise of the internet, and the advantages of an electronic mailing system, in particular, had become obvious to techies paying attention. Still, internet pioneers of the day came to realize that email, as this electronic mailing system was called, presented its own challenges.

"In particular, the easy and low cost of sending electronic mail, and in particular the simplicity of sending the same message to many parties, all but invite abuse", IBM researchers Dr. Cynthia Dwork and Dr. Moni Naor explained in their 1992 white paper bearing the name "Pricing via Processing or Combatting Junk Mail".

Indeed, as email rose in popularity, so did spam.

A solution was needed, early internet users agreed – and a solution is what Dwork and Naor's paper offered.

The duo proposed a system where senders would have to attach some data to any email they send. This data would be the solution to a math problem, unique to the email in question. Specifically, Dwork and Naor proposed three candidate puzzles that could be used for the purpose, all based on public-key cryptography and signature schemes.

Adding a solution to an email wouldn't be too difficult, ideally requiring only a couple of seconds of processing power from a regular computer, while its validity could easily be checked by the recipient. But, and this is the trick, even a trivial amount of processing power per email adds up for advertisers, scammers, and hackers trying to send thousands or even millions of messages at once. Spamming, so was the theory, could be made expensive and, therefore, unprofitable.

"The main idea is to require a user to compute a moderately hard, but not intractable, function in order to gain access to the resource, thus preventing frivolous use", Dwork and Naor explained.

While Dwork and Naor did not propose the term, the type of solution they introduced would become known as a "proof of work" system. Users would have to literally show that their computer performed work, to prove that they spent real-world resources.

A nifty solution, but perhaps too far ahead of its time. The proposal never made it very far beyond a relatively small circle of computer scientists.

 

Adam Back and the Cypherpunks

Around the same time that Dwork and Naor published their white paper, a group of privacy activists with a libertarian bent came to recognize the enormous potential of the internet as well. The ideologically driven crowd started to organize through a mailing list centered around privacy-enhancing technologies. Like Dwork and Naor, these "Cypherpunks" – as they would come to be called – utilized the relatively new science of cryptography to work toward their goals.

Over the years, Adam Back – who earned his Ph.D. in 1996 – established himself as one of the more active participants on this list, at times contributing dozens of emails in a single month. Like most Cypherpunks, the cryptographer was passionate about topics including privacy, free speech, and libertarianism, and engaged in technical discussions pertaining to anonymous remailers, encrypted file systems, electronic cash as introduced by Dr. David Chaum, and more.

But for a while, Back was perhaps best known for printing and selling "munition" shirts: T-shirts with an encryption protocol printed on them, intended to help point out the absurd decision by the U.S. government to regulate Phil Zimmermann's PGP (Pretty Good Privacy) encryption program as "munitions" within the definition of the U.S. export regulations. Wearing Back's shirt while crossing the border to exit the United States technically made you a "munitions exporter".

Like many, Back was not aware of Dwork and Naor's proof-of-work proposal. But by the mid-1990s, he was thinking of similar ideas to counter spam, sometimes "out loud" on the Cypherpunks mailing list.

"A side benefit of using PGP, is that PGP encryption should add some overhead to the spammer – he can probably encrypt less messages per second than he can spam down a T3 link", Back commented, for example, in the context of adding more privacy to remailers; an idea somewhat similar to Dwork and Naor's.

The Cypherpunks mailing list grew significantly in about half a decade. What started out as an online discussion platform for a group of people that initially gathered at one of their startups in the Bay Area became a small internet phenomenon with thousands of subscribers – and often more emails on a single day than anyone could reasonably keep track of.

It was around this time – 1997, close to the list's peak popularity – that Back submitted his Hashcash proposal.

 

Hashcash

Hashcah is similar to Dwork and Naor's anti-spam proposal and has the same purpose, though Back proposed some additional use cases like countering anonymous remailer abuse. But as the name suggests, Hashcash was not based on cryptographic puzzles like Dwork and Naor's; it was based on hashing.

Hashing is a cryptographic trick that takes any data – whether it's a single letter or an entire book – and turns it into a seemingly random number of predetermined length.

For example, a SHA-256 hash of the sentence This is a sentence produces this hexadecimal number:

Which can be "translated" to the regular decimal number:

Or to binary:

Meanwhile, a SHA-256 hash of the sentence This, is a sentence produces this hexadecimal number:

As you can see, merely inserting one comma into the sentence completely changes the hash. And, importantly, what the hash of either sentence would be was completely unpredictable; even after the first sentence was hashed, there was no way to calculate the second hash from it. The only way to find out was to actually hash both sentences.

Hashcash applies this mathematical trick in a clever way.

With Hashcash, the metadata of an email (the "from" address, the "to" address, the time, etc.) is formalized as a protocol. Additionally, the sender of an email must add a random number to this metadata: a "nonce". All this metadata, including the nonce, is then hashed, so the resulting hash looks a bit like one of the random numbers above.

Here's the trick: not every hash is considered "valid". Instead, the binary version of the hash must start with a predetermined number of zeroes. For example: 20 zeroes. The sender can generate a hash that starts with 20 zeroes by including a nonce that randomly adds up correctly … but the sender can't know in advance what that nonce will look like.

To generate a valid hash, therefore, the sender has only one option: trial and error ("brute force"). He must keep trying different nonces until he finds a valid combination; otherwise, his email will be rejected by the intended recipient's email client. Like Dwork and Naor's solution, this requires computational resources: it's a proof-of-work system.

"[I]f it hasn't got a 20 bit hash […] you have a program which bounces it with a notice explaining the required postage, and where to obtain software from", Back explained on the Cypherpunks mailing list. "This would put spammers out of business overnight, as 1,000,000 x 20 = 100 MIP years which is going to be more compute than they've got".

Notably, Back's proof-of-work system is more random than Dwork and Naor's. The duo's solution required solving a puzzle, meaning that a faster computer would solve it faster than a slow computer every time. But statistically, Hashcash would still allow for the slower computer to find a correct solution faster some of the time.

(By analogy, if one person runs faster than another person, the former will win a sprint between them every time. But if one person buys more lottery tickets than another person, the latter will statistically still win some of the time – just not as often.)

 

Digital Scarcity

Like Dwork and Naor's proposal, Hashcash – which Back would elaborate on in a white paper in 2002 – never took off in a very big way. It was implemented in Apache's open-source SpamAssassin platform, and Microsoft gave the proof-of-work idea a spin in the incompatible "email postmark" format. And Back, as well as other academics, came up with various alternative applications for the solution over the years, but most of these never gained much traction. For most potential applications, the lack of any network effect was probably too big to overcome.

Nevertheless, Dwork and Naor as well as Back (independently) did introduce something new. Where one of the most powerful features of digital products is the ease with which they can be copied, proof of work was essentially the first concept akin to virtual scarcity that didn't rely on a central party: it tied digital data to the real-world, limited resource of computing power.

And scarcity, of course, is a prerequisite for money. Indeed, Back in particular explicitly placed Hashcash in the category of money throughout his Cypherpunks mailing list contributions and white paper, mirroring it to the only digital cash the world had seen at that point in time: DigiCash's Ecash by Chaum.

"Hashcash may provide a stop-gap measure until digicash becomes more widely used", Back argued on the mailing list. "Hashcash is free, all you've got to do is burn some cycles on your PC. It is in keeping with net culture of free discourse, where the financially challenged can duke it out with millionaires, retired government officials, etc on equal terms. [And] Hashcash may provide us with a fallback method for controlling spam if digicash goes sour (gets outlawed or required to escrow user identities)".

Despite the name, however, Hashcash couldn't properly function as a full-fledged cash in itself (nor could Dwork and Naor's proposal). Perhaps most importantly, any "received" proof of work is useless to the recipient. Unlike money, it could not be re-spent elsewhere. On top of that, as computers increased in speed every year, they could produce more and more proofs over time at lower cost: Hashcash would have been subject to (hyper)inflation.

What proof of work did offer, more than anything else, was a new basis for research in the digital-money realm. Several of the most notable digital-money proposals that followed were building on Hashcash, typically by allowing the proofs of work to be reused. (With Hal Finney's Reusable Proof of Work – RPOW – as the most obvious example.)

 

Bitcoin

Ultimately, of course, proof of work became a cornerstone for Bitcoin, with Hashcash as one of the few citations in the Bitcoin white paper.

Yet, in Bitcoin, Hashcash (or, rather, a version of it) is utilized very differently than many would have guessed beforehand. Unlike Hashcash and other Hashcash-based proposals, the scarcity it provides is not itself used as money at all. Instead, Hashcash enables a race. Whichever miner is the first to produce a valid proof of work – a hash of a Bitcoin block – gets to decide which transactions go through. At least in theory, anyone can compete equally: much like a lottery, even small miners would statistically be the first to produce a valid proof of work every so often.

Further, once a new block is mined, confirming a set of transactions, these transactions are unlikely to be reversed. An attacker would have to prove at least as much work as required to find the block in the first place, adding up for every additional block that is found, which under normal circumstances becomes exponentially harder over time. The real-world resources that must be spent in order to cheat typically outweigh the potential profit that can be made by cheating, giving recipients of Bitcoin transactions confidence that these transactions are final.

This is how, in Bitcoin, Hashcash killed two birds with one stone. It solved the double-spending problem in a decentralized way, while providing a trick to get new coins into circulation with no centralized issuer.

Hashcash did not realize the first electronic cash system – Ecash takes that crown, and proof-of-work could not really function as money. But a decentralized electronic cash system might well have been impossible without it.

If Bitcoin Had a First Draft, Wei Dai's B-Money Was It

All Cypherpunks value privacy; it's basically the founding principle of the collective of cryptographers, academics, developers, and activists grouped around the 1990s mailing list by the same name. But few put it in practice like Wei Dai does. Once described as an "intensely private computer engineer" by the New York Times, not many personal details are known about the man who, two decades ago, dreamed up an electronic cash system intriguingly similar to Bitcoin.

This lack of personal details is made up for by Wei Dai's work and proliferation of ideas. A talented cryptographer, Dai created and still maintains Crypto++: a C++ library for cryptographic algorithms. Dai is also, to this day, active on rationality forums like LessWrong, where he philosophizes on such topics as artificial intelligence, ethics, epistemology, and more. His insights earned him the praise of well-known AI researcher Eliezer Yudkowsky and repeated invitations to speak at his  Machine Intelligence Research Institute (MIRI; previously known as the Singularity Institute).

Dai's interest in philosophy and politics is nothing new. Back in the 1990s, as a young bachelor student in computer science at Washington University, his curiosity led him to the writings of Timothy May, one of the "founding fathers" of the Cypherpunk movement. Dai was inspired by the crypto-anarchy May advocated; the brand-new ideology prevalent amongst Cypherpunks based on the conviction that cryptography and software could provide and safeguard political and economic freedom better than any system of government would.

"I am fascinated by Tim May's crypto-anarchy", Dai wrote in 1998. "Unlike the communities traditionally associated with the word 'anarchy', in a crypto-anarchy the government is not temporarily destroyed but permanently forbidden and permanently unnecessary. It's a community where the threat of violence is impotent because violence is impossible, and violence is impossible because its participants cannot be linked to their true names or physical locations".

By the mid-1990s, Dai engaged in discussions on various topics on the Cypherpunks mailing list such as digital reputation systems, game theory, privacy, and anonymity in digital cash systems. Perhaps more importantly, Dai made a number of proposals to further the Cypherpunk cause, including trusted timestamping, an encrypted TCP tunneler, a secure file sharing system, and more. It garnered him a reputation as a prolific contributor to the Cypherpunk community – though, even back then, no one knew much about him personally. (Not even whether Dai was male or female, Timothy May recently said.)

But Dai would become best known for an idea he casually announced in November 1998, just after graduating from university. "Efficient cooperation requires a medium of exchange (money) and a way to enforce contracts", Dai explained. "The protocol proposed in this article allows untraceable pseudonymous entities to cooperate with each other more efficiently, by providing them with a medium of exchange and a method of enforcing contracts. […] I hope this is a step toward making crypto-anarchy a practical as well as theoretical possibility".

He called his proposal "b-money".

 

B-money

Typical digital money systems use a central ledger to keep track of account balances. Whether it's a central bank, a commercial bank, VISA, or any other payment provider, a centrally-controlled database somewhere tracks who owns what.

The problem with this solution, from Dai's and the crypto-anarchist perspective, is that it ultimately lets governments control the flow of money through regulation, while participants in the system are usually required to identify themselves. "My motivation for b-money was to enable online economies that are purely voluntary … ones that couldn't be taxed or regulated through the threat of force", he later explained.

So, Dai came up with an alternative solution. Or really, two alternative solutions.

In the first solution, instead of a central entity controlling the ledger, all participants maintain separate copies of the same ledger. Any time a new transaction is made, everyone updates their records. These ledgers, furthermore, would consist of public keys, with amounts attached to them – no real names. This decentralized approach would prevent any single entity from blocking transactions, while offering a level of privacy to all users.

As a quick example, let's say Alice and Bob are b-money users. They both have a public key: Alice has public key "A" and Bob has public key "B", for which they both control their unique private keys. And, as recorded in the ledgers maintained by all users, both their public keys hold b-money units; let's say three units each.

If Bob wants to receive two b-money units from Alice (because he's selling her a product), he sends her his public key: B. Assuming Alice wants to buy the product, she then creates a transaction in the form of a message: "2 b-money from A to B". Next, she signs this message, with her private key corresponding to A. The message and the cryptographic signature is then sent to all b-money users.

The signed message proves to all b-money users that the rightful owner of A wants to send two b-money units to B. Everyone, therefore, updates their ledgers, now attributing a total of one b-money unit to A and a total of five b-money units to B – without learning that Alice or Bob control either.

If this solution sounds familiar, it should: It's roughly how, 10 years later, Satoshi Nakamoto designed Bitcoin.

 

B-money, Version 2

Dai considered his first b-money solution impractical, however, "because it makes heavy use of a synchronous and unjammable anonymous broadcast channel", he explained in his proposal.

Put differently, the first b-money proposal didn't solve the double-spending problem. Alice could send two b-money units to both Bob's B and to Carol's C at the same time, transmitting these transactions to different parts of the network. Both Bob and Carol would give Alice a product in return … only to later find out that half of the network won't acknowledge their new balances.

That's why Dai came up with a second b-money solution, all in the same proposal.

In this version, not everyone maintains a version of the ledger. Instead, the system would consist of two types of users: regular users and "servers". Only the servers, linked through a Usenet-style broadcast network, would maintain the b-money ledgers. To verify that a transaction went through like it should, regular users – like Bob and Carol – would have to verify it with a random subset of these servers. (In case of a conflict, Bob and Carol would presumably reject the transaction from Alice and not sell her anything.)

While not detailed in the proposal, anyone would probably have been able to become a server, but "each server is required to deposit a certain amount of money in a special account to be used as potential fines or rewards for proof of misconduct", Dai proposed. The servers should also periodically publish and cryptographically commit to ownership databases.

"Each participant should verify that his own account balances are correct and that the sum of the account balances is not greater than the total amount of money created", Dai envisioned. "This prevents the servers, even in total collusion, from permanently and costlessly expanding the money supply".

If this sounds somewhat familiar as well, that's no wonder either: Dai's second b-money proposal loosely resembles what would today be called a proof-of-stake system.

To boot, Dai added an early version of a smart contract solution to his proposal(s). These types of smart contracts most closely resemble a mixture of a proof-of-stake system and an arbitration system, where both parties to a contract and an arbitrator must all deposit funds in a special account. Curiously for modern standards, however, these contracts did not have a dispute resolution system encoded: Instead it was possible that, in case of disputes, different users (or servers) would adjust their own ledgers differently, in effect leaving the state of ledgers on the network out of consensus. (Presumably, the potential penalties would make the cost of cheating too high to risk it.)

 

Monetary Policy

Yet, where b-money would have perhaps differed most sharply from Bitcoin was Dai's proposed monetary policy.

Bitcoin's monetary policy is of course very straightforward. To bring coins in circulation, it initially issued 50 new bitcoins per block, a number that has since dropped to 12.5. This number will continue to decrease over time until, some hundred years from now, the total amount of bitcoin issued caps out at slightly below 21 million. Whether or not such a monetary policy is ideal has been a subject of debate, but one thing is clear: So far it has not produced a stable coin value.

In contrast, a stable coin value was explicitly part of Dai's vision. To achieve this, the value of b-money was to be coupled to the value of a (theoretical) basket of goods. For example, 100 b-money units would be worth one basket of goods. This should give b-money a stable value, at least in relation to this basket of goods: the same 100 b-money units would buy the same basket of goods in the past, in the present, and in the future.

To issue new coins, users were to determine what a basket of goods would cost relative to a solution to a computational problem: a "proof of work". If, for example, a basket of goods should cost $80 at specific point in time, it would have to be matched by a proof of work that would on average cost $80 to produce. If, 10 years later, the same basket of goods were to cost $120, the same 100 units would have to be matched with a proof of work that'd cost $120 to produce.

Using this indicator, the first person to produce a valid proof of work would be credited 100 new b-money by all users or the servers. Therefore, no one would be particularly incentivized to produce proofs of work unless they intended to use b-money, limiting inflation to the growth of the "b-money economy".

Alternatively, in an appendix to his proposal, Dai suggested that money creation could be realized through an auction. Either all users (first protocol) or the servers (second protocol) would first have to determine an optimal increase of the monetary base. Then, if this ideal increase were to be established at 500 b-money units, for example, an auction would determine who should create these 500 units: whoever was willing and able to provide the most proof of work for it.

 

Bitcoin

B-money was never implemented. It couldn't have been: "b-money wasn't a complete practical design yet", Dai acknowledged in a LessWrong forum thread a couple of years ago. What's more, Dai did not expect b-money to take off in a big way, even if it was implemented.

"I think b-money will at most be a niche currency/contract enforcement mechanism, serving those who don't want to or can't use government-sponsored ones", he explained in an email following his announcement on the Cypherpunks mailing list.

Indeed, several of b-money's problems remained unsolved or at least under-specified. Perhaps, most importantly, its consensus model was not very robust, as best shown by Dai's proposed smart contract solution. It has since also been found that proof-of-stake systems introduce new challenges that Dai may not have foreseen; for example, it's not clear how "misconduct" can be objectively established. And that doesn't even get into the more nuanced problems of the proposal, such as a lack of privacy due to traceability of funds or potential coin issuance ("mining") centralization. Indeed, some of these problems are still not solved for Bitcoin today.

Dai – who after proposing b-money went on to work for TerraSciences and Microsoft, and may have retired early on since then – would not stick around to solve these problems.

"I didn't continue to work on the design because I had actually grown somewhat disillusioned with crypto-anarchy by the time I finished writing up b-money", Dai later explained on LessWrong. He reiterated, "I didn't foresee that a system like it, once implemented, could attract so much attention and use beyond a small group of hardcore Cypherpunks".

Yet, Dai's proposal was not forgotten: b-money ended up as the first reference in the Bitcoin white paper. Still, as similar as b-money and Bitcoin's designs may be, it's possible that Satoshi Nakamoto was not inspired by Dai's idea at all. Dai himself believes that Bitcoin's inventor came up with the idea independently.

Shortly before publishing the Bitcoin white paper, Hashcash inventor Dr. Adam Back directed Satoshi Nakamoto to Dai's work, making Dai one of few people Bitcoin's inventor personally reached out to before publishing his white paper. But Dai did not respond to Satoshi's email. In retrospect, he wished he had. Unsurprisingly, Dai questions Bitcoin's coin generation model.

"I would consider Bitcoin to have failed with regard to its monetary policy (because the policy causes high price volatility which imposes a heavy cost on its users, who have to either take undesirable risks or engage in costly hedging in order to use the currency)", he wrote on LessWrong. "[O]ne possible impact of Bitcoin might be that due to its deficient monetary policy and associated price volatility it can't grow to very large scales, and by taking over the cryptocurrency niche, it has precluded a future where a cryptocurrency does grow to very large scales".

He added, "This may have been partially my fault because when Satoshi wrote to me asking for comments on his draft paper, I never got back to him. Otherwise, perhaps I could have dissuaded him (or them) from the 'fixed supply of money' idea".

Author's note: After finishing this article, it was pointed out that the first version of Nick Szabo's Bit Gold goes back to early 1998. Even more similar to Satoshi Nakamoto's invention than b-money, it's probably more accurate to consider Bit Gold "Bitcoin's first draft".

With Bit Gold, Szabo was Inches Away from Inventing Bitcoin

As his Hungarian parents had fled post-war Soviet regime to settle in the United States, Nick Szabo came to call the Californian Bay area of the 1990s his home. Here, he was among the first to frequent the in-person "Cypherpunk" meetings organized by Timothy May, Eric Hughes, and other founding members of the collective of cryptographers, programmers and privacy activists centered around the '90s mailing list of the same name.

Like the other Cypherpunks, Szabo was concerned with the receding guarantees of privacy in an upcoming digital age and took action to stem the tide where he could. For example, on the Cypherpunks mailing list, Szabo led opposition to the "Clipper chip", a proposed chip that would have been embedded in phones, allowing the NSA to listen in to calls. Szabo had a particular knack for explaining the risks of such privacy infringements in a way that resonated with non-technical people, sometimes giving talks on the topic or even handing out flyers. (The chip would eventually be rejected by manufacturers and consumers.)

But like the more libertarian-oriented Cypherpunks, Szabo's interest in digital privacy was part of a bigger picture – it was not just about privacy alone. Inspired by Timothy May's vision as laid out in The Crypto Anarchist Manifesto, Szabo saw the potential to create a "Galt's Gulch" in cyberspace: a domain where individuals could trade freely, as described libertarian author Ayn Rand's novel Atlas Shrugged. The pseudo-physics force field of the story, May and Szabo believed, could be substituted with the recently invented magic of public-key cryptography.

"If we step back and look at what many cypherpunks are trying to achieve, a major idealistic theme is a Gandhian cyberspace where violence can only be make-believe, whether in Mortal Kombat or 'flame wars,'" Szabo wrote on the Cypherpunks mailing list.

Yet, Szabo also realized that free enterprise needs more than just encryption as a security layer. Inspired by another libertarian author – economist Friedrich Hayek – he found that the basis of human society is, to a large extent, based on building blocks, like property and contracts, which are typically enforced by the state. To create a stateless, non-violent cyber alternative, Szabo knew that these building blocks had to be transferred to the online domain.

This is how Szabo, by the mid-1990s, came to propose what he is perhaps best known for today: smart contracts. These (then-hypothetical) computer protocols could digitally facilitate, verify and enforce the negotiation or performance of a contract, ideally without the need of any third party. As Szabo had famously argued: "Trusted third parties are security holes". These security holes would be targets for hackers or criminals – as well as nation-states during times of political instability or oppression.

But smart contracts were only part of the puzzle. The second tool Szabo needed in order to realize his "Galt's Gulch" was possibly even more important. Money.

 

Electronic Cash

Digital currency, a cash for the internet, was always a central goal for the Cypherpunks. But few dived into the subject matter like Szabo did.

In his essay "Shelling Out: The Origins of Money", Szabo described how – as first hypothesized by evolutionary biologist Richard Dawkins – using money has been embedded in the very DNA of humans. Having analyzed pre-civilized societies, Szabo found that people across cultures tended to collect scarce, easy-to-carry objects, often to make jewellery out of them. It was these objects that served as money, which in turn allowed humans to cooperate: game theoretical "reciprocal altruism" through trade, at scale and across time.

Szabo also took a keen interest in free banking, a monetary arrangement advocated by Hayek, where private banks issue their own currency not bound to any particular state. Under such a system, it's completely up to the free market to choose which money to use. While a novel idea today (and even more so in the years before Bitcoin), free banking was a reality in the United States of the 1800s, as well as in several other countries.

Szabo also went on to put his interest into practice and sold his expertise as an internet commerce consultant by the mid-1990s, long before most saw the potential of online commerce. Most notably, he spent some time working at David Chaum's DigiCash startup, headquartered in Amsterdam. Chaum's company introduced the first digital cash the world had ever seen in the form of eCash: a means to make payments online as private as cash in real life was.

But it was also at DigiCash where Szabo learned about the risks of Chaum's solution. DigiCash was a centralized company, and Szabo found it was far too easy for him and others to mess with people's balances if they'd wanted to. Trusted parties are security holes, after all, and this risk is perhaps nowhere bigger than with money.

"The problem, in a nutshell, is that our money currently depends on trust in a third party for its value", Szabo argued in 2005. "As many inflationary and hyperinflationary episodes during the 20th century demonstrated, this is not an ideal state of affairs".

In fact, he considered this trust problem such an obstacle that even a typical free banking solution could suffer from it: "[P]rivate bank note issue, while it had various advantages as well as disadvantages, similarly depended on a trusted third party".

Szabo knew he wanted to create a new form of money that did not depend on trust in any third party.

Based on his analysis of prehistoric money, Szabo had come a long way in figuring out what his ideal money would look like. First, it had to be "secure from accidental loss and theft". Second, its value must be "unforgeably costly, and therefore considered valuable". And third: "This value [had to be] accurately approximated by simple observations or measurements".

Best compared to precious metals like gold, Szabo wanted to create something that was both digital and scarce, where this scarcity did not depend on any third-party trust. He wanted to create a digital gold.

 

Bit Gold

Szabo first came up with Bit Gold in 1998, though he only fully described it in public in 2005. His proposed digital money scheme consisted of a combination of solutions, some of which were inspired by (or resembled) previous electronic cash concepts.

The first central property of Bit Gold was proof of work, the cryptographic trick utilized by Dr. Adam Back in his "anti-spam currency" Hashcash. Proof of work represented the unforgeable costliness Szabo was looking for, as it required real-world resources – computing power – to produce these proofs.

Bit Gold's proof-of-work system started with a "candidate string": basically a random number. Anyone could take this string and mathematically combine – "hash" – it with another, newly generated random number. By the nature of hashing, the result would be a new, seemingly random string of numbers: the hash. The only way to find out what this hash looks like is to actually create it – it cannot otherwise be computed or predicted.

The trick, also utilized in Hashcash, is that not all hashes are considered valid within the Bit Gold protocol. Instead, a valid hash must, for example, start with a predetermined number of zeros. Because of the unpredictable nature of hashing, the only way to find such a valid hash is trial and error. A valid hash, therefore, proves that its creator expended computing power.

This valid hash would, in turn, be the next Bit Gold candidate string. The Bit Gold system would, therefore, grow into a chain of proof-of-work hashes, and there'd always be a next candidate string to work with.

Whoever would find a valid hash would quite literally own that hash, similar to how the person that finds a bit of gold ore owns it. To establish this ownership digitally, Bit Gold used a digital ownership registry: another Hayek-inspired building block proposed by Szabo. In this registry, the hashes were to be linked to the public keys of their respective creators.

It was also through this digital ownership registry that a hash could be transferred to a new owner: The original owner would literally sign off on a transaction with a cryptographic signature.

The ownership registry was to be maintained by a Bit Gold "property club". This property club consists of "club members" (servers) that would keep track of which public keys own which hashes. This solution somewhat resembled Wei Dai's proposed replicated database solution for b-money; both Szabo and Dai were not only active on the Cypherpunks' mailing list, but also on a closed email list discussing these topics.

But instead of Dai's proof-of-stake system to keep the system up to date, Szabo proposed a "Byzantine Quorum System". Similar to security-critical systems like airplane board computers, if only one (or a minority) of these computers should fall out of line, the system as a whole would continue to operate fine. Only if a majority of computers were to fail at the same time would the system be in trouble. Importantly, none of these checks required courts or judges or police, backed by the state monopoly on violence: It would all be voluntary.

While this system was not in itself 100 percent watertight – it could for example be Sybil attacked (the "sock puppet problem") – Szabo believed it could work itself out. Even in the scenario where a majority of club members would attempt to cheat, the honest minority could branch off into a competing ownership registry. Users could then choose which ownership registry to use, which Szabo thought would probably be the honest one.

"If the rules are violated by the winning voters, the correct losers can exit the group and reform a new group, inheriting the old titles", he explained. "Users of the titles (relying parties) who wish to maintain correct titles can securely verify for themselves which splinter group has correctly followed the rules and switch to the correct group".

(As a modern-day example, this can perhaps be compared with Ethereum Classic, which maintains a version of the original Ethereum ledger that did not undo The DAO smart contract.)

 

Inflation

The next problem that Szabo had to solve was inflation. As computers improve over time, it would become easier and easier to generate valid hashes. This means that the hashes themselves can't function as money very well: they would become increasingly less scarce every year, to the point where abundance would dilute all value.

Szabo figured out a solution. Once a valid hash was found, it had to be timestamped, ideally with different timestamp servers to minimize trust in any particular one. This timestamp would give an idea of how hard it was to produce the hash: an older hash would have been harder to produce than a newer hash. Markets would then determine how much any particular hash is worth relative to one another, presumably adjusting its value for the date it was found. A valid "2018 hash" should be worth much less than a valid "2008 hash".

But this solution, of course, introduced a new problem, Szabo knew: "the bits (the puzzle solutions) from one period (anywhere from seconds to weeks, let's say a week) to the next are not fungible". Fungibility – the idea that any currency unit is equal to any other unit – is critical for money. A shopkeeper wants to accept a payment without having to worry about the date the money was created.

Szabo came up with a solution to this problem as well. He envisioned a sort of "second layer" solution on top of the Bit Gold base layer. This layer would consist of a type of bank, though a securely auditable bank, since the Bit Gold registry was public. These banks would collect different hashes from different time periods and, based on the value of these hashes, bundle them into packets of a combined standard value. A "2018 pack" would include more hashes than a "2008 pack", but both packs would be worth the same.

These packs, then, were to be cut up in a specific number of units. Finally, these units could be issued by the "banks" as a private and anonymous Chaumian eCash.

"[C]ompeting banks issue digital banknotes redeemable in solution bits whose market values add up to the face value of the bank note (i.e. they create bundles of standard value)", Szabo explained.

Thus, Bit Gold was designed as a gold standard-like base layer for a free banking system of the digital age.

 

Bitcoin

In the 2000s, Szabo went on to earn a law degree to understand the law and contract reality he wished to replace or replicate online even better. He also started to collect and publish his ideas on a well-respected blog, "Unenumerated", which covers topics ranging from computer science to law and politics, but also history and biology. "The list of topics for this blog […] is so vast and varied that it cannot be enumerated", Szabo explained the title.

By 2008 – 10 years after first proposing it in private – Szabo brought up Bit Gold on his blog once again, only this time he wanted to realize a first implementation of his proposal.

"Bit Gold would greatly benefit from a demonstration, an experimental market (with e.g. a trusted third party substituted for the complex security that would be needed for a real system). Anybody want to help me code one up?" he asked in the comment section his blog.

If someone responded, it wasn't in public. Bit Gold, in Szabo's proposed form, was never implemented.

However, Bit Gold did serve as a key inspiration for Satoshi Nakamoto, who published the Bitcoin white paper later that same year.

"Bitcoin is an implementation of Wei Dai's b-money proposal […] on Cypherpunks […] in 1998 and Nick Szabo's Bitgold proposal", Bitcoin's pseudonymous inventor wrote on the Bitcointalk forum in 2010.

Indeed, it's not difficult to see Bit Gold as an early draft of Bitcoin. Apart from the shared database of ownership records based on public-key cryptography, the chain of proof-of-work hashes has an eerie resemblance to Bitcoin's blockchain. And, of course, the names Bit Gold and Bitcoin are not too far apart either.

Yet, unlike systems like Hashcash and b-money, Bit Gold was conspicuously absent from the Bitcoin white paper. Some have even considered this absence so notable they took it as one of several hints that Szabo must be the man behind the Satoshi Nakamoto monicker: Who else would try to hide Bitcoin's origins like this?

Still, while similar to Bit Gold in several ways, Bitcoin did include some improvements over Szabo's design. In particular, where Bit Gold still relies on trusted parties to an extent – servers and the timestamp services must be trusted to some degree not to collude – Bitcoin was the first system to solve this problem entirely. It solves it very elegantly, by having the required proof-of-work system serve as both an award system and a consensus mechanism in one: The hash chain with the most proof of work is considered the valid version of history.

"Nakamoto improved a significant security shortcoming that my design had", Szabo acknowledged in 2011, "namely by requiring a proof-of-work to be a node in the Byzantine-resilient peer-to-peer system to lessen the threat of an untrustworthy party controlling the majority of nodes and thus corrupting a number of important security features".

Further, Bitcoin has a very different monetary model than Szabo proposed, with a fixed inflation schedule that remains unaffected by hash power increases altogether. As computing power on the Bitcoin network increases, it just means that it's harder to find new coins.

"Instead of my automated market to account for the fact that the difficulty of puzzles can often radically change based on hardware improvements and cryptographic breakthroughs (i.e. discovering algorithms that can solve proofs-of-work faster), and the unpredictability of demand, Nakamoto designed a Byzantine-agreed algorithm adjusting the difficulty of puzzles", Szabo explained.

"I can't decide whether this aspect of Bitcoin is more feature or more bug", he added, "but it does make it simpler".