From: Adam Back <aba@dcs.ex.ac.uk>
To: kent@songbird.com
Message Hash: 1e8bf278919a9597a5bf73732bf2cde65861c41b7433aec96a53c5149b37e333
Message ID: <199708090914.KAA00770@server.test.net>
Reply To: <19970808165350.55775@bywater.songbird.com>
UTC Datetime: 1997-08-09 16:28:26 UTC
Raw Date: Sun, 10 Aug 1997 00:28:26 +0800
From: Adam Back <aba@dcs.ex.ac.uk>
Date: Sun, 10 Aug 1997 00:28:26 +0800
To: kent@songbird.com
Subject: Re: some hashcash advocacy
In-Reply-To: <19970808165350.55775@bywater.songbird.com>
Message-ID: <199708090914.KAA00770@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain
Kent Crispin <kent@songbird.com> writes:
> On Fri, Aug 08, 1997 at 10:45:29PM +0100, Adam Back wrote:
> [...]
> > I wasn't talking about remailers above, but about end users. Hashcash
> > allows the recipient to filter out email that hasn't got postage.
>
> Ie, hashcash is a fancy techie oriented self-labelling technique. :-)
Yes, if you like. If techie people can make themselves pretty much
immune to spam, perhaps the non-techies will get interested to use our
solution. Make it easy enough to install at ISP level, and interim
migration paths for people without it so it still interoperates, and
you might get somewhere.
All depending on how spammers and hashcash interact when they bump
into it as a major block on their ability to spam. They'll obviously
try their damnest to work around it. But I think that the
inconvenience and cost to them, as hardly anyone ever replies to their
mail (costs are only for first email that isn't replied to), is a much
better spam preventer than the current status quo, which has
practically no protection other than manual blocking lists which
hardly anyone has software installed for, or for complaints to
ISPs... but then the spammers use forged email addresses, and there
are a few ISPs who apparently (from discussion here) are willing to
knowingly sell spammers bandwidth. Someone's going to do it.
> I didn't read the code, but it seems that the double spending
> protection is just local to the recipient (ie, there isn't a trusted
> central clearinghouse that checks against double spending on a global
> basis).
It's supposed to be 100% decentralised -- the network strain on any
kind of centralised clearling house for postage for _all_ email would
be Terrabits/second.
OK, so you might be able to split it up a bit, and have multiple
banks, and inter-bank clearing, and various trade-offs, but it's still
a major engineering effort with large bandwidth overheads.
> Thus, a spammer could calculate postage for a message, then
> send 100000 copies. Hashcash would guarantee that each user only got
> one copy, but there are easier ways to do that.
You missed one aspect of the design. What the collision is calculated
on is the recipients email address. If the collision is on someone
elses email address, you reject it out of hand. So the hashcash
postage token is specificly minted by the sender and made out in the
email address of the individual that you are trying to send email to.
It is useless for sending email to anyone else. You can never spend
it twice on the same person, and sending it to anyone else it will
have zero value.
Also it includes in the hash collision an expiry date when you
generate it, but this is not significant to the email spam control
aspect, but is just there to ensure that the users double spend
database doesn't grow -- you discard expired double spend entries --
as you wouldn't accept them anyway -- because they are out of date.
> [If the checking was done at an ISP level, of course, only one
> message would get through. But that requires widespread deployment
> at the ISP level, not the individual user level, and checking at the
> ISP level requires that the ISP keep a database of users mail
> preferences.]
ISP level checking is nice because you can get away with out changing
email clients. The short term solution of sending nonces will help
provide a reasonable solution for those with out new clients.
> > You could auto-add anyone you ever manually replied to to the
> > no-postage list even.
>
> I would rather pursue a "tit-for-tat" strategy for email, but
> unfortunately tit-for-tat requires stable identities...
tit-for-tat would be reasonable also.
Stable identities already have advantages... you can block remailers
etc.
Stable identities could include signed documents.
[btw: Kent: I tried out your .midi file under win95, all I had to do
was double click on it. Almost melodic in an weird modern sort of
way. Most cool anyway :-]
Adam
--
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/
print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
Return to August 1997
Return to “Tim May <tcmay@got.net>”