e$: Financial Cryptography for Dogs

Robert Hettinga
Shipwright Development Corporation
44 Farquhar Street, Boston, MA 02131

Comments: rah@shipwright.com


October 27, 1995


Now that I've likened Cyberdog to the famous clay animation character Grommit the Dog reading a big book called "Financial Cryptography for Dogs", let's take a look at that book's table of contents, shall we?


Chapter 1: Building in existing e$ capability.

It seems to me that the first thing that ought to be done is for people to be able to spend money using CyberDog. When I say that, most folks point out that Netscape implements SSL, it's going to be an OpenDoc part sooner or later, and so people can spend money just by typing in their credit card numbers into a secure form somewhere.

Of course, that's not exactly what I had in mind. Remember when I asked whether you took MasterCharge the last time you sold a car? The point is, the economic medium of choice for peer-to-peer economics is cash, or close equivalents like cashier's or certified checks, money orders, traveller's checks or checks from a trusted buyer.

While there are various schemes for digital checks or traveller's checks, digital cash has only recently been made available. There's a bank in St. Louis which has teamed up with Digicash bv, David Chaum's digital cash outfit, to implement real, live, digital cash on the net. That happened this Monday. Digicash has been in beta on the net for about 6 months or so, and I expect that Chaum and Co. would be ecstatic if someone built an OpenDoc wallet or cash register part. He's giving the software away for free as it is, even though he's still got pieces of the protocol under wraps at the minute.

Now there are politico-philosophic problems with Chaum's current digital cash implementation, in that it's not totally anonymous. The bank and the seller can collude to identify the buyer, which is necessary to prevent double-spending. Currently all owners of digital cash are strongly identified, to keep various political entities at bay, so utterly anonymous digital cash, the whole point to Chaum's original idea, is still a ways off. Nonetheless, the current version of ecash, Digicash's brand name for this version of digital cash, will do nicely for all peer-to-peer cash trades on the net.

Remember what I said about cash trades. They are instantiated, cleared and settled all at once. This blows a lot of middlemen out of the loop, and should significantly lower a buyer's and seller's transaction costs.

For more information about digital cash, take a look at the Digital Cash announcement.

It's easy to see that building parts to handle both credit card and cash transactions to make using them easy is (ahem) part and parcel of improving the interface of digital commerce applications using CyberDog, so let's look at those next.


Chapter 2: What does it looks like to the user

When I had my "light dawns on Marblehead" experience with OpenDoc at Boston's MacWorld this summer, I immediately saw in my head someone dragging digital cash icons representing bills or coins, or even a credit card icon, onto a web-page's cash register icon to pay for stuff.

I haven't really thought of much else, but it seems to me that that's a powerful enough image. You could maybe jazz it up by making part that looks like a wallet or purse which opened up a window so you could see the money inside when you double-clicked it.

Similarly, you could drop cash onto other icons like banks, or a pile of securities representing stocks or bonds, or whatever.


Chapter 3: Money Through the Looking Glass

On a more heritical note, the major reason we need banks for large amounts of cash is that they're safe. With digital cash, your cash is as safe as your last backup. Banks may become nothing more than offsite places where your cash is backed up, and you will invest your money directly with a money manager when you want a better return. I talked about this a little bit before.

A stickier point is that with this model, you can send money anywhere in the world, not just spend it there. This will make national laws regulating the flow of currency in and out of thier borders very interesting. As Tim May, one of the two founders of cypherpunks, and the person who coined the word "cryptoanarchy" says, "National borders are speedbumps on the information superhighway". I have a client who has 50 beauty salons all around the world. I would purely love to see him upstream his cash to the home office in London this way every night, on the net, sans the bank wire system.

You could bust your brains on all of this, and you can be my guest, because mine's busted already, but there is sizable opinion out there that reality is not optional here. You can't put the cryptographic genie back in the bottle any more than you can forget any other piece of technology, especially as useful as digitial certificates are going to be.


Chapter 4: A step farther out

In the rant where I compared CyberDog to Grommit, I talked vaguely about the idea of code which sends you money. I'm going to talk vaguely about it here a little more, because I have no idea how to do it except in how the objects might behave. It's easy to see how you could build into an OpenDoc part the ability to ask for a receipt from its builder that says you paid for the software, or made this month's rent payment, or whatever. It could even initiate the payment process with permission. It's also easy to see that in some future version the ability to send agents out into the world with a little cash to buy you things.

The limit on this is the greed of the developer balanced against what will be a pretty efficient market. There's nothing to keep a developer from making a knockoff in a world where enforcement of software patent and copyright will be cryptographically impossible. Once again, reality is not optional. So-called software or data watermarks only tell you who had the copy which was pirated, not necessarily who did the pirating. As more and more anonymous techniques are developed, including IP and address spoofing, remailers, and HTTP proxies, not to mention the requirements for stronger and stronger link encryption like that in the IPSEC standard, it will become harder and harder for governments as we know them to tax people and corporation. The joke on one Harvard Law School mail group was, "What happens when taxes become a tip?". Essential services will still have to be paid for, including personal safety, water, sewers, telecommunications, and maybe even some kind of gross copyright enforcement, but John Perry Barlow's favorite hobbyhorse aside, it's clear that the people who benefit in this darwinian environment are going to be people who keep building new stuff. New stuff like new code, or new ideas, or the ability to generate syntheses of those new ideas, like an editor does.

Tim May talks about the necessity of building cryptographic financial objects, which have the behaviors of what would normally be legal agreements. An old bearer bond, for instance, was a piece of paper with an enormous amount of legalese printed on it in mouse type. Those legal stipulations said how the bond and its coupons would be treated when presented to the issuer, under what conditions the principal and interest would be paid. All that needs to be written into software somehow, using cryptographic protocols where necessary. Those are where the oportunities would be for budding financial engineers in the future, not as an associate in a Wall Street law firm or investment bank. The reason is that if you build an object which you can't cheat, or repudiate , you don't need a lawyer and the physical force of a nation-state to back him up. That's a lot of what Chaum has done with his digital cash protocol. The only way to repudiate a digital cash trade is to double spend the cash, and with an on-line trade involving the buyer, seller, and the underwriter, that's impossible. This will be how securities will be bought and sold, with a trusted third party verifying the trade, and announcing the price.


Chapter 5: Conclusion

There are many more things to think about, some way over the edge, like the above, but it seems to me that the first part (pardon the pun) is easy. The code for handling ecash has already been built by Digicash, and it would seem that all it would need would be a spiffier, drag-the- money-onto-the-register front end. Of course, everyone tells me that the "trivial" stuff is the hardest part.


[ Back to the previous Rant ] | [  home page ] | [ On to the next Rant ]