[hashcash] Re: status of hashcash version 1?

  • From: Jonathan Morton <chromi@xxxxxxxxxxxxxxxxxxxxx>
  • To: hashcash@xxxxxxxxxxxxx
  • Date: Sun, 22 Aug 2004 22:31:11 +0100

If N is about 1, however, my TiBook and Athlons would require approximately 22-bit tokens, and would generate 26 or 27-bit tokens (taking 20 seconds over it on average). This seems a bit higher than the previous recommendation.

If I could remember the URL, I'd point you to my paper with Richard Clayton on the economics of spam. In short, 20 seconds is low.

I disagree. What we want to do is reduce the spammers' output. At the moment they can send as fast as their upstream bandwidth allows. Compared to that, spending even 1 second of CPU time per mail is painfully slow.

Now, 20 seconds is still (just about) acceptable to most users' perceptions, especially if the calculation is overlapped with their actually typing the message. Much more than that will cause hashcash to not get adopted, and is probably overkill anyway.

A minor problem with this approach is that newer processors are not just faster in general, they are frequently also capable of optimisations which boost their performance manifold over the previous generation.

Yeah, I'm leaning towards memory based proof of work for this and other reasons.

Sorry, but memory-based PoW is even worse from this perspective. Sure, when you look at the raw "main memory latency" stats for a 1986 machine compared to today's, there isn't really all that much difference (typically 100ns uncached FPM, versus 50ns measured latency for an Athlon-64). But a 1986 machine probably has less total RAM than some modern workstations have as *cache* - and that cache will be a great deal faster than the main memory.

This came to light when someone suggested a Dworkian algorithm based on a modified RC4 and a 16MB array. Such an algorithm, unlike hashcash, would be *impossible* to run on my Mac IIcx (circa 1988), which is similar to machines handed out to disadvantaged folk quite recently in the American desert.

Yet workstations are now, or will soon be, available which have a total cache size large enough to provide a substantial performance boost with a 16MB random-access working set - a boost which would not be available with hashcash. Furthermore, it would be ridiculously easy to build a dedicated machine using SRAM or fast graphics memory, which would also have a substantial advantage.

Then, unlike hashcash, the size of the array cannot be smoothly evolved upwards to cope with increasing capabilities. It also bloats the download sizes and memory requirements of all applications that use it. This Mac IIcx only has 40MB of disk space, total - would a typical user of such a machine want to spend 40% of their disk space on a new e-mail program? No, I didn't think so.

from:     Jonathan "Chromatix" Morton
mail:     chromi@xxxxxxxxxxxxxxxxxxxxx
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.

Other related posts: