[hashcash] Re: status of hashcash version 1?
- From: Jonathan Morton <chromi@xxxxxxxxxxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Sun, 22 Aug 2004 18:40:52 +0100
Benchmark your own CPU, then accept cash for anything that takes more
than n seconds on your CPU. Generate cash that takes n*k seconds.
This naturally evolves to take account of improved speeds _and_
variance without tweaking being required after setting an initial
value (though the owner of a very fast CPU might have to downgrade
the default n, and a very slow CPU upgrade k).
Seems like a good idea. It'd work best for the 99% of users who have
access to a machine within the newest few generations, and the rest can
use a manual or alternative mechanism. At the moment, I think K should
probably be about 20 - this allows all but the newest and most
optimised machines to accept default tokens generated by my 200MHz
Pentium-MMX.
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.
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. For example, the Altivec cores running on a G4 are each
about 4 times the speed of the best scalar core running on an
equivalent G3. The MMX core running on a P4 is about twice the speed
of the scalar cores running on the same processor, and a similar
improvement over MMX may be possible for an SSE2 core.
This factor skews the value of K needed rather badly. However, it is
probably still useful as a first approximation, especially if no other
source of information is readily available.
this implies that there is some form of feedback mechanism telling
the sender that they need to increase their postage. Otherwise it
just falls into the spamtrap.
This is a general problem, surely? I'm trying to avoid having to give
feedback very often, but surely never is an impossible goal.
Agreed, a realtime feedback mechanism of some sort is generally wanted.
Otherwise, people would (gradually but completely) stop being able to
use their old 486s as firewalls and personal servers, as the state of
the art advanced. A feedback mechanism would allow these old machines
to (eventually) produce the correct credentials. Suggestions on how to
do this properly are welcomed.
OTOH, it's just as valid to treat hashcash as a "score modifying"
property. A whitelisted signature is the only thing that should cause
a complete bypass of the content filters (in eg. SpamAssassin). Higher
hashcash values cause more score lowering, the precise extent depending
on the local benchmark, or on regular updates to the spam filter
itself.
--------------------------------------------------------------
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: