From: solman@MIT.EDU
Date: Fri, 22 Jul 94 10:09:44 PDT
To: hfinney@shell.portal.com
Subject: Re: Voice/Fax Checks
In-Reply-To: <199407221554.IAA02325@jobe.shell.portal.com>
Message-ID: <9407221709.AA15468@ua.MIT.EDU>
MIME-Version: 1.0
Content-Type: text/plain


Well here are the answers that I'm working with in my model:

> Example 1, the fractional-cent transaction, will be tough to address by any
> technology IMO.  Even with ecash, there are a lot of questions.  Is it on-
> line or off-line? Does the server actually try to validate each half-cent
> or does it just trust people?  If the latter, how much fraud is likely, and
> how would we track down and penalize the half-cent counterfeiters?  Solving
> these problems is going to add overhead which will make it hard to deal with
> such small sums efficiently.  How many cash businesses sell low-value items
> for pennies today?  Not many.

First, what you set up has to work off-line. At the same time, validation,
by its very nature, is a process that can only be accomplished online. The
part of my code that I am in the middle of right now (and strugling with)
uses a distributed dynamic hashing scheme (with some attempt at periodic
space minimalization [this is what is making it tricky]) whereby information
is recorded in the public system such that if one part of a bill is used
twice, the cheat's identity is revealed. If two people try to record the
same payment, the person who records it first (according to a distributed
byzantine agreement algorithm) gets the money. Now if its a small amount,
you can feel comfortable dealing with it off-line. If its a large amount,
you want to hold off closing the transaction until you get confirmation
that the payment which you recorded has been accepted by the majority as
the first. Clearly this is not at all simple, but it is provably do-able.
And its my attempt to do this that led me to join this list (although
the complex parts have turned out to be dealing with the perfect hashing
that makes things scalable and not cryptography.)

For types of small transactions that will be executed frequently, the
best idea is to establish accounts. In my system, when ever an agent
enters somebody else's computer, it gives the local wizard (the agent
with the final say on computational cycles, storage space, and
communications) a deposit which neither the agent nor the wizard can
cash without agreement by both [do public validation and recording
but hold off on the last steps which allow the wizard to use the money].
The money is thus recorded globally as having been spoken for. Then, for
all transactions on the local machine, the agent simply uses its local
account, just as anybody would in a much simpler bank-based protocol,
like the ones we have now.

So effectively, tiny transactions are taken care of differently (although
there is no reason why this has to be the case other than efficiency [you
actually have to pay the global community for validating everything so
it is simply cheaper to use account based ecash]).

> >Isn't the point of
> >digital cash that you *can* send it through unsecure mail and buy things?

> No, I don't think you can.  Ecash can generally be cashed by the bearer
> so it has to be sent through secure mail.  That is why I was saying that
> echecks might be better for those purposes.

I don't agree on this point. I prefer license based e-cash which is modified
on each transaction (and unfortunatelly gets slightly bigger -- the downside
of this method). If we're going to make the conversion to ecash, we might
as well make it as powerful as mathematics will allow.

> I don't understand the Telescript agent world well enough to judge whether
> it would drive a market for ecash.  I have the impression that at least with
> the initial implementations the agents will not be on the Internet as we
> know it but rather on a separate AT&T network of special servers.  So they
> may not have much impact for a while on the "net" as we know it.

Where can I find information about telescript?

JWS