Re: Voice/Fax Checks

Robert Hettinga writes:

>As someone who's been thrashing this a little bit, I've gotten stuck on
>exactly how to "*undercut*" the transaction costs of existing methods.  Got
>any ideas?  Are those transaction costs as a percentage of total cost
>meaningful enough to embue digital cash with the rocket-like competitive
>advantage we hope for?

It's pretty clear that credit cards don't work for some of the transactions
people want to do:

1) one-cent and fractional-cent charges for connecting to a useful Web
page or ftp site.  A useful resource like this wouldn't have to charge much
on a per-user basis to fund the equipment and people.

2) Transactions with individuals or small companies who are not VISA clients.
It's not that easy for a mail-order shoestring startup to get the ability to
accept VISA cards.  Because of the danger of fraud, the credit card companies
like to see a storefront and/or some previous history.  Someone who writes a
nifty PGP shell and wants to sell it for $10 per will have this problem.

3) People who don't like giving out their credit card numbers to an unknown
email address.  This is the flip side of the above.  The danger of fraud is
always present, and the more people I've given my card number to, the more
chance that I'll get burned.  Of course most states have protection laws in
place, but it's still going to be a major hassle.

Now, 2 and 3 can probably be addressed by electronic checks, and I think the
secure Mosaic announcement included that possibility.  I suspect that echecks
are a considerably stronger competitor to ecash than today's credit-card
infrastructure.  For one thing, an echeck can be sent in the clear, while
ecash has to be sent encrypted; an eavesdropper can spend ecash but not an
echeck.

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.

>Light dawns on Marblehead. (Massachusetts joke).  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 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.

Hal

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

-----BEGIN PGP SIGNED MESSAGE-----

In list.cypherpunks, solman@MIT.EDU writes:

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

I'm not clear on this point.  Is this an audit trail built into the
e-cash?  I'm not so sure that's a Good Thing.
- -- 
Roy M. Silvernail  []  roy@sendai.cybrspc.mn.org

                          It's just this little chromium switch.......

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAwUBLjBYHRvikii9febJAQHbzAP7BtK0oS6oO78/J9781IyA5mQQv7Jjl1SP
D/M8pLSHco4q6OhHHEa2qLUOzMeh2v1CArFvXjZjx2Yg3AmmWCR3E0prCO0ZgQmh
iPOttdfue4W788rwpBtHVkOBPUjf5ilB7aifWXYxTgzwbGotbjILtBnvUvcQPSzi
+UYOmErloEY=
=e8lz
-----END PGP SIGNATURE-----

> -----BEGIN PGP SIGNED MESSAGE-----
> 
> In list.cypherpunks, solman@MIT.EDU writes:
> 
> > 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).
> 
> I'm not clear on this point.  Is this an audit trail built into the
> e-cash?  I'm not so sure that's a Good Thing.

When properly implemented, nobody can deduce anything from the "audit trail"
other than the validity of the e-cash. If somebody cheats, only the cheater
(and people who reuse his money without checking first) is revealed. I should
note that the Japanese system that I started with does not quite cut it in
this reguard. A tiny bit of probabilistic encryption goes a long way
towards imporving their system. (Vendors and banks could otherwise deduce
things when they saw the same license).

On a more important note, I believe that in one of the papers on my to-read
list for this weeked, Chaum demonstrates that e-cash can not be transferable
unless it grows bigger. Otherwise you have to give it back to the bank and
get a new one each time it is used. Given this, I think that it is highly
desireable for us to accept the increasing size of the e-cash and maintain
its transferability.

JWS