deterring coin re-use with offline coins (Re: A Trial Balloon to Ban Email?)

Adam Back adam at cypherspace.org
Thu May 15 01:41:32 EDT 2003


Sunder wrote:
[...spammer sends 170k mails all with same micropayment coin...]
> Each time this happens - (from my point of view I get about 50-60
> spams/day that I filter) each of those recipients turns around and sends
> some traffic attempting to auth the micropayments via the micropayment
> bank.  That's a DDoS from the point of view of the bank.  
> 
> Even if it can handle the traffic it has to do lots of CPU intensive work
> and send the error back to each of those requests, which will result in
> rejection of 169,999 requests and 1 acceptance (assuming the spammer is
> using a valid coin in the 1st place.)  It becomes expensive to run the
> mint.

and Declan wrote:
| 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.

So I'm not sure if you'd want to do it, and it has other issues
discussed on cpunks recently, but there are some other options here
with ecash that can avoid the bank having to say "already spent"
169,999 times for each valid but already spent coin.  (I concur with
Sunder that if the bank had to fit such usage patterns into their
business model, it would increase ther costs significantly which would
make running the bank even harder to do and still turn a profit,
especially as we are talking very high volume, and exceedingly low
value tokens.)

One assumption I'm making is presumably the micropayment system
provides the option for payer and payee anonymity, or email privacy
just got removed once and for all.  (Trace the payments at the bank
and you know who emailed who in a convenient central database - a
definite privacy no-no).

So with the offline brands protocol of which there was some discussion
recently, the MTA could verify the coin locally.  It would be assured
that if the coin was locally verified as valid, he either gets the
money later when he deposits, or the bank gets the spammers identity
and prosecutes them for payment fraud.

So (and this is why I said I don't know if you would want to do
this...) this payment choice where identity is revealed iff you
double-spend has the recently discussed issue:

A) you have to provide your identity in the first place, and if having
it revealed is any deterrent, you'd better be identified robustly
(doing this identification for every email user on the planet seems a
somewhat daunting task)

B) the spammer will have an incentive to find a way to provide fake
identity to the bank, or of buying someone else's identification
(eg. someone with no credit rating, or of stealing someone else's
tokens, or stealing someone else's mail services which automatically
add a payment (identifying them) on event of double spend


But aside from those issues (plus the showstopper issue of building a
payment infrastructure to support this volume in the first place which
was discussed earlier in this thread) this now gives the MTA the
ability to reject double-spends locally -- modulo the amount of
deterrent to double-spending anyway and being identified ends up
providing after the spammers have finished attacking issue B).

A remaining technical issue would be the MTA could have it's CPU
overloaded as verifying such tokens is while relatively cheap (I think
around DSA signature verification cost) still much more expensive than
it is for the DoS spammer to send you plausibly formatted random
numbers to burn off your CPU.  But we have a separate solution to
that: you make the spammer provide a hashcash token of comparable cost
to that verification and this can be verified an one order of
magnitude or more efficiently and increases the would-be DoSers costs
to be comparable to the signature verification.  (Or more if you wish
-- legitimate mail users usually don't need to send 200 mails/sec).

Sunder wrote:
> From my point of view, if my MTA has already spooled the spam, I've
> already lost my bandwidth, and thus lost some value.  Doesn't matter
> that I never see the spam.  Bandwidth was already wasted receiving
> bits that wind up in /dev/null and cpu cycles to make the decision
> to drop said bits.

Well in some cases I guess the ISP lost the bandwidth (depending on
where you do your checking).  But anyway personally I'd be more than
happy to double by bandwidth consumption to receiving email to avoid
any spam arriving in my mailbox.  (As an individuals bandwidth
consumption sending and receiving email is typically rather low, and
entirely feasible over perhaps 15 minutes of dialup per day).

Or at least to the end-user the human attention costs of spam are
vastly in excess of the bandwidth costs of spam.  ISPs I suspect have
a different perspective: while they have some human costs -- dealing
with complaints and manually throttling debilitating spam floods --
the users inconvenience at having to sort spam from non-spam is not
directly their problem, other than in perhaps a competitive advantage
if users will switch ISPs to use one which offers better anti-spam
options.

Sunder also wrote:
> The current cost to the spammer is currently nearly zero.  To add
> hash generation for each email might slow things down a bit, but
> throwing more hardware at it gets around this.  Hardware is cheap,
> and old out of date PC's are plentiful.  The bandwidth cost is the
> same, the CPU cost and time is a bit higher, but not much.

I presume this comment is about hashcash or variants rather than about
ecash which the rest of the post was about.  Hardware is cheap, but 1
sec of CPU per sent mail on a 1Ghz machine still ends up costing by my
estimates (see thread with Subject: economics of spam) about a factor
of 30 more for the spammer.  Note old machines are cheaper but they
are also slower; the spammer would want to buy the best value for
money hardware factoring in electricty costs (old slow machines don't
necessarily consume less electricity, and electricity is around the
same cost as the amortized cost of ownership of the machine).

Adam

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list