Genesis Documentation: How Adam Back Designed the Bitcoin Engine

Without Hashcash, there probably wouldn’t be a decentralized digital cash system today.

Genesis Documentation: How Adam Back Designed the Bitcoin Engine

[Announcement] hach cash stamp implementation
On March 28, 1997, over 2000 subscribers to the CryptoPunk mailing list received an email that began with the quote above. The sender was a 26 year old Englishman, a post-doc at the University of Exeter. This young cryptographer goes by the name Dr. Adam Back in the mailing group and is a prolific contributor to the mailing group. The explanation and simple implementation contained in this email is named by the author as “Partial Hash Collision Based Postage Scheme” — actually the equivalent of a postage stamp used in email, except that it is based on a nice cryptographic scheme.

“The rationale for using partial hashes is that their computational cost can be arbitrarily cranked up,” Back writes, “but instantly verifiable.” That’s how he explains the advantages of this system.

The cryptographer of the day is now the CEO of Blockstream, but that email didn’t make much of a splash at the time: only one reader wrote back, and it was about the technicalities of choosing a hashing algorithm. But the technology behind Hashcash — proof of workload — has shaped digital currency research for more than a decade since its birth.

“Fighting spam by imposing a cost on task processing”
Back’s Hashcash wasn’t the pioneer of its kind.

Back in the early 1990s, the promise of the Internet, and especially the virtues of email systems, was obvious to concerned technicians. But the Internet pioneers of the time, too, realized that the e-mail system had its own problems.

“In particular, it was easy and inexpensive to send e-mail, and you could send the same message to many people, and that was bound to invite abuse,” IBM researchers Dr. Cynthia Dwork and Dr. Moni Naor explained in their white paper published in 1992. The whitepaper is called “Taking a Task as a Task. The white paper was called “Fighting Spam at the Cost of Task Processing.

Indeed, as email became popular, so did spam.

A solution was needed, early Internet users agreed — and one was provided by Dwork and Naor’s paper.

The solution they both came up with was for the person sending the e-mail to append some data to the message whenever they sent a message. The data needs to be the solution to a mathematical problem, and the problem posed by each email is unique. Specifically, Dwork and Naor propose three candidate puzzle forms that can be used in this scenario, all based on public-key cryptography and signature schemes.

It is not difficult to add a solution to an email, ideally requiring the processing power of an average computer for a few seconds, and it is easy for the recipient to check its validity. Here’s where it gets interesting: for advertisers, scammers, and hackers, even if an email requires only a little processing power, it can still add up to a high cost because they all want to send thousands or even millions of messages at once. In theory, the cost of sending messages indiscriminately can be so exorbitant and expensive as to be unprofitable.

“The main idea is to let users compute a function that is moderately difficult and not tricky before gaining access to resources, thus preventing abuse,” Dwork and Naor explain.

Although Dwork and Naor did not invent the term, their proposed solution became known under the name “proof of workload”. Users had to show the results of their computer’s work as proof that they had spent real-world resources.

What a beautiful solution, but unfortunately probably too far ahead of its time. The scheme was only circulated within a small circle of computer scientists and never received widespread attention.

Adam Back and Cryptopunk
At the same time that Dwork and Naor published their white paper, a group of Libertarian-leaning privacy activists were beginning to realize the powerful potential of the Internet. This group of like-minded individuals began to form an email group dedicated to exploring privacy-enhancing technologies. Like Dwork and Naor, these “cryptopunks” — as they were later called — used newer cryptography to achieve their goals.

A few years later, Adam Back — who earned his Ph.D. in 1996 — became one of the most active participants in the email group, sometimes sending dozens of emails a month. Like other crypto-punks, he was passionate about topics such as privacy, free speech, and free willism, and he was involved in technical discussions on topics such as “anonymous relayers,” encrypted file systems, and electronic cash (invented by Dr. David Chaum).

