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. 170,000 email addresses is what one CD offered. Assume that spammer bob sends emails to that many from lots of servers, say it takes one or two hours. Most spams are small, some are over 20-30K (gif attachments, and other crap.) 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. The 1st time a significant number of users start using this scheme, the spammers will adapt to get around to it. Just like they've already adapted against keyword searches by using text such as e'n'l'ar'g'e' 'y,o,u,r, `pe`n`i`s__n_o_w. Again, from the spammer's point of view, they don't necessarily care that you recieved the email. They sell advertisements for a price. Say you have an ad, you go to the spammer, he spams 170,000 emails with it for $10. He doesn't give a shit if less than 1% of those will get the spam - he charges his client the same. Say, things get harder and he has to adapt, well, he'll just charge his clients more for the trouble and advertise it as a value add that it's garanteed that x% will be read (never mind that idiot client hasn't got a way to prove it one way or another.) You have to think about it from their point of view to find out what they could do to get around it. Then you have to think about it from the bank or mint's point of view, and the traffic and CPU operations, it will have to deal with. Does this solution make it exponentially harder for spammer to deliver the spam? Does this incur cost to the recipient? Does it incur cost to the mint? and so on. Looking at this problem from the spam recipient's point of view isn't enough.
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.
----------------------Kaos-Keraunos-Kybernetos--------------------------- + ^ + :25Kliters anthrax, 38K liters botulinum toxin, 500 tons of /|\ \|/ :sarin, mustard and VX gas, mobile bio-weapons labs, nukular /\|/\ <--*-->:weapons.. Reasons for war on Iraq - GWB 2003-01-28 speech. \/|\/ /|\ :Found to date: 0. Cost of war: $800,000,000,000 USD. \|/ + v + : The look on Sadam's face - priceless! --------_sunder_@_sunder_._net_------- http://www.sunder.net ------------ On Wed, 14 May 2003, Declan McCullagh 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.
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.