From: hfinney@shell.portal.com
Date: Sun, 7 Nov 93 11:12:53 PST
To: cypherpunks@toad.com
Subject: Real-world digicash
Message-ID: <9311071909.AA04142@jobe.shell.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


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

I agree with Mike Ingle's points re NetCash.  I had some pretty strong
criticisms of their proposal when it first came out.  They didn't seem
too familiar with the literature on digital cash.  Their system was more
like cashier's checks than cash.  The anonymity was not strong.

Nick has some interesting ideas re the use of "reputation capital" to
discourage double-spending of dcash.  You wouldn't want to destroy your
reputation by cheating on a small sum of money, not if the reputation
was one which you had built up over a period of time.

In considering these ideas, there are a lot of questions about the
whole infrastructure in which the dcash is being used.  Is this something
which we would see occuring in the near future, the next couple of years,
in which case current systems of electronic communication would be used?
In that case, we might imagine people purchasing items via the more
progressive on-line services, like the new MUD-based systems people
are working on (metaverse, virtual city, ...).  Or companies might simply
advertise items for sale on the internet and accept orders by email or
perhaps TCP connection.

One technical detail is that dcash systems require a multi-step protocol
for spending and withdrawal.  This would make email orders more difficult
to deal with since mail would have to bounce back and forth.  Actually,
Chaum's simplest dcash scheme has a one-step protocol for spending (just
send the cash), but that requires on-line verification.  TCP connections
can handle the back-and-forth very quickly so that may be a preferred
communications method.

Today, most credit card transactions do an on-line check, so I don't think
that on-line systems should be ruled out, although eventually a dedicated
network separate from the internet would probably be needed.  The total
data transfer per transaction is not large, a few hundred bytes.

One question in considering whether double-spending is likely to be a
problem is whether bank accounts are anonymous.  One possible system
is for bank accounts to be non-anonymous, but for transactions to be
untraceable.  Then if someone double-spends the cheating is traced, not
to a "nym", but to a real person.  (There is still the possibility Mike
raised of stealing someone's cash, similar to how you might steal someone's
PGP secret key today, but perhaps this will not occur often enough to
be a problem.)

In this case you don't have to have an infrastructure of reputations and
credit ratings in order to use the cash.  Nick's idea sounds like it would
take some time to develop.  Our hundreds of years of experience in giving
credit will require some readjustement to a world in which "nyms" can
disappear much more easily than physical people can.

Another technical detail with the two forms of digital cash that I am
more familiar with, Chaum's on-line and off-line systems from his Crypto
88 paper, is that even the off-line system requires the vendor to communicate
with the bank for every transaction.  He has to send in the spent cash, as
well as the results of his protocol with the customer, for every piece of
cash he gets.  The difference is that he doesn't have to do it right away.
So this off-line system will actually require more bandwidth for communication
with the bank than Chaum's on-line system would (because of the extra
transaction information that has to be sent).

It seems that on-line and off-line cash systems both have pros and cons.
Initially my feeling is that an on-line system might be preferable because
there is less need for trust between the parties involved.  Each person
checks at each stage to make sure he is not being cheated.  There is no
need for a legal system to prove double-spending and force cheaters to make
good.  The protocols are much simpler and easier to understand.  And the
bandwidth requirements are less.  The main disadvantage is the need for
enough redundancy in the bank to allow continual accessibility, although
even this would not be an issue for purchases which are delivered after
a delay, typical of electronic purchases today.

Hal Finney
hfinney@shell.portal.com

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLN0b86gTA69YIUw3AQEw+wP/daSj1lrRoYB/YuXVq1JGVvqxANOwVEyb
KeG53eOaauxn4BlhG6z7jMZYLeTJO1Ct045ZbeKwfgMEDKFyDJyfwquDz7VcgtQH
5N1E4yLRYiIyy6UEiIz6Vg2BLOp1yYqux4h/n6F13xY7HgXYSzHTwZAp+9UFvh5v
lUxNkVkC8Tk=
=n4aj
-----END PGP SIGNATURE-----