But for a while, Back was probably best known for printing and selling “arms” tops: that is, T-shirts with encryption technology protocols on them, meant to point out that the U.S. government had made Phil Zimmermann’s PGP (Pretty Good Privacy) It is meant to point out the absurdity of the U.S. government regulating Phil Zimmermann’s PGP (Pretty Good Privacy) encryption program under the “arms” provision of export control laws. You’d be an “arms exporter” if you wore Back’s clothes and crossed the border out of the United States.

Like most people, Back took no notice of Dwork and Naor’s workload certification proposal. But in the mid-1990s, he was thinking of similar ways to combat spam, sometimes speaking “loudly” in crypto-punk email groups.

For example, in the context of adding more privacy to forwarders, Back would comment: “One of the benefits of using the PGP protocol is that the PFP encryption method imposes some overhead on the spammer — he should be able to encrypt more messages per second than he can use to stuff less than the number needed to stuff a T3 link”. How like Dwork and Naor’s idea.

The crypto-punk email group grew rapidly in five years. What started as an online discussion platform for a small group of people starting startups in the San Francisco Bay Area became a small Internet phenomenon with thousands of subscribers — and often too many emails to read.

It was during this time — 1997, when the email group was nearing peak size — that Back came up with his Hashcash.

Hashcash
Hashcah was similar to Dwork and Naor’s anti-spam scheme, and had the same purpose, but Back proposed some additional uses, such as resisting the abuse of anonymous relayers. But as the name implies, Hashcash is not based on the same set as that used by Dwork and Naor, it is based on a hash algorithm.

A hash algorithm is a cryptographic tool that accepts arbitrary data — whether a single letter or an entire book — as input and then outputs a seemingly random number of defined length.

As an example, the SHA-256 hash of the sentence “This is a sentence” would be the following hexadecimal number.

Genesis Documentation: How Adam Back Designed the Bitcoin Engine

“Convert” to regular decimal numbers as.

Genesis Documentation: How Adam Back Designed the Bitcoin Engine

The binary form is then

Genesis Documentation: How Adam Back Designed the Bitcoin Engine

However, the SHA-256 hash of “This, is a sentence” is.

Genesis Documentation: How Adam Back Designed the Bitcoin Engine

As you can see, just inserting a single punctuation can produce a completely different hash value. And, importantly, the hashes of both sentences are completely unpredictable; even if you know the hash of the first sentence, you can’t derive the hash of the second sentence from it. The only way to find out is to actually run the hash calculation.

Hashcash makes clever use of this mathematical tool.

In Hashcash, the metadata of an email (e.g. “sender address”, “recipient address”, time of sending, etc.) are formalized as a protocol. In addition, the sender of the email must add a random number, called “nonce”, to this part of the metadata. All this metadata, including this “nonce”, (when entered into the hash function) yields a hash value that will look just as unstructured as the random number shown above.

The mystery is that not just any hash value can be considered “valid”. The binary form of the hash must start with a predetermined number of “0s” to be considered valid; for example, it must start with 20 “0s”. The sender has to find a nonce so that the hash value starts with 20 “0s”. However, he cannot know in advance which nonce can do this.

Therefore, to come up with such a valid hash, the sender has only one option: trial and error (i.e., “brute force computing”). He can only keep trying different nonce until he finds a valid combination. Otherwise, the TA’s mail is rejected by the recipient’s mail client. Just like Dwork and Naor’s scheme, Hashcash also demands computational resources: it is a proof-of-workload system.

“If the message doesn’t come with a 20-bit hash …… your program will pop up a statement explaining that you need to pay postage to send the message and where to get the right software,” Back explained in the Cryptopunk Mail group. “This could bankrupt spammers overnight, because 100,0000 x 20 = 100 MIP years is way more than they can compute”.

It is worth noting that Back’s proof-of-workload system is more random than Dwork and Naor’s. Both of their schemes simply solve a puzzle, which means that a faster computer always solves it faster (than a less well-conditioned computer). But statistically speaking, the slower computer in Hashcash also has a chance of finding the correct solution faster.

