hashcash for windows GUI based application
command line tool and library
hashcash in java applet (in web browser)
hashcash in java
hashcash for RISC-OS
Hash cash is payment in burnt CPU cycles by calculating n-bit partial hash collisions on chosen texts.
The idea of using partial hashes is that they can be made arbitrarily expensive to compute (by choosing the desired number of bits of collision), and yet can be verified instantly. This can be used as the basis for an ecash system measured in burnt CPU cycles. Such cash systems can be used to throttle systematic abuses of un-metered internet resources.
Take as an example spam, where a user abuses the un-metered nature of email to send out millions of emails. The most common form of spam is commercial spam, where the user is hoping to make a profit. As the incremental costs of sending more emails to the spammer are almost zero, he can still make a profit even with a success rate of 0.0001 %. The unfortunate side-effect of this is that many people are annoyed by advertisements they are uninterested, and unlikely to be, interested in. Also on a global scale use of bandwidth and CPU resources are wasted. The spam recipients time is wasted as well, and receiving the spam may directly costing the user bandwidth fees from their ISP.
ISP's also dislike spam because it costs them time and money to deal with the complaints, and recover overloaded mail servers that sometimes crash under the load of intensive spamming.
Hash cash is denominated in the bit length of the partial hash collisions. One bit longer is twice as expensive to compute (on average). By choosing an appropriate denomination of hash collision we can create a system of metering which does not pose a problem to the normal sender, but which becomes expensive for large mass mailings.
For example, my workstation is able to test 180,000 hashes per second. A 20 bit hash collision takes on average 6 seconds to produce at this rate. If I am charged by recipients a 20 bit hash for each email I send, I can only usefully send 3750 mails per day.
This should be more than adequate for the normal user, but could easily prevent a spammer breaking even with his low rate of success. This should cause spammers to either give up sending spam, or to work hard on increasing the accuracy of their direct marketing database, either option being is a net positive result.
The recipient's service provider's SMTP server could be modified to discard, or bounce messages with insufficient hash cash. Notification of the amount of hashcash required could be part of the bounce message. Alternatively the user could use the hashcash client as part of incoming mail filtering. If the system administrator, or the user decides that they are still getting spam with the current postage charge, they increase the hashcash charge for receipt.
Hashcash suffers from a high rate of inflation: machines get faster every year. In the longer term it may be necessary to increase the hash collision postage rate by a couple of bits or so a year.
For mailing list servers which have a legitimate need to send many emails (50 messages/ day x 1000 subscribers = 50,000 emails / day) the requirement to include hash cash tokens would become expensive. To solve this problem subscribers should put the mailing list address in a postage-free recipients list.
Other uses of hash cash include charging for use of anonymous remailer resources. For non-replyable remailer services a hash cash token could be included for each hop of the remailer network, or just for the exit hop.
For longer term services such as two way nym-server accounts a larger denomination hash cash token could be used as at account creation to discourage abuse of the nym-server account for spamming. A one off account-creation fee would not be too onerous on normal users, but a spammer would keep getting their account cancelled automatically due to volume, and the cost to keep creating new accounts would be comparitively high.
Traditional payment systems which are traceable are not appropriate where privacy must be maintained at the same time as providing protection from systematic abuse of un-metered resources. There are a few anonymous electronic cash systems (see: refs section on Internet payment systems and protocols).
I am very keen on seeing an anonymous electronic payment system deployed as the main net payment system because of the privacy preserving features.
Ecash support can be combined with the hashcash client, thus providing a smooth migration path to postage denominated in ecash. The client could be set up so that either form of payment form would be accepted. Advantages of this dual currency approach are:
The advantages of ecash, is that it actually compensates the recipient for resources used. For example the operator of a popular remailer can use the revenue generated to upgrade equipment to cope with the overhead. Popular individuals (media-celebrities), or individuals whose time is valuable to themselves can set the postage higher to discourage emails of a trivial nature, or in the extreme case (media celebrities) hire a secretary with the revenues generated to deal with the email, and filter by given criteria.
Other related systems and papers (in order of publication date) are:
Very similar to hashcash also for store-and-forward communications -- was not aware of this publication at time of work on hashcash -- cost functions proposed are different
This is a micro-payment system -- and only related in that involves hash collisions.