From: rah@shipwright.com (Robert Hettinga)
Date: Sat, 13 Jan 1996 07:40:47 +0800
To: cypherpunks@toad.com
Subject: (fwd) e$: Starting an Avalanche
Message-ID: <v02120d00ad1c588d46f6@[199.0.65.105]>
MIME-Version: 1.0
Content-Type: text/plain



--- begin forwarded text

Sender: e$@thumper.vmeng.com
Reply-To: e$@thumper.vmeng.com
Mime-Version: 1.0
From: rah@shipwright.com (Robert Hettinga)
Date: Fri, 12 Jan 1996 13:02:27 -0500
Precedence: Bulk
To: Multiple recipients of <e$@thumper.vmeng.com>
Subject: e$: Starting an Avalanche

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

e$: Starting an Avalanche

1/12/96
Boston, Massachusetts

The most interesting thing I've read in quite a while is a reprint of
the March 31,1995 issue of Esther Dyson's Release 1.0, which, I
understand, was the first time someone other than Esther herself edited
an issue.

The editor was none other than Eric Hughes, of cypherpunks fame, and the
topic was, of course, e$. Well, he didn't up and say "e$" anywhere,
exactly, the title of the whole issue was "A Long-Term Perspective on
Electronic Commerce", but he was talking about e$ just the same. Eric
told me about this magnum opus when he came to help me talk about e$ at
Apple in December. It was the first time I had heard of it, and when I
talk to people who are interested in these things, it's the first
they've heard of it, too. Blink once, and you miss the good stuff, I
guess..


I won't go too much into what he said there, as I'm still digesting it,
and it's frightfully copyrighted, but I'm sure you can get reprints from
EDventure Holdings, Esther's company, by sending e-mail to their
circulation and fulfillment manager, Robyn Sturm, robyn@edventure.com .

You can definitely tell Eric wrote it, though. When Eric's really
cooking, it's like he invents this whole language to describe what he's
talking about. In this case, that's a good thing, because most of what
he talks about he has to invent as he goes along. Anyway, it's 28
single-spaced elite-pitched pages of pure Eric, and it's manditory
reading for anyone who wants to sit in on an advanced e$ colloquium from
the comfort of their own living room...


I'm taking, as my text for today's sermon (say "amen!", somebody), the
following, from Eric's Release 1.0 issue, page 19:

"Multiparty compatibility.

"A software product launch is a two-party negotiation. Software vendors
write products for a given operating system and persuade consumers to
buy it. This is a standard retail transaction. Prospective sellers of a
money system, however, have a four-party negotiation: the money system
vendor, consumers, merchants and financial intermediaries.  That is,
there is one seller and three buyers, each of which has different system
requirements.

"Consumers have microcomputers or PDAs or smart cards. Merchants vary
widely by size; each will hve different requirements for operations
size. Banks and other intermediaries require extremely reliable
transaction processing systems. No single vendor will be able to meet
all these requirements. Anybody who expects to provide the entire
technology infrastructure for a new money system will fail outrightly
and completely. Success will require partnerships at the very least.
Open standards will be even more likely to succeed.

"This criterion against isolation cuts out several would-be contenders
from my book right away: Netbank, Digicash and the academic projects
NetBill and NetCheque.  This is not to say that these companies won't
have businesses, but rather that their ventures will always remain
small."

Now, this was written in, say, February of last year. A year ago. What
amazed me was that it was exactly what I was talking to someone about
last week. I love this stuff...

Now I'm not bashing any of the above payment schemes, here, but there is
a lot of the old industrohierarchical (see, Eric, I do neologism too!)
mindset in what a lot of e$ protocol developers are doing out there.

With that in mind, I'm going to step into *my* version of e$-Life,
- -the-Universe and -Everything, and I'm going to do it with a model for
distributing digital bearer certificates of various kinds, starting with
digital cash, but easily extensible to any kind of digital bearer
certificate.


Definitions

As Eric said, there are at least 4 players in any money system. I hope I
may be excused if I tweak this a bit...

Consumer

The first player is the consumer. This is the person who purchases a
digital bearer certificate for some reason. In the case of a digital
cash certificate, this person is buying a piece of digital cash from
someone else, for some other kind of money, in order to effect a
transaction on the net later.

Merchant

It gets more complicated a little later, but, for the time being, this
is a person who accepts a digital bearer certificate in exchange for
something else. Usually this person is a commercial entity, and thus
needs to be able to test the certificate, on-line with the underwriter,
before accepting it, in order to prevent double-spending and reduce the
risk of the transaction.

Underwriter

This is the entity which issues the certificates, and is responsible for
exchanging them into other forms of money or certificates of other
kinds. The second most important thing an underwriter does is to verify
that certificates haven't been double-spent.  The most important thing
an underwriter does is to market its certificates.

Trustee

A trustee holds the money for the underwriter while it's on the net.
Like bond trustees, the trustee works for "shareholders", the holders of
the digital certificates, according to an agreement between the
underwriter and the certificate holders. Typically, the trustee is a
bank, since certificates are usually settled for money.

Software Developer

Off of the net, there are consumers, underwriters and trustees of
physical certificates. We haven't really introduced any really
net-specific features. Here's where we do.  Since digital certificates
are digital objects, they're created and handled by software and moved
around on networks. The second most important thing that developers of
digital bearer certificate software do is to write software which
issues, verifies, and handles digital bearer certificates. The most
important thing that developers of digital bearer certificate software
do is to market their software to consumers, to trustees, and to
underwriters.

A software developer can develop all kinds of different software and
market that code to any market that's out there: vertical, functional,
or any niche that makes money. A developer can make wallets, which can
do peer-to-peer or client-server transactions, or cash registers, which
do on-line transactions involving the underwriter to validate
certificates against double spending, or mints, which produce and
validate the digital certificates themselves. A developer can even
subdivide those major software objects into smaller peices, if there's a
market for it.

Protocol Inventor

Protocol inventors are the people who had the idea to begin with. They
figured out how to generate, handle, verify, and transmit this
particular type of digital bearer certificate, and typically have
patents on the process. The second most important thing a protocol
inventor does is design cryptographic protocols, licence them, and
validate their implementation. The most important thing a protocol
inventor does is market their protocols to software developers, to
underwriters, and, in the early stages, to trustees.


A prima facie retread

Yes, it's time for Hettinga to trot out his now-threadbare (I'll say
"time-tested") business model for digital cash, and show how this all
works. Of course, you can use digital bearer certificates for all kinds
of things besides cash, and I contend in my more unrestrained moments,
that *any* security can be issued as a digital bearer certificate, but's
let's stick with digital cash here, for the time being.


The protocol inventor is a cryptographer who has a brainwave one day and
invents a digital bearer certificate protocol.  He announces it, patents
it if possible, lots of other cryptographers vet it, and it works.
Potential underwriters, software developers, and even trustees blow
apart his e-mail server asking him when he's going to let them build
code, businesses, or whatever it is they want him to let them build.

The inventor convenes a group of interested developers, and they start
working out how to implement the protocol into code. The inventor makes
deals with all of them. When they've finished their code, he'll certify
that their code adheres to the protocol, and they'll pay him a licence,
or a certification fee, or whatever.

The inventor also starts to chum the water for underwriters, even though
the developers are the people who're going to be actually closing deals
with them, and trustees, even though the underwriters are going to be
actually closing  deals with *them*.

So, the day comes, and people are actually buying these certificates.

The consumer buys, from one of many software developers, or is given, by
one of many underwriters, a wallet, which allows the storage and
disbursement of digital bearer certificates, either on-line or off-line.
I personally believe that there will be off-line transactions between
people who trust each other enough, caveat vendor ;-).

The consumer goes to a web page. Think of this web page as the
equivalent of an automatic teller machine. As such, it has at least
link-, and hopefully internet-level encryption to the user's machine.
Not only that, but the consumer's account information is probably
encrypted so that not even the underwriter sees it, in the same way that
the Cybercash protocol works now. If the consumer's machine has a card
swiper, then he swipes a card and enters a pin number. He could also
store this information encrypted on his hard drive, and just type a
passphrase to release it. He could also have all this on a smart card.
Software and hardware vendors will build what consumers, underwriters,
and trustees want to use.

The request and authorization for cash goes over the net, through the
underwriter and the ATM network to the consumer's bank, who sends an
authorization message back to the underwriter to disburse digital cash
certificates in the amount of the consumer's request. At least that's
the way it would work for the time being. It's easy to see that, if the
consumer's bank was on the net, the transmission authorizing
disbursement to the underwriter could just go over the net itself. The
bank and the underwriter settle with a fed funds wire. For the time
being, anyway. ;-). The underwriter then issues the certificates to the
consumer in the desired denominations, in addition to whatever fee the
underwriter charges, in the same way traveller's checks are sold at a
premium at the time of sale. The money from the consumer's bank goes to
the underwriter's account at his trustee bank, collecting interest,
payable to the underwriter, until the money comes back off of the net
someday, payable to the redeemer at par (the value of the  denomination
of the certificate).

The consumer then buys something on-line from a merchant, or off-line
from another consumer (or a merchant who can't afford the security of an
on-line transaction, and believes the risks are worth it), who then
either spends the cash certificate somewhere else or redeems the
certificate through the underwriter, who in turn has his trustee wire
the money to the merchant's bank.


Wearing too many hats

When you break the world up the way I have above, you see the world of
digital certificates in very interesting terms. First of all, you can
see what Eric was talking about. Lots of people in the digital cash
business are trying to wear too many hats. Underwriters who are also
trustees, protocol inventors developing software, merchants who are
software developers.

Remember my contention elsewhere that the worst thing you can do in a
geodesic market is to create industrial scale-economy hierarchies. The
more independent entities you have, doing different things in as
market-driven a fashion, the better. The instantaneity of communication
and the multiplicity of information processors continually lowers the
cost to entry and makes markets very competitive, forcing lots of
innovation and product evolution. Concentrations of information, or any
other resource, get "surfacted" into the lowest possible reaches of the
network as processor prices fall. In InfoWorld a couple of months ago, I
compared Microsoft to a dog in the manger in this regard, and you can
see what they're trying to do now that they figured out that their
monopolistic desktop strategy won't hunt on the internet.


Now What?

So. You've developed the be-all, end-all digital bearer certificate
protocol. What do you do? The most important thing you can do is to
develop, validate, and above all, promote your protocol.  Anything else
is not only inefficient, but, in the worst scenario, it can be
considered a threat to one or more of the other players in the system,
and no one will adopt it. Your protocol is stillborn.

The thing you want to do is to create as many software developers, as
many underwriters, and as many trustees as possible. Why?

The more underwriters you have, the more people are using your protocol.
Remember, the underwriters are charged with actually marketing the
certificates themselves. Also, the more underwriters there are, the more
robust your certificate system is, because there is no single point of
failure -- economic, operational, or otherwise -- in the system.

The more trustees you have, the more faith everyone has in the system.
The social and legal parts of your protocol are enforced by the
trustees. They're there to hold the stakes and keep everyone honest. To
prevent repudiation of the certificates by the underwriters themselves
by making them hold a respectable reserve against the certificates
outstanding, for instance. In addition, the trustees could be used to
settle certificates from one underwriter against those of others. That's
already built into the banking system, with various central bank wires
and clearing associations. In the model above, the trustee is the link
to the non-net economy. It is the ultimate settlement mechanism because,
for the time being, digital cash has to be denominated in other
currencies. Certainly, like any method of abstracting value, digital
cash cannot exist if it is not immediately convertable into other things
of value, so there will always be those who are responsible for
guaranteeing those conversions. In my model, and in non-net securities
markets, those people are the trustees.

The more developers you have, the more competition there is to build
software which creates, handles, and verifies the certificates as
efficiently and reliably as possible. Like underwriters, software
developers are responsible for marketing *their* products -- the
wallets, the cash registers, the mints, that your protocol requires in
order to function -- to the various participants in the digital
certificate market.

That means that you have to be as open with your protocol as possible.
You have to create a set of reference documents which everyone can read
and understand. You have to promote the hell out of the protocol by
hosting conferences of current and potential underwriters.  Then, when
you have lots of developers, underwriters, trustees, and, by extension,
users, of your certificate protocol, you have to keep the protocol
honest by cryptographically validating the various software parts so
that the market's participants can trust that the protocol is being
adhered to. That means *not* writing software, paradoxically. The reason
you have this great protocol is because you're a great cryptographer:
not a great underwriter/marketer, not a great developer, not a great
trustee/banker. The entire market can't function without you, and, in a
geodesic market, you can add significant value and get paid for that
value without owning all the other components of the system to get it.


The great unwashed avalanche

There's great benefit to having this great unwashed horde of people
helping you put all this together. Most of that benefit comes from
creating a large chaotic emergent system, a market. People can
specialize in some small piece of the system and optimize it without you
having to tell them what to do, for instance. In addition, very small
investments yield rewards way out of proportion to the money invested.

My favorite example for this is the prize that was offered for flying
non-stop from New York to Paris.  Many times the prize money was spent
in achieving the feat by all the contenders, and some single teams
probably spent more than the prize money all by themselves. The rewards
to the person who finally completed the trip greatly exceeded the prize
money he won. Finally, the rewards to aviation the aviation as a whole
were much greater than all the money spent by all the teams trying to be
first.

That's the great thing about creating an emergent process like a digital
certificate market. It's like kicking some snow down on top of an
avalanche zone. You release all that stored energy, ambition, and
talent.

All at once.


Cheers,
Bob Hettinga


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMPagTfgyLN8bw6ZVAQHmqQP/RaD/2XPxO2Gx2otHjAPI8+H+xkT85JSX
BqVyYEYo/8ilbf/bmZC9YDIhmi0vDpEODkj+7LJ0zsm8AX0LAOLj8N23f3R5LXX0
2QNvPczNN8v+9T1M2r4bhgtRUfy7OPFkOpvfbrJkkWT4XNL8PwojAA3UMVQ8UgYJ
A0nLC/z+78s=
=5TRr
-----END PGP SIGNATURE-----

--------------------------------------------------
The e$ lists are brought to you by:

Making Commerce Convenient (tm) - Oki Advanced Products - Marlboro, MA
Value-Checker(tm) smart card reader= http://www.oki.com/products/vc.html

Where people, networks and money come together: Consult Hyperion
http://www.hyperion.co.uk                    info@hyperion.co.uk

See your name here. Be a charter sponsor for e$pam, e$, and Ne$ws!
See http://thumper.vmeng.com/pub/rah/ or e-mail rah@shipwright.com
for details...
-------------------------------------------------

--- end forwarded text





-----------------
Robert Hettinga (rah@shipwright.com)
e$, 44 Farquhar Street, Boston, MA 02131 USA
"Reality is not optional." --Thomas Sowell
The NEW(!) e$ Home Page: http://thumper.vmeng.com/pub/rah/