Re: [Asrg] hashcash, was My take on e-postage

> > > So, OK, this is definitely going to turn off the non-hardcore 
> > > spammers.
> > > Those that are left will be the ones to send the law after.  Theft of
> > > service and computer intrusion on this kind of scale is a crime, no
> > > matter whether the actual spam is.
> > What you also have to factor here is how much money will be saved in
> > order to produce this reduction versus the costs required to convert
> > everybody to hashcash.
Implementation costs are pretty low - a small plugin or extra feature 
in each popular MUA, plus possibly a verifier in the MTA or MDA chain.  
Aunt Tillie's prehistoric Mac is taken care of by a plugin for Eudora 
v3, for example.  Low-power mobile devices may have a problem 
generating hashcash themselves, but their upstream provider may be able 
to do it for them, especially if they already charge (however 
indirectly) for e-mail.
There's an education cost to get users to adopt it, but this should be 
minimal compared to many other schemes.  Once the plugin/feature is 
installed, it should be possible to make both the hashcash generation 
and signature transparent to the user, except for the processing 
latency.
Whitelisting can be ignored for truly novice users, but should be easy 
to teach to most, and will improve efficiency.  Subscription to mailing 
lists and use of e-mail forwarding boxes will require adding acceptable 
"to" addresses to an internal list, which will be an interesting 
user-interface problem, but not insurmountable.
Running costs are a certain amount of CPU time on the sender side, when 
sending to a recipient who hasn't whitelisted them yet.
> You also need to factor in the ongoing costs to update the hashcash
> mechanism.
>
> You may need to either increase the number of bits collided, as generic
> hardware capability vs cost increases, or replace the scheme, if the
> hashing algorithm is broken, or specialized hardware is built.
If specialised hardware is built for one hash algorithm, it will be 
built for whatever other hash we migrate to as well, so unless the hash 
is actually cracked, we don't need to worry about changing it.  The 
solution in the case of hardware acceleration being built is to move to 
a higher bit count, and start getting Taiwan to make cheap hash 
coprocessors so that ordinary users keep up with the spammers.
Many users won't actually need the coprocessors, because they'll 
already have adequate mutual whitelists (so that hashcash is rarely 
needed) and/or decently powerful computers (which can generate even 
high values of hashcash in a reasonable time).  Users who must contact 
strangers on a regular basis, such as sales and customer service 
departments, will benefit from the coprocessors.
In this ecology, is there a place for paid-for e-stamps?  Yes there is, 
in one form or another.  How about if an "e-stamp" is nothing more than 
a hashcash token generated by a third party, to the sender's 
specifications on the sender's payment?  That way, verification is no 
harder than for hashcash (ie. almost trivial), there's no need for 
inter-vendor settlements, there's almost no barrier to entry for 
vendors and there's no limit to scaling.  It also means that hashcash 
becomes available to all, no matter what their hardware.
The vendors are also in a good position to upgrade to coprocessor 
hardware, if and when it becomes necessary - which might, for 
particularly successful vendors, be before the spammers complete 
*their* prototype.  It means Aunt Tillie doesn't need to find and buy a 
coprocessor for her Mac IIcx in order to file her tax return on time, 
or join a gardening discussion list.
A popular argument as to why e-postage requires a micropayment system 
is that the money should go to the recipient.  I don't think the money 
needs to go that far - just the value.  We value having a nice, clean 
inbox - isn't that enough?
--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi(_at_)chromatix(_dot_)demon(_dot_)co(_dot_)uk
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg