From: Hal <74076.1041@CompuServe.COM>
To: CYPHERPUNKS <CYPHERPUNKS@toad.com>
Message Hash: 8209afbe64a151c85560823b87f85b0ec7fe44c2cf8276b06dbfc07d7c2ca546
Message ID: <93052507540174076.1041_FHD58-1@CompuServe.COM>
Reply To: _N/A
UTC Datetime: 1993-05-25 08:02:18 UTC
Raw Date: Tue, 25 May 93 01:02:18 PDT
From: Hal <74076.1041@CompuServe.COM>
Date: Tue, 25 May 93 01:02:18 PDT
To: CYPHERPUNKS <CYPHERPUNKS@toad.com>
Subject: Digital cash issues...
Message-ID: <930525075401_74076.1041_FHD58-1@CompuServe.COM>
MIME-Version: 1.0
Content-Type: text/plain
Reading the article in the Whole Earth Review reminded me of our
discussions several months ago about digital cash. I would be interested
in seeing an implementation of digital cash suitable for email or Internet
use.
Chaum is working on "off-line" cash systems, where you don't have to check
with the bank for every transaction. But I think there are problems with
this in the network environment.
The big issue in digital cash is double-spending. Someone could send the
same piece of cash to more than one seller. (We say "double-spending" but
really it could be triple- or worse.) Each seller can check that the cash
was properly signed by the bank and not a forgery, but if they honor the
cash only one of them can be reimbursed by the bank.
On-line systems require the sellers to check with the bank to make sure
a particular piece of cash has not been spent before. As long as the bank
handles such queries sequentially, and adds each piece of cash to a database
of "spent cash" as it sends an "OK" response back to a seller, then each
piece of cash can only be spent once. Double-spending is prevented.
Off-line systems are more complicated. They are designed so that the
anonymity of the spender is lost if the cash is double-spent. This is
achieved by having an exchange of messages between seller and spender,
in which the seller specifies some random information and the spender
responds based on the seller's message. Chaum's fancy mathematics guarantees
that the spender's anonymity is protected if he only uses each piece of
cash once. But if he uses it twice, the random information will be
different for each transaction, and this will cause him to reveal more
information about himself, enough information that the bank can deduce
his identity.
This process is problematical in the Internet environment, though. The
need for a protocol between spender and seller might be tolerable for
systems with direct TCP connections, but the universe of potential
users of cash is much larger than this. I think it will be necessary for
cash to work just via email. And in that case the requirement for
three messages (spender to seller, seller to spender, spender to seller)
for every transaction will be very cumbersome.
Also, if double-spending is discovered it's not clear what you do about
it. Ideally, if the customer has a large enough bank balance to cover
the extra spending the bank can just dip into the account (once the
customer's anonymity is broken by Chaum's algorithms) and pay off the
sellers. But if this is not the case then it isn't clear who would
take the loss or what legal redress the bank would have against the
customer. All this seems to require some legal infrastructure which
would delay the acceptance of digital cash.
In an on-line system, transactions are somewhat easier. Customers send
cash to sellers, sellers check the cash with the bank, and proceed
with the sale. There are still three messages, but two of them are with
the bank, so it is simpler because these always go to the same place.
Spenders have it especially easy as they just send off their cash.
So, I would think an on-line system would be more appropriate for the
net environment as it exists today.
Another big issue is the legality of cash. How legitimate does an initial
implementation of digital cash need to be? PGP's acceptance has been
hampered by its infringement of patents. Digital cash would have a worse
time of it, probably; it infringes on RSA (for the bank signatures) as
well as Chaum's patents. In the Whole Earth article Chaum indicated that
he had the whole field pretty well locked up with patents.
With PGP we can at least make a moral argument that non-commercial, personal use
should be OK, but it's not clear that the concept "non-commercial" can really
apply to digital money. Even if it could, RSAREF does not provide at all
the functionality that is needed since it is the direct mathematics of RSA
that provides the basis for blind signatures. So one would need to get
permission to call the "pure RSA" entry points in RSAREF. Then some kind
of agreement would be needed with Chaum. This is quite a daunting list.
Whether you satisfy the patent lawyers or just decide to go with an under-
ground approach, you then have the issue of backing the cash and the tax
consequences. When I looked into this several months ago it looked to me
like a digital cash system would be much like the "barter exchanges" which
have been tried from time to time, and which have stringent tax reporting
requirements, with associated serious penalties. England is apparently
less strict about this than the U.S., with several cases of barter exchanges
having been publicized recently. Perhaps that would be a better forum for
launching a cash system.
As for backing, I believe that the best way to give digital cash value is
to make it possible to exchange it for regular cash. If you know that
you can take received digital cash, email it to the bank, and receive a
check in the mail a few days later for that amount, you will be likely to
accept it. I have a Disney Dollar on my desk for which it is possible to
take it to a Disney store and exchange it for a regular dollar. If the
same thing can be done for digital cash then I think it will be accepted.
All told, there are a lot of obstacles standing in the way of digital cash.
The technology is complicated, patent issues arise at every turn, and
the complexity of the tax and banking laws will have to be faced. It's
not clear how soon we can expect to be able to tackle these problems.
Hal
Return to May 1993
Return to “Hal <74076.1041@CompuServe.COM>”