[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:
