From: eric@remailer.net (Eric Hughes)
Date: Sat, 19 Nov 94 08:24:19 PST
To: cypherpunks@toad.com
Subject: Re: Islands in the Net
In-Reply-To: <199411190638.WAA05397@netcom3.netcom.com>
Message-ID: <199411191622.IAA02376@largo.admate.com>
MIME-Version: 1.0
Content-Type: text/plain


   From: tcmay@netcom.com (Timothy C. May)

   For example, I tend toward Amanda's point of view, that credit cards
   "quack like a duck."

I don't think I can stress the following enough, but understanding the
following principle is necessary (not convenient, or helpful, or
replaceable) to understand how payment systems work:

** The most important thing about a transaction system is not how it
** works a transaction succeeds, but what happens when it fails.

Failure properties are more important than financial properties.  The
the expectations about float, rates of interest, time to clear and
settle, etc. are all meaningless if the failure properties don't
create a robust system.

Anyone at all can design a transaction system which works for
successful transactions, but designing for failure is enormously and
surprisingly difficult.  For example, here's a transaction system
that works only when there are no failures.  Everyone memorizes
the amount of money they have.  When two people do a transaction,
one persons increases their money by the same amount that another
person decreases theirs.

Now obviously this system doesn't work.  But the reason it doesn't
work is because of failures -- increasing balances between
transactions the obvious one.  Note that if all the implicit
constraints are met the naive system above does actually work.

Let me be blunt.  Most transaction systems people run by me show the
same naivete as those who design ciphers for the first time.  These
naive systems just won't work, and those that propose them just
haven't thought through the issues, and usually have been ignorantly
unaware that there are any.

"Why can't you just ..." is, unfortunately, most often said in mock
ignorance rather than humility.

I should note, though, that almost all these systems _do_ work
reasonably well under simple failures.  That means that they could be
deployed, but that they won't scale to many users.  Thus while they
might be suitable for a club like the hypothetical Hacker Privacy
League (which cypherpunks is _not_), they aren't suitable for
universal use.

As a primer and milestone, I'll make the bald assertion that
bankruptcy of the financial institution is one of the most important
failure modes to consider.  The argument that this almost never
happens is made only by those who haven't estimated the cost of this
failure more.  Once you have a good appreciation about bankruptcy and
payment systems, you'll be well on your way to having the mental
framework necessary for dealing with the issues.

I don't intend to lecture on this list about these issues.  These are
extremely arcane yet important details, and I hope to derive part of
my livelihood from them.

   When I make a purchase with my credit card, and
   the thing clears, both the merchant and I act as if we've just
   exchanged money.

To take this particular example, what happens if it doesn't clear?  Is
this different that, say, with a check or with cash?

   Anyway, there are many forms of "money," with many things that make
   the forms "money-like." 

A "means of payment" is only one of the functions of "money".  It is
useful to keep this clear.

Eric