From: Jason W Solinsky <solman@MIT.EDU>
Date: Fri, 26 Aug 94 04:41:58 PDT
To: Hal <hfinney@shell.portal.com>
Subject: Re: Is pay-per authentication possible absent trust?
In-Reply-To: <199408252046.NAA11580@jobe.shell.portal.com>
Message-ID: <9408261141.AA13815@ua.MIT.EDU>
MIME-Version: 1.0
Content-Type: text/plain


> Jason W Solinsky <solman@MIT.EDU> writes, quoting me:

> >First, just let me note that there are a thousand ways to structure it.
> >In my example, Microsquish gets to hold a challenge whenever they want
> >to. If everybody is being honest Microsquish will lose eight nano-slinkys
> >each time they challenge so they won't do it frequently. If everybody
> >is not being honest, Microsquish will collect substantial damages.
> 
> One thing I'd add is that Charles still makes money whenever there is a
> challenge.  If there were no challenges then there would be nothing to
> keep people honest.  So it's not a matter of eliminating pay per use of
> certifications, it's just a matter of the frequency with which they are
> used vs other kinds.

True, but we desire something that scales linearly with use.

> Also, as the challenges become less frequent, Charles can actually raise
> his rates and still let everyone else make money.  He can even charge
> more than the 10 that Micro is paying for challenges, which he could
> probably not have done in the non-probabilistic (pre-Ingve) system.  It
> sounds like Micro is paying the challenge fees (in at least one version)
> and if the penalties against cheaters are great enough it won't challenge
> very frequently, in which case a larger fee by Charles can be absorbed.

So you are pointing out that Charles has the ability to move the system
towards a one-time fee system. This is true, but the logic in the above
paragraph is tainted by the fact that the insurance company can shift the
payouts so that the frequency of challenges becomes arbitraily small.
Charles becomes unable to properly charge some customers without overcharging
others.
> >Now that I think about it, its possible that I'm in error approaching this
> >problem from a cryptographic standpoint. Maybe the correct course of action
> >is to establish a cybergovernment which prohibits "Ingve the insurance
> >salesman" attacks and then set up the fine structure such that the
> >conspirators will have an enormous incentive to turn each other in.
> 
> These tend to be non-local solutions, with a lot of overhead and extra
> mechanisms. Maybe you can make it work with your "government" but I'm
> afraid you may come to lean on it as the solution to all of your
> problems.  Why bother with cryptography for anything; just have a
> "government" where everybody has posted a ruinous bond which they forfeit
> if they break a "law", then legislate communications privacy, non-
> duplication of electronic cash, bit commitments, etc., with heavy
> incentives for people to report cheaters?

I agree, I only suggested it because it doesn't look likr cryptography
can help me out here.

> Again, though, people could just swear they've seen a Charles certificate
> and these witnesses will undercut Charles.
> 
> As I said, I think there will still be a place for per-use
> certifications, but the market will decide how much they are used vs
> other kinds.  I don't think you should worry so much about trying to fine
> tune the system so this one technology wins.  There are a lot of
> possibilities that people may come up with.

Maybe I'm looking at it wrong. The challenge is to pay the certifier based
on the value he provides. Perhaps in situations like these YOU are providing
the per use value and the service of the certification agency is of the
one-time nature. Suppose you have created a piece of software which is
compatible with system X. You need somebody to certify that compatibility.
Each time you sell a copy of that software you receive a certain amount
extra because its compatibility has been certified, but I could argue that
the extra value is due to the carefulness of the programer and that the
value created by the certifier really is one time.

But what about systems in which selling signatures on a one time basis is
truly critical to operation. Consider the example of a user who is going
to buy a car. This characteristic is worth a lot of money to companies who
sell cars, but they need a way to verify it. I have envisioned (and even
written some code for) agents that would come along and offer gift
certificates good for any car in class X. The gift certificates would sell
below face value. The agent who sells these certificates can then use the
information that it has sold you the certificate to attract advertisers at
a high price. You save the amount by which the gift certificate was
discounted, the agent keeps any money made beyond the discount, and the
advertisers get the attention of a hot prospect. But how could this system
work if pay-per use authentication is not possible?

[now that I think about it, I guess it is possible to contact the
advertisers ahead of time and be promised a bounty for each prospect
found.]

Cheers,

JWS