From: Nathaniel Borenstein <nsb@nsb.fv.com>
Date: Tue, 5 Dec 95 06:08:56 PST
To: rah@shipwright.com (Robert Hettinga)
Subject: Geodesic Payment Systems?  (was Re: Meeting notes from ANSI X.9 Meeting on Electronic Payment)
In-Reply-To: <v02120d09ace90e1bce3b@[199.0.65.105]>
Message-ID: <gkl58I2Mc50eBlRA1y@nsb.fv.com>
MIME-Version: 1.0
Content-Type: text/plain


Excerpts from mail.nonpersonal: 4-Dec-95 Re: Meeting notes from ANSI..
Robert Hettinga@shipwrig (4665*)

> MTB's
> cost on a Digicash trade is $.50, while the most efficient book-entry
> system on the net, First Virtual, has to charge, what? $5.00 to break even?

There are some interesting unspoken assumptions here.  To calculate
anyone's "cost" on a transaction requires the complex amortization of
costs over many transactions, with assumptions/projections about the
transaction volume.  I have no idea where you came by either of your
numbers, MTB's or FV's, but I can tell you that your guess about FV is
off the mark.  And I'm sure that MTB is no more eager than we are to
publicly dissect all the underlying cost structures, so I have no idea
what the 50 cents that you cite really means.

From a consumer standpoint, I think that the only reasonable thing you
can do is to assume that the vendors are pricing their services at a
level that they believe yields profit in the long term.  FV charges 29
cents plus 2 percent, which means that you can put 50 cent charges
through the system if you're willing to give up 30 of those cents.  By
pricing it that way, we have invited people to put 50 cent charges
through the system.  We wouldn't have done that if we didn't think we
could make money on it.  

To be perfectly clear:  our minimum service charge is 30 cents, not 5
dollars.  If we didn't think it was worthwhile to take transactions that
small, we wouldn't do so.

Finally, on the more philosophical matter:

> They don't get it. The network isn't a hierarchy. The network is a
> geodesic. You don't need offsetting book entries, you can trade digital
> certificates much cheaper. You don't need to control your software, you
> need to make it autonomous and set it free.

In terms of crypto-privacy, anonymous communication, and things like
that, I agree completely.  However, it's genuinely more complicated than
that where money is concerned, because there are aspects of the
translation between "bits and bucks" that have some extremely serious
practical complexities.

A true geodesic structure is self-supporting and self-structuring.  A
cryptographic infrastructure can and should be similar, I agree
completely.  However, a *monetary* infrastructure needs convertability,
and the points of conversion are always the best targets of attack for
criminals.  (I've been casting about for an analogy to physical
geodesics, and it's hard to find one.  The best I can come up with is to
imagine that in order to convert a carbon buckyball to a more
conventional set of carbon molecules, you had to do it through a service
bureau that was capable of error, fraud, or subversion by outside
criminals.  This would ONLY matter if you ever wanted to do such
conversions, but it would matter a lot then, especially if you had to
suffer a serious financial loss if you got the wrong carbon molecules at
the end of the process.)

IF you wanted to settle for a totally non-convertible economy (like
rubles in the old Soviet Union, or like the LETS system on the net
today, as I understand it) then you could build it geodesically.  But if
you want to be able to convert back and forth between Internet payment
systems and non-Internet payment systems, it can never be truly
geodesic.  It will always be attackable at the points of conversion. 
(You may "trade digital certificates", but how do you know the ones
you're receiving were obtained for legitimate real-world value?) 
Because of this, the underwriting financial institutions, who have a
very reasonable desire to limit their own risk, will inevitably seek the
protection-by-traceability offered by something less than perfect
anonymity.  We may not like it, but it's a very natural position to be
taken by those who are actually bearing the financial risks at the point
of conversion.

The truth is that there's a natural tension between the consumer's
desire for privacy and the underwriter's desire for financial
protection.  First Virtual has been worrying about this for 2 years now,
actually.  Our solution -- which I think has held up pretty well -- was
to allow users to be pseudonymous (as opposed to anonymous), to limit
the traceability-by-pseudonym to the service bureau (FV) that effects
the payments, and to treat all such information with the highest
possible standards of confidentiality.  The fact that the information
can be traced when absolutely necessary is actually a huge selling point
with those who carry the financial risks.  I'm not claiming it's a
perfect solution, but I think that unless you are clear about the
underlying tradeoffs, it's hard to talk seriously about how to build a
better solution.  -- Nathaniel
--------
Nathaniel Borenstein <nsb@fv.com>       | (Tense Hot Alien In Barn)
Chief Scientist, First Virtual Holdings | VIRTUAL YELLOW RIBBON:
FAQ & PGP key: nsb+faq@nsb.fv.com       | http://www.netresponse.com/zldf