Real-world digicash

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

hfinney@shell.portal.com writes:
re NetCash:
> The anonymity was not strong.

Hmph.  You can say that again. There is no real anonymity in NetCash
(v1).  What they describe is something like an online (non-anonymous)
system with the suggestion that people may achieve anonymity by
trafficking in coins without verifying their validity.  If they
receive an invalid coin, T.S.  In such an environment, you can bet
that everyone would keep records of all off-line transactions so they
could recover their losses if they were passed an invalid (spent)
coin.  The suggestion that a (non-anonymous) Currency Server might
simply avoid tracking coins is poppycock.  That would work for epsilon
months, until the CS was strongarmed into keeping logs.
One valid point that the NetCash paper raised was that a framework
must be devised in which currency exchange can occur, without forcing
an intermediate transfer into paper. 

I like Nick's suggestions regarding mostly-offline digicash.

A couple of issues which it seems must be pointed out:

1.  Any digicash scheme is going to require some hardware.  You just
can't do this with pencil and paper.  They don't all require
special-purpose, tamperproof hardware, but very few people are going
to be willing to keep long lists of numbers and do complex arithmetic
in their head...

Hal sez:
> 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.

The credit-card infrastructure is funded by the 3%-7% cut that the
credit company gets from each purchase.  Who is going to fund such an
infrastructure (potentially much much much larger) for cash
transactions?  Presumably, it would be someone who stands to make a
profit from these transactions, but how will that profit be realized?
Maybe the digicash vendor will charge for on-line verification.  I
guess that works.  It lets the dcash recipient decide whether to trade
off risks against known costs, which I like.

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

A widely-used digicash scheme will certainly include small computers
for performing the transactions.  Such a computer should be guarded as
well as one's wallet, or one's home safe.

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

Requiring more bandwidth isn't really a problem.  The available
bandwidth of any network is practically infinite, if you don't care
about delay. For all practical purposes, the off-line systems don't care
about delay.  (to forestall flames, I will admit that the delay
must be small enough to reduce the temptation to double-spend, and
that it must be small enough to prevent the holder of cash from losing
value due to inflation.  Delays on the order of days are not
unreasonable.  Given current technology (ie, without purchasing any
new hardware), the workstation on my desk can handle 10 times the
bandwidth that it now does, if I will accept delays on the order 
of several days.) 

I forgot what else I was going to say.  I think my 'nym is stealing my
thoughts. 

Lyle		Transarc		707 Grant Street
412 338 4474	The Gulf Tower		Pittsburgh 15219