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.
The header line looks something like this:
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.
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 220 headers will have 20 zeros as the beginning of the hash, the sender will on average have to try 220 random numbers to find a valid header. Given reasonable estimates of the time needed to compute the hash,[when?] 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 inconvenienced by the processing time required to generate the Hashcash string. However, spammers would suffer significantly due to the large number of spam messages sent by them.
Technically the system is implemented with the following steps:
- The recipient's computer calculates the 160-bit SHA-1 hash of the entire string (e.g.,
"1:20:060408:firstname.lastname@example.org::1QTjaYd7niiQA/sc:ePa"). This takes about two microseconds on a 1 GHz machine, far less time than the time it takes for the rest of the e-mail to be received. If the first 20 bits are not all zero, the hash is invalid. (Later versions may require more bits to be zero as machine processing speeds increase.)
- The recipient's computer checks the date in the header (e.g.,
"060408", which represents the date 8 Apr 2006). If it is not within two days of the current date, it is invalid. (The two-day window compensates for clock skew and network routing time between different systems.)
- The recipient's computer checks whether the e-mail address in the hash string matches any of the valid e-mail addresses registered by the recipient, or matches any of the mailing lists to which the recipient is subscribed. If a match is not found, the hash string is invalid.
- The recipient's computer inserts the hash string into a database. If the string is already in the database (indicating that an attempt is being made to re-use the hash string), it is invalid.
If the hash string passes all of these tests, it is considered a valid hash string. All of these tests take far less time and disk space than receiving the body content of the e-mail.
The time needed to compute such a hash collision is exponential with the number of zero bits. So zero bits can be added (doubling the amount of time needed to compute a hash with each additional zero bit) until it is too expensive for spammers to generate valid header lines.
Confirming that the header is valid always takes the same amount of time, no matter how many zero bits are required for a valid header, since this requires only a single hashing operation.
Advantages and disadvantages
|This section needs additional citations for verification. (August 2010)|
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 to pay, thus the administrative issues involved with all micropayment systems are entirely avoided.
On the other hand, as Hashcash requires potentially significant computational resources to be expended on each e-mail being sent, it is somewhat difficult to tune the ideal amount of average time you wish clients to expend computing a valid header. This can mean sacrificing accessibility from low-end embedded systems or else running the risk of hostile hosts not being challenged enough to provide an effective filter from spam.
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.
One plausible analysis concluded that only one of the following cases is likely: either non-spam e-mail will get stuck due to lack of processing power of the sender, or spam e-mail is bound to still get through. Examples of each include, respectively, a centralized e-mail topology (like a mailing list), in which some server is to send an enormous amount of legitimate e-mails, and botnets or cluster farms with which spammers can increase their processing power enormously.
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 remain to be addressed.
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.
The Penny Post software project on SourceForge implements Hashcash in the Mozilla Thunderbird email client. 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.
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. 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.
Microsoft also designed and implemented a now deprecated open spec, similar to and yet incompatible with Hashcash, Email Postmark,  as part of their Coordinated Spam Reduction Initiative (CSRI). The Microsoft email postmark variant of Hashcash is implemented in the Microsoft mail infrastructure components Exchange, Outlook and Hotmail. The format differences between Hashcash and Microsoft's email postmark is that postmark hashes the body in addition to the recipient, and uses a modified SHA1 as the hash function and uses multiple sub-puzzles to reduce proof of work variance.
Bitcoin is a virtual currency that uses hashcash (with minor changes) for the generation and verification of currency. Proof-of-work is used to protect the network and keep it decentralized with no central authority - rather, processing power becomes votes.
|This section may require cleanup to meet Wikipedia's quality standards. The specific problem is: a number of oddities were recently fixed in this section, but the one fixing them was not familiar with all of Wikipedia's guidelines and writing styles, so it is very likely that some still remain. (February 2014)|
RSA has made IPR statements to the IETF about client-puzzles in the context of an RFC 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 (Mar 1997) the client-puzzles publication (Feb 1999) and the client-puzzles patent filing US7197639 (Feb 2000).
- Announcement of Hashcash, from hashcash.org
- link to hashcash.org
- Hashcash proof-of-work paper
- Penny Post software project on SourceForge
- "Penny Post: What do you mean by Postage Stamp?". Pennypost.sourceforge.net. 2008-06-16. Retrieved 2014-02-11.
- "Hashcash FAQ". Hashcash.org. 2003-06-26. Retrieved 2014-02-11.
- "SpamAssassin: Tests Performed: v3.3.x". Spamassassin.apache.org. 2006-12-21. Retrieved 2014-02-11.
- "The Coordinated Spam Reduction Initiative: A Technology and Policy Proposal" (PDF). Retrieved 2014-02-11.
- Nakamoto, Satoshi (1 Nov 2008). "Bitcoin: A Peer-to-Peer Electronic Cash System". Retrieved 20 December 2012.
- C reference implementation
- RSA IETF client-puzzles
- Draft Jennings SIP hashcash
- hashcash announce
- client puzzles
- client-puzzle patent filing
- 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)