No free spam

[Ben Laurie]

Amir Herzberg wrote:
> 
> Ben responded to me thus:
> 
> > > This takes care reasonably well of peer to peer e-mail (I think), and
> can be
> > > easily deployed (any volunteers? I'll be very glad to provide our system
> for
> > > this !).
> >
> > Sure. Is it something I can actually deploy (without everyone else in
> > the world also deploying it)?
> 
> You can certainly deploy our system, as well as several others, e.g. one
> response mentioned correctly MojoNation (of course there are plenty of
> reasons to choose ours :-).
> 
> I was puzzled by your saying `without everyone else in the world also
> deploying it`. I thought you meant that you are concerned that others will
> use it, making your deployment redundant or not commercial etc. Now when
> writing this to you I realize I stupidly misunderstood you. What you meant,
> I'm quite sure now, if that you are concerned that if you implement such a
> payment solutions others will not be able to mail you since they don't have
> it. Now that's a very valid concern and I also thought for a long time it
> may be a show stopper.

Actually, I was more concerned with the other side of the coin: that
insufficient people will adopt it to make it worth doing, and that it is
hard to find ways to give people an incentive to start using it.

> But now I actually think it could work. Let me explain how. The key is the
> belief that micropayment systems MUST emerge - and be interoperable. That is
> a payer with account at one Payment Service Provider (PSP) should be able to
> pay anybody with account at any PSP. That's certainly our goal - our system
> has this property and we plan to work closely with any other vendor which
> will want to have this property to ensure interoperability.
> 
> Assuming this, the problem is only the bootstapping phase, before everybody
> has accounts in interoperable PSPs. But in that phase when the system is not
> yet so widely used, it will be sufficient to force the sender to simply do
> some manual process - such as enter a web site to open a demo account and
> pay. That's clearly something achievable with our system or others. If it
> becomes popular, spammers may develop automated tools to do so as well, but
> that will buy them very little as at that point the system will be popular
> enough to move to real payments.
> 
> BTW, I've been thinking of payments as the answer to spamming already for
> many years, and in fact it was one of my motivations for working on
> micropayments (from which our broader
> payment platform emerged). There are others who thought of it long ago, in
> particular Kevin Mccurly (see
> http://www.almaden.ibm.com/cs/k53/pmail/tsld001.htm).

I actually favour Adam Back's hashcash scheme for this particular
problem, even though I'm as keen as you are to see micropayments succeed
for other things.

This is particularly related to the incentive problem - I think it will
be difficult to persuade people to voluntarily adopt a system that is
likely to make what is now free cost money. Hashcash has the advantage
that it costs nothing (in practice) but still has the property of making
spam uneconomic (which, when you think about it, is a very cool trick).

In fact, in a conversation just now with Russ Nelson, I came up with
what I think is probably the best idea I've had yet on how to get this
scheme off the ground - what we do is get people to run hashcash on
their mail servers, and prioritise mail that arrives properly paid for -
also, autorespond periodically (in the style of vacation) to those who
do _not_ use hashcash urging them to start and pointing them at the
appropriate patches for the major mailer apps (of course, the endgame is
to get the major apps to include the patches by default). When it gets
popular enough, we just throw the switch and start bouncing mail that
has no hashcash. I even thought of a name for this scheme - CAMRAM (the
CAMpaign for ReAl Mail[1]).

I really think this could work, so I'm prepared to spend time on it -
who's in? (mail me privately)

> Another BTW, the other application I really want micropayments for (and was
> my first motivation to this if I recall correctly) is also crypto-related...
> it is to motivate people to produce reviews of products, services, and esp.
> other reviewers - creating a huge `web` (or directed graph) of credentials.
> If these are signed, and identify the reviewed entity by its public key,
> these credentials are certificates. Using such a collection of many
> credentials is what I believe will be the ultimate solution to public key
> infrastructure - and this is another area I'm very interested in (and worked
> on).

I hear what you are saying, but I really don't see how this produces the
ultimate solution to PKI - unless you envisage the huge web boiling down
to a few very large players that I subcontract my ID requirements to. In
which case, I'm not keen.

Cheers,

Ben.

[1] That's a joke, based on CAMRA, the CAMpaign for Real Ale.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com