Hashcash

Hashcash is a proof-of-work system designed to limit email spam and denial-of-service attacks. It is also used as the proof-of-work protocol in Bitcoin. Hashcash was proposed in March 1997 by Adam Back.^[1]

How it works

Hashcash is a method of adding a textual stamp to the header of an email to prove the sender has expended a modest amount of CPU time calculating the stamp prior to sending the email. In other words, as the sender has taken a certain amount of time to generate the stamp and send the email, it is unlikely that they are a spammer. The receiver can, at negligible computational cost, verify that the stamp is valid. However, the only known way to find a header with the necessary properties is brute force, trying random values until the answer is found; though testing an individual string is easy, if satisfactory answers are rare enough it will require a substantial number of tries to find the answer.

The theory is that spammers, whose business model relies on their ability to send large numbers of emails with very little cost per message, cannot afford this investment into each individual piece of spam they send. Receivers can verify whether a sender made such an investment and use the results to help filter email.

Technical details

The header line looks something like this^[2]:

X-Hashcash: 1:20:060408:adam@cypherspace.org::1QTjaYd7niiQA/sc:ePa

The header contains: the recipient's email address, the date, and information proving the required computation has been performed. The presence of the recipient's email address requires that a new header be computed for each recipient, and the date allows the recipient to record headers received recently and make sure the header is unique to this email.

Sender's side

The sender prepares a header and adds an initial random number. It then computes the 160 bit SHA-1 hash of the header. If the first 20 bits of the hash are zeros then this is an acceptable header. If not then the sender increments the random number and tries again. Since about 1 in 2²⁰ headers will have 20 zeros as the beginning of the hash the sender will on average have to try 2²⁰ random numbers to find a valid header. Given reasonable estimates of the time needed to compute the hash,^{[as of?]} this would take about 1 second to find. At this time no more efficient method is known to find a valid header.

A normal user on a desktop PC would not be significantly impacted by the processing time required to generate the Hashcash string. However, spammers would suffer a significant impact due to the high number of spam messages required.

Recipient's side

Technically the system is implemented as follows:

The recipient's computer calculates the 160 bit SHA-1 hash of the entire string "1:20:060408:adam@cypherspace.org::1QTjaYd7niiQA/sc:ePa". This takes about two microseconds on a 1 GHz machine—far shorter than the time it took for the rest of the e-mail to be received. If the first 20 bits are all zero, then it is valid. Later versions may require more bits to be zero.
The recipient's computer checks the date in that header "060408" (8 Apr 2006). If it's within 2 days of today, it's valid (to compensate for clock skew and routing time).
The recipient's computer checks to see if the e-mail address in the hashcash header is (any of) the valid e-mail address(es) of the recipient (or any mailing lists to which the recipient is subscribed).
If all the other checks are valid, the recipient's computer puts that string in a database. If that string was not already in the database, it is valid.

All these tests take far less time and disk space than receiving the rest of the e-mail.

Required effort

The time needed to compute such a hash collision is exponential with the number of zero bits. So one can keep adding zero bits (doubling the amount of time needed to send with each zero bit) until it is too expensive for spammers to generate valid header lines. (Confirming the header is valid always takes the same amount of time, no matter how many zero bits are required for a valid header.)

Advantages and disadvantages

The Hashcash system has the advantage over micropayment proposals applying to legitimate email that no real money is involved. Neither the sender nor recipient need pay, thus the administrative issues involved with all micropayment systems are entirely avoided.

On the other hand, as Hashcash requires significant computational resources to be expended on each e-mail being sent, it is impractical to use with low-end embedded systems without the help of an external server.^{[citation needed]}

Hashcash is also fairly simple to implement in mail user agents and spam filters. No central server is needed. Hashcash can be incrementally deployed—the extra Hashcash header is ignored when it is received by mail clients that do not understand it.

Some plausible estimates^[3] come to the conclusion that you can only have one of these: Either good e-mail will get stuck due to lack of processing power of the sender, or bad e-mail is bound to still get through.^{[citation needed]} The reasons for this are botnets or cluster farms with which spammers can increase their processing power enormously, or centralized e-mail-topologies like mailing lists, in which some server is to send an enormous amount of legitimate e-mails.

Most of these issues may be addressed. E.g., botnets may expire faster because users notice the high CPU load and take counter-measures, and mailing list servers can be registered in white lists on the subscribers' hosts and thus be relieved from the hashcash challenges. But they represent serious obstacles to hashcash deployment that need to be addressed somehow.^{[citation needed]}

