Re: Voice/Fax Checks

[solman@MIT.EDU]

> 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