Re: Voice/Fax Checks

JWS writes:

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

>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.
>[...]
>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.

This seems like a good approach for a lot of cases.  You end up having
three classes of transactions: small, medium, and large, with slightly
different strategies for each.  For large, you do on-line checking; for
medium, you detect double-spending after the fact and use crypto to find
his identity; and for small you set up an account and dip into that a bit
at a time.  I am curious about whether you are focussing more on some size range
in your plans.

One problem I still see is the small transaction where you don't tend to
use the same provider again and again.  On the net there are a few sites
(well, quite a few, I suppose) which are heavily used, but there are a
lot of places I might like to just browse through.  Paying a penny per
site isn't going to bother me much, but if I have to set up an account
for each one ahead of time I'm probably not going to bother.  So I still
think there are problems with the fractional-cent-per-web-site model
which I have been hearing about.

>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.

Is this an approach where you determine to whom you will be sending the cash,
then make it into a "check" which can only be spent by that recipient?
Doesn't that require the bank's (cash issuer's) help?  Or is this something
else?

Hal

> This seems like a good approach for a lot of cases.  You end up having
> three classes of transactions: small, medium, and large, with slightly
> different strategies for each.  For large, you do on-line checking; for
> medium, you detect double-spending after the fact and use crypto to find
> his identity; and for small you set up an account and dip into that a bit
> at a time.  I am curious about whether you are focussing more on some size
> range in your plans.

Well I've only got small implemented right now, so I guess that's where
things are focused now. Whether there is more medium or large depends on
how comfortable vendors feel with their customers. I imagine that
certification agencies will develope using my primitives, that will
certify (by betting money on it) that certain people are likely not trying
to double spend. Economics will sort things out. People will chose
whatever form makes them the most money.

> One problem I still see is the small transaction where you don't tend to
> use the same provider again and again.  On the net there are a few sites
> (well, quite a few, I suppose) which are heavily used, but there are a
> lot of places I might like to just browse through.  Paying a penny per
> site isn't going to bother me much, but if I have to set up an account
> for each one ahead of time I'm probably not going to bother.  So I still
> think there are problems with the fractional-cent-per-web-site model
> which I have been hearing about.

Well, I'm expecting a major shift in how people view transactions once the
agents are available to obscure the details. The account based money is
intended to support a market based system whereby competing bits of
information and advertisements vie for the user's attention. In this sort
of system there are LOTS of tiny transactions on one system. Also, I don't
expect the large scale money transactions to wind up costing more than
a penny or less after everything is set up. The problem is that initially
there will be few transactions to amortize processing and communications
costs over. When there are large numbers of transactions occuring, even the
medium/large scale transactions will be cheap.

> >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.
> 
> Is this an approach where you determine to whom you will be sending the cash,
> then make it into a "check" which can only be spent by that recipient?
> Doesn't that require the bank's (cash issuer's) help?  Or is this something
> else?

In systems like this, a bank initially issues the user a license. The bank
verifies the identity of the user and issues him a license authenticated
by the bank in a manner that prevents the bank from knowing which license
the user got... unless the user cheats at a latter time in which case the
vendor which knows the license and the bank which knows the ID will each
find out the other and track down the user. Okamoto and Ohta proposed a
centralized one of these in Crypto '91. I'm using some results from
papers on minimalist and dynamic hashing functions (two groups that
do not normally get along well) to create a truly distributed analog to
this system.

JWS

This seems like a good approach for a lot of cases.  You end up having
   three classes of transactions: small, medium, and large, with slightly
   different strategies for each.

There are more categories than these, actually.  There's already a
banking distinction between large and very large.  One of the high end
funds transfer systems in the world has a _minimum_ transaction size
of about two million dollars.  You can bet that these are handled
differently than a one thousand dollar check (still "large").

In addition to direct costs of provision, there are also effective
costs of collection risk.  At each level, these collection risks have
to be estimated and taken into account.  Since the real desire is for
a known upper bound, some fraud or other form of transaction failure
can be expected.

When credit is being offered (even intra-day), the risk increases
proportionally.  Every off-line system offers some amount of credit,
however small.

   Paying a penny per
   site isn't going to bother me much, but if I have to set up an account
   for each one ahead of time I'm probably not going to bother.  

You can still use an account mechanism, but with an intermediary whose
business it is to aggregate small amounts as these proposed and clear
the total periodically.  That's now one account setup for the
customer.

Eric