(For example, if someone runs faster than others, the TA will win every time in a sprint race. But if someone simply buys more lottery tickets, there is always a chance that someone else will win more than he does — just not as often.)

Scarcity in the digital world
Similar to the fate of Dwork’s and Naor’s proposals, Hashcash has never gained much traction. Apache’s open source SpamAssassin (spam filtering) platform implemented it, and Microsoft leveraged the idea of workload proofs in an incompatible “email postmark” format. Back and others, who have worked for years to come up with different applications for this solution, have not received much attention. For most potential applications, the lack of network effects makes them difficult to start.

However, Dwork and Naor, and Back’s (independent research), all did create something. One of the most powerful properties of digital products is that they can be easily replicated, and the workload proves to be essentially the first notion of virtual scarcity that does not depend on the center: it ties electronic data to real-world, limited computational resources.

And scarcity, no doubt, is a prerequisite for currency. In fact, Back, in both his cryptopunk email statements and his white paper, specifically and explicitly placed Hashcash in the category of currency, as opposed to the only digital cash in the world at the time (Chaum’s DigiCash).

“Hashcash may provide a temporary measure until digicash gains widespread use,” Back said in the email group, “Hashcash is free, you just consume some computation on your computer to get it. It’s in line with the free expression internet culture, where people of modest means can talk to millionaires, retired government officials, etc. on an equal footing. (And) if something goes wrong with digicash (a takeover or a request to hold a user’s identity), Hashcash can also provide a fallback solution to control spam.”

But beyond the name, Hashcash doesn’t work well as a full-fledged cash (and Dwork and Naor’s proposal certainly doesn’t). Perhaps more importantly, the proof of workload “received” by the recipient is of no use to him. Unlike currency, you can spend it elsewhere. Moreover, because computers are getting more and more powerful, they can generate more and more proofs in the same amount of time – Hashcash will suffer from hyperinflation.

All else aside, what proofs of workload offer is a whole new foundation for digital currency research. Most of the major digital currency schemes that followed were built on Hashcash and generally allowed for the reuse of proofs of work (Hal Finney’s “reusable proof of work (PROW)” is the most obvious example).

Bitcoin
Ultimately, of course, proofs of work became the cornerstone of Bitcoin, and Hashcash is one of the few references in the Bitcoin white paper.

However, Bitcoin utilizes Hashcash (or a variant of it) in a very different way than others have previously suggested. Unlike Hashcash and other Hashcash-based schemes, the proof of workload itself provides scarcity and is not directly used as a currency in Bitcoin. In fact, Hashcash is used to create a kind of race: whichever miner makes a valid proof of work first — that is, the hash of a block of Bitcoin transactions — the TA determines which transactions are the next batch of get processed. At least in theory, everyone is on an equal playing field: much like a lottery, even a small miner has the probability of being the first to make a valid workload at a certain locus.

Further, every time a block is mined, it confirms a batch of transactions that are unlikely to be revoked. The attacker has to prove that he did at least as much work as the block that was mined first (the one that came out of the block), and this amount of work accumulates as subsequent blocks appear, which in normal circumstances increases exponentially in difficulty. As a result, the real-world resources required to cheat will generally be greater than the potential profit to be made by the cheat. The recipient of a bitcoin transaction, therefore, has the confidence that the money he or she receives will not disappear into thin air.

This use of Hashcash kills two birds with one stone: it solves the “multipayment problem” in a decentralized way and provides a way for new coins to enter circulation again without a centralized issuer.

Hashcash didn’t become the first electronic cash system — Ecash already had a head start, and the proof of workload itself couldn’t actually be used as a currency. But without it, a decentralized digital cash system probably wouldn’t have emerged to date.

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/genesis-documentation-how-adam-back-designed-the-bitcoin-engine/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2021-06-03 19:35
Next 2021-06-03 19:40

Related articles