1994-12-02 - Re: Scalability of Ecash System / Article on Internet Cash available.

Header Data

From: Hal <hfinney@shell.portal.com>
To: www-buyinfo@allegra.att.com
Message Hash: fbe5f91ae38c5938de0d6ed8a2b4bff54e30e6cfaf6352f526a8aa512c2cbe46
Message ID: <199412020608.WAA12408@jobe.shell.portal.com>
Reply To: N/A
UTC Datetime: 1994-12-02 06:09:09 UTC
Raw Date: Thu, 1 Dec 94 22:09:09 PST

Raw message

From: Hal <hfinney@shell.portal.com>
Date: Thu, 1 Dec 94 22:09:09 PST
To: www-buyinfo@allegra.att.com
Subject: Re: Scalability of Ecash System / Article on Internet Cash available.
Message-ID: <199412020608.WAA12408@jobe.shell.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


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

One thing that could be done with the on-line ecash system would be to
decentralize the task of detecting double-spending.  DigiCash could set
up a large number of coin validation centers on the net, dispersed
geographically to equalize the load.  Then the merchants would do a
simple hash algorithm on the electronic coin to determine which
validation center to use.  That center only records spent coins which
have the specified hash.  Since any attempt to double-spend would mean
re-use of a particular coin, both instances would hash to the same
validation center and so the re-use would be detected.

This way if a validation center went down it would hamper but not stop
electronic commerce.  Other coins could perhaps be offered in payment in
place of those which cannot be validated (although this would require a
certain amount of trust of the shop, but perhaps not much more than is
necessary already).

This might address some of the scalability concerns raised with the
on-line cash system.

Another idea comes from the NetCash people.  Here you have the customer
get a payment token from the bank which is made out to the specific
merchant desired and given a time-stamp, perhaps good for one day.  Now
the merchant can accept these, check the signature, and check its own
database of tokens which it has received earlier that day.  As long as
the incoming token is not in the database, the merchant can accept the
payment with confidence and turn the tokens in to the bank for credit
later as in an off-line system.  Effectively these tokens would be
digital cashier's checks.

The big problem with this is the difficulty of the customer getting his
payment token anonymously.  If the bank knows the customer who is asking
for a particular "cashier's check" to be cut then it learns the
customer's spending patterns, defeating his privacy.  So there would have
to be some communication infrastructure to allow for anonymous
connections in order for this system to work.  Chaum, as it happens, has
written on this topic as well, with his "Mix" and "DC-Net" systems for
anonymous communications.  Unfortunately, these systems have scaling
problems of their own and don't appear to be entirely satisfactory for
this purpose.

Hal Finney
hfinney@shell.portal.com

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

iQBVAwUBLt651RnMLJtOy9MBAQEzfwIApLw5dPjil4unqa0yToT1Wm5/kczvnE/E
IdXrWqhbVz32VqKw1d6QrG/I20t8RiZSG+yuBCPSOcoMi9XMRs2nnw==
=EJTS
-----END PGP SIGNATURE-----





Thread