On Sat, 22 Mar 2003 16:43:17 -0700 (MST), Vernon Schryver
<vjs(_at_)calcite(_dot_)rhyolite(_dot_)com> writes:
From: Scott A Crosby <scrosby(_at_)cs(_dot_)rice(_dot_)edu>
...
A shiny new 3ghz system amortized at $1000/year over 3 years amortizes
to $3/day, and is good for 300,000 ghz seconds/day. At a 1ghz*second
of minting cost, the amortized cost per message is 100,000/$1. The
spamvertizing costs are $100 buys a million? Thats $.0001/message, or
ten times the costs to the spammer from minting. Even a minting cost
of 60 ghz*seconds would only increase the cost to $600/million. Worse,
Moore's law will eat into these costs by a factor of 8 over the next 5
years.
Thus, I think we'd need on the order of *AT LEAST* 10 ghz*minutes of
hashcash to make spamming unaffordable, and perhaps 100 ghz minutes 5
years down the line. IMO, would 10 ghz*minutes of CPU to mint just one
stamp makes it impractical to expect a mail gateway to mint hashcash
style stamps?
...
What is the minimumm speed CPU that you will allow to send mail? A
25 MHz 486 is at least 200 and perhaps 500 or 1000 times slower than
a 3 GHz P4. A 25 MHz 486 needs several minutes to generate 60
About 7 hours to compute a partial collision stamp. But, if the sender
already has a valid stamp (previously sent to them by the recipient),
they may use it with no computations. Recipients can compute
nonce-stamps at zero cost. Thus the 600ghz*seconds of CPU would only
be spent on new senders.
In any case, unless the cost is at least 60ghz seconds, and preferably
600ghz seconds, it is insufficient to make spam signifigantly more
expensive.
GHz*seconds of hashcash. You might fix the problem for mailing lists
by somehow letting one coin work on many copies with some kind of
authentication (from crypto to envelope Mail_From) and authorization
from whitelisting on. It is unrealistic to hope that users would
stand for a mail protocol that limits them 1 one mail message afer
several minutes of hard computing. It is insane to expect ISPs to
force their customers to get new computers or tolerate such delays.
Please reread the proposal, it has none of these properties.
Scott
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg