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@metzdowd.com