[hashcash] Re: Speed problem with 1.03 on Mac G4
- From: Jonathan Morton <chromi@xxxxxxxxxxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Tue, 24 Aug 2004 12:01:51 +0100
Does using 2 threads translate directly to (2 * 9,000,000) collision
detections per second?
Yes, assuming the system is otherwise lightly loaded.
So assuming the initial postage rate is 24 bits. A spammer sitting in a
room with a stack of 10 Xserves can generate 864,000 stamps per day (I
doubt he'd need a sys admin for a setup like that, he could probably
fit
the servers in his bedroom!)
Yes, an Xserve is an impressively compact and powerful piece of kit.
It also happens to cost upwards of $2000, so it's a significant
investment for a spammer to make - it'll raise the bar at least a bit.
But, let's assume the worst-case scenario, which is that a prolific and
thus well-funded spammer has made this investment in a rack of 10
Xserves. In that case, a "limit" of ~900K mails a day is still a
pretty large figure, and is unlikely to affect his operations too
badly. If anything, he might have to charge a little more per message
to remain profitable, but it's still a pretty small cost from the
spammer's client's point of view.
A similar argument applies to the zombie armies that organised spammer
rings now employ. These machines are, individually, considerably less
capable than the Xserve, typically having only one CPU and being from
the x86 family. Let's say, on average, 2 million collisions a second
per zombie, considering they might not be switched on 24/7 and will be
in use by the legitimate user as well. That is, however, still a
24-bit stamp in under 10 seconds on average, or about 9000 mails a day.
Multiply that by even a thousand active zombies, and you have a big
problem.
So clearly 24 bits is, really, still too low. But how can we make a
larger bit count acceptable for general users?
24 bits would still slow him down. But any less and he's back up to his
old spamming volumes (20 or 21 bits are out of the question running on
that sort of hardware)
Yes. That's partly why I grabbed these figures, so that we know what
we could be up against. Bear in mind that the Xserve is probably the
most cost-effective hashcash platform available today - while larger
multi-CPU workstations could achieve higher performance, the cost of
these is prohibitive, especially as the CPUs used in most of these lack
the highly efficient vector unit of the G5.
To me, this seems like a pretty good case for *large* hashcash stamps
combined with a strongish signature/whitelist system. I've already
described, in outline, how such a system could be designed, though some
of the details could stand to be tweaked given recent data. Large
stamps (over 26 bits, possibly as high as 30) would impact spammers'
operations even if they invested in a pile of high-end kit, as they'd
be unable to forge whitelisted signatures in large quantities.
The signatures, meanwhile, ensure that most users rarely need to
produce such large stamps themselves. This could also begin to make
RPOW more viable for general use, although something tells me it still
won't scale to global proportions. However, use of RPOW would in turn
further reduce the need for end-users to generate stamps, which is
particularly important to users of old machines.
If this seems interesting, I'll dig out the old posts and distill their
ideas into something more concise and relevant for this month's level
of knowledge.
--------------------------------------------------------------
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:
