Of course, it still suffers from the usual problems endemic to all
hashcash, notably the very wide variety in CPU speeds out there.
J. Random Hacker in Outer Slobbovia running on a half-lung salvaged
68020 will be utterly blocked by hashcash values high enough to be
even
noticed by Evil Q. Spammer's late-model 8-CPU 18GHz Hexium.
One response to this has been to try to design functions that are
less dependent on processing power and more dependent on stuff
that's less variable.
That said, I seem to remember hearing that there have been
problems with these functions, though I don't track the
field that carefully...
The main one I remember (offhand) is something using memory bandwidth
rather than core. The problem with that is anything with a large
enough working set to swamp the 2MB and 4MB on-die caches that are now
appearing, will simply not run on my Mac IIcx with only 8MB *total*
RAM.
And the spammers can always splurge for a big IBM POWER5 workstation
with 8MB on-module L2 cache (4 dies per module, 2MB per die) and insane
amounts of L3 cache.
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: chromi(_at_)chromatix(_dot_)demon(_dot_)co(_dot_)uk
website: http://www.chromatix.uklinux.net/
tagline: The key to knowledge is not to rely on people to teach you it.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg