A Trial Balloon to Ban Email?

Joseph Ashwood ashwood at msn.com
Wed May 14 16:58:29 PDT 2003


----- Original Message ----- 
From: "Declan McCullagh" <declan at well.com>
Subject:  Re: A Trial Balloon to Ban Email?


> At 09:57 AM 5/14/2003 -0400, Sunder wrote:
[double-spending problem, and associated unacceptable costs]

> It is true that the notions of micropayments as applied to spam (that I'm
> familiar with, at least) would require that the email recipient check with
> the bank to detect doublespending. This would introduce an additional
delay
> before delivery from unknown senders, yes, but I fail to see how it would
> impose an unacceptable cost in bandwidth or CPU usage.

The biggest cost I see isn't in the bandwidth or cpu, the cost I see is in
the memory. First let's look at the load incurred on these systems. For a
single email, the email must be held in RAM for the time necessary to verify
the coin (otherwise double spending occurs, filters fail, etc). Obviously
each of these messages (real or fake doesn't matter) will incur a toll on
the memory of the system. Let's assume for the sake of argument that 1 token
costs 1 second to verify (under heavy loads this would be an expectable
number), this is not the CPU-time necessary, but the roundtrip bank time,
where the token enters a queue on each side and slowly makes it's way
through. So every message must be held an additional 1 second for
verification. Now let's look at the impact this would have on say AOL's mail
system. Estimating that they have 35 million members (I believe this is
close to accurate), each of them receiving on average 16 emails a day, and
each email averaging 100kb (AOL appears to use strictly HTMLified email so
this number is not as off as it sounds), this will result in an additional
load of 663 MB of RAM at the very minimum. Since these emails come in
batches and there is additional overhead beyond simply holding the message
in RAM, what you're looking at is probably approaching 50 GB of RAM, last
time I checked a fully loaded Itanium could handle 68 GB, so this is pushing
dangerously close. Now let's assume something like hat happened at Telewest
over the last week or so happens
(http://www.theregister.co.uk/content/6/30650.html) where an enormous
quantity of email is sent in, brute force style, now you start requiring
increasing amounts of RAM because although you filter as fast as you can,
you can't send out. This places increaseing load on your resources,
enormously accelerated and aggravated by the necessity of verifying each
coin (you can't contact the bank under such load so the round trip time
starts increasing, reaching several minutes, and eventually stops). For all
it matters you could have 0% cpu load during this, the cpu isn't the
problem. The problem is the full incoming pipe, normally this can be dealt
with by spooling to disk, but the necessity of contacting the bank creates a
rippled effect of this. The net result is that a single short-term attack
can conceivably bring down a mailsystem for days. The net effect of this is
that the small spam problem (those companies tht have a small list of people
they occassionally send unwanted mail to) pretty much goes away, the bigger
fish though are unaffected. Personally I don't much mind some of the small
fish, right now I have several unwanted emails from various conference
companies, but I only get 20 a year, that's handlable, but from cypherpunks
alone I received several times that in really dumb ones today. If we can
find a solution to the big problem (which this doesn't solve at all), I
think the little problem won't seem like a problem at all.

> Spammers could still try the same-micropayment-a-million-times route, just
> as they could try to spam without micropayments, but if their email is
> rejected in sufficient quantities, the cost to the spammer would outweigh
> the benefits. The key is achieving sufficient quantities.

I agree, the problem with the proposal is that it very quickly opens the
door to spammers sending "sufficient quantities" to cripple the entire
payment claim system. The net result is that under the best of conditions
the bank is under a sporadic DDoS from people trying to claim tokens before
anyone else, and at worst the bank is fine because no one can speak from all
the spam being shoved in their mouths, crippling the entire system. Doesn't
sound like much of a winning situation for the "good" side.
                Joe





More information about the cypherpunks-legacy mailing list