Another projected problem is that computers continue to get faster according to Moore's law. So the difficulty of the calculations required must be increased over time. However, developing countries can be expected to use older hardware, which means that they will find it increasingly difficult to participate in the email system. This also applies to lower-income individuals in developed countries who cannot afford the latest hardware.

Implementations

Email clients

The Penny Post software project^[4] on SourceForge implements Hashcash in the Mozilla Thunderbird email client.^[5] The project is named for the historical availability of conventional mailing services that cost the sender just one penny; see Penny Post for information about such mailing services in history.

Spam filters

Hashcash has been recommended as a potential solution for false positives with automated spam filtering systems, as legitimate users will rarely be inconvenienced by the extra time it takes to mint a stamp.^[6] SpamAssassin has checked for Hashcash stamps since version 2.70, assigning a negative score (i.e. less likely to be spam) for valid, unspent Hashcash stamps. In the 3.3.x series (the current version at time of writing), it gives a bonus for any stamp 20 bits or greater, capping at -5 points for a stamp 26 bits or greater; however, an already-spent stamp incurs a small penalty.^[7]

Blogs

Like e-mail, blogs often fall victim to comment spam. Some blog owners have used hashcash scripts written in the JavaScript language to slow down comment spammers.^[8] Some scripts (such as wp-hashcash) claim to implement hashcash but instead depend on JavaScript obfuscation to force the client to generate a matching key; while this does require some processing power, it does not use the hashcash algorithm or hashcash stamps.

Intellectual Property

Hashcash is not patented, and the reference implementation ^[9] and most of the other implementations are open source. Hashcash is included or available for many linux distributions. (Fedora/redhat type sudo yum install hashcash for ubuntu/debian type sudo apt-get install hashcash).

RSA has made IPR statements to the IETF about client-puzzles ^[10] in the context of an RFC ^[11] that described client-puzzles (not hashcash). The RFC included hashcash in the title and referenced hashcash but the mechanism described in it is a known solution interactive challenge which is more akin to Client-Puzzles; hashcash is non-interactive and therefore does not have a known-solution. In any case RSA's IPR statement can not apply to hashcash because hashcash predates ^[12] (Mar 1997) the client-puzzles publication ^[13] (Feb 1999) and the client-puzzles patent filing US7197639 ^[14] (Feb 2000).

References

Adam Back, "Hashcash - A Denial of Service Counter-Measure", technical report, August 2002 (PDF).
Ben Laurie and Richard Clayton, "'Proof-of-Work' Proves Not to Work", WEIS 04. (PDF).
Dwork, C. and Naor, M. (1992) "Pricing via Processing or Combating Junk Mail", Crypto '92, pp. 139–147. (PDF)

^ Announcement of Hashcash, from hashcash.org
^ link to hashcash.org
^ Hashcash proof-of-work paper
^ Penny Post software project on SourceForge
^ http://pennypost.sourceforge.net/PostageStamps
^ http://www.hashcash.org/faq/
^ http://spamassassin.apache.org/tests_3_3_x.html
^ WP-Hashcash, a plugin for Wordpress blog software that implements a Hashcash-like facility, written in JavaScript, by Elliott Back
^ C reference implementation
^ RSA IETF client-puzzles
^ Draft Jennings SIP hashcash
^ hashcash announce
^ client puzzles
^ client-puzzle patent filing

External links

http://hashcash.org — Hashcash homepage
Beat spam using hashcash — David Mertz's article on hashcash, its applications and an implementation in Python.
RSA IPR note to the IETF about hashcash (2004)

[1] Announcement of Hashcash, from hashcash.org

[2] to hashcash.org

[3] Hashcash proof-of-work paper

[4] Penny Post software project on SourceForge

[5] ttp://pennypost.sourceforge.net/PostageStamps

[6] ttp://www.hashcash.org/faq/

[7] ttp://spamassassin.apache.org/tests_3_3_x.html

[8] WP-Hashcash, a plugin for Wordpress blog software that implements a Hashcash-like facility, written in JavaScript, by Elliott Back

[9] C reference implementation

[10] RSA IETF client-puzzles

[11] Draft Jennings SIP hashcash

[12] shcash announce

[13] t puzzles

[14] t-puzzle patent filing

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]