[ Back to the previous Rant ] | [home page ] | [ On to the next Rant ]
Robert Hettinga
e$
44 Farquhar Street, Boston, MA 02131
Comments: rah@shipwright.com
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.
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...
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.
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.
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.
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.
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 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.
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.
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.
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.
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
[ Back to the previous Rant ] | [