From: Hal <74076.1041@CompuServe.COM>
To: CYPHERPUNKS <CYPHERPUNKS@TOAD.COM>
Message Hash: d3d5f885701aa3aae30aec813d76495841c669ae22badada230b890219365887
Message ID: <93011718474474076.1041_DHJ40-1@CompuServe.COM>
Reply To: _N/A
UTC Datetime: 1993-01-17 18:53:20 UTC
Raw Date: Sun, 17 Jan 93 10:53:20 PST
From: Hal <74076.1041@CompuServe.COM>
Date: Sun, 17 Jan 93 10:53:20 PST
To: CYPHERPUNKS <CYPHERPUNKS@TOAD.COM>
Subject: Poor Man's Cash.
Message-ID: <930117184744_74076.1041_DHJ40-1@CompuServe.COM>
MIME-Version: 1.0
Content-Type: text/plain
Tim May's message about remailers mentioned the possibility of a
simple way of handling digital postage. This can be extended to be
a replacement for digital cash which doesn't use any cryptography.
As in Tim's suggestion, the "banker" (or "money changer" in the model
I described yesterday) simply creates 50-bit numbers, each of which is
a "piece of digital cash". The banker keeps a list of the specific
numbers that are circulating. When someone presents one for payment,
he checks to see if the number is on the list. If so, he honors it
and then removes it from the list. As with regular digital cash,
withdrawers keep the numeric values secret.
Nobody can forge the cash because no one can create numbers which are
on the banker's (secret) list.
There are two problems with this system. The first is that there is
no way for the seller in a seller/buyer transaction to verify that
the random 50-bit numbers the buyer is offering him are actually valid
pieces of digital cash. The only thing he could do is to send them
to the bank and have the bank report back as to whether they are valid
or not.
But in at least the simpler cryptographic protocols, the same problem
exists. In those protocols, it may be possible to use digital signatures
to recognize that a particular piece of cash originally came from the
bank, but you still have the problem that this cash may have been
"spent" before. Digital cash can be reproduced trivially, so any seller
must again check with the bank to make sure that the cash he is offered
is still valid. (More complex schemes are intended to allow "incrimination"
of a buyer who reuses cash, but I feel that they have problems as well.)
So this problem is no worse than at least the simpler cryptographic
schemes.
The other problem is that this cash is not anonymous. When a seller
sends in some cash he received from a buyer, the banker can recognize
which buyer that cash came from.
But there are several reasons why this might not be as bad as it seems.
First, the buyer and seller may themselves be anonymous to the bank. The
bank may know them only through an anonymous address of the type we have
been discussing here. So, at best, the banker could deduce things like
"account 1234 seems to be buying a lot from account 5678." This is not
a direct loss of anonymity. Second, our own paper cash already has this
problem, through the serial numbers printed on each bill. Although this
is used occasionally by law enforcement to track criminals, it is not
considered in general to be a threat to anonymity.
And third, the banker could have a policy of not remembering which buyer
received each outgoing digital cash number. This could be done by
having the banker publicize the software which he is running, so that
people can see that these records are not being kept, along with
occasional audits by some third party to verify that the banker is
actually running that software. There would still be an element of
trust involved, but trust will always be a part of such relationships,
and reputations will be important.
This "poor man's digital cash" is not that interesting technically,
because no cryptography is involved. But it does provide most of the
features of crypto-cash, and it does so in a manner which is easy to
understand and explain. It also violates no one's patents, so it would
be that much easier to start experimenting with it safely.
Hal
Return to January 1993
Return to “Hal <74076.1041@CompuServe.COM>”
1993-01-17 (Sun, 17 Jan 93 10:53:20 PST) - Poor Man’s Cash. - Hal <74076.1041@CompuServe.COM>