paul@poboy.b17c.ingr.com (Paul Robichaux) writes: [digicash stuff...] At some point I am going to have to take a look at my NDA with Digicash again and see how much I can say about the reality of some of these things...

As others have pointed out, network bandwidth and processing CPU are cheap enough to allow multiple banks to communicate cleanly. Real banks already understand how to do this.

Wanna bet? You should get into a clearing discussion with Eric sometime (I think that the clearing issue must be one of his favorite things in the world as he has so much to say about it :) Clearing is not only non-trivial, it can be downright ugly. A small system is not incredibly difficult to set up, but a nationwide or global system would be something that would give scores of engineers and designers nightmares for years to come. Things are easy when you talk about your $50 Visa purchase or check, but when you start to deal with clearing big aggregate sums through banks things get real nasty very quickly. In the US we have the Fedwire system and other gifts of the Federal Reserve to prop up a few of the weakest parts of the problem, but it is still a house of cards waiting for the right puff of wind... jim

Paul Robichaux (perobich@ingr.com) writes:

...

Things are easy when you talk about your $50 Visa purchase or check, but when you start to deal with clearing big aggregate sums through banks things get real nasty very quickly.

Why clear big aggregate sums? Why not just clear smaller ones? Hell, why not use a forwarding engine that just says "this cash came from bank X" and sends it along?

I will defer to Eric on this one, but what happens is bank X does not seem to respond? What happens if bank X goes bankrupt between the time it says "Yes that coin is good, pay user foo", and the time your bank goes to get the money from bank X to settle it's payment to user foo? Are you going to clear every transaction individually, if so how much more will that cost you than batching transactions? What factors become involved when banks start borrowing money to clear daily transactions among themselves? Take a look at the process involved in clearing checks and you will soon see how it can get very strange. jim

Paul wrote:

I'm sure that the design of a robust, usable system is nontrivial, and I don't mean to imply that it is. I just don't believe that a tool the size of Fedwire and the existing bank architectures are, or will be, required.

My $0.02: The size or complexity of Fedwire is not the issue (it's actually pretty simple compared to some off the suggestions I've heard recently). Nor is this merely a matter of designing robust computer programs (although this is very important). What is important is the degree of trust between the clearing parties, the legal arrangements between the clearing parties, and the backend of the clearing mechanism, which is settlement -- how you balance out the real money accounts. Let's say you have two banks, X and Y. Bank X has slightly more merchant activity than bank Y, as bank Y is more consumer oriented. Therefore bank Y is going to receive more real dollars from its customers, and bank X is going to pay out more real dollars to its customers. If these two banks are part of the same clearing system, then it is certain that the net flow of e-cash from Y to X is going to need to be accompanied by a flow of real US$ from bank Y to bank X. This is called settlement. In reality, these things are extremely dynamic, changing on a minute-by-minute basis throughout a clearing system, but let's stick with this simple example. As Mr. Hughes pointed out recently, the question is not whether the system works when everything goes as expected, but rather what happens when things fail unexpectedly. For instance, if bank X has credited the accounts of its customers (the merchants) while waiting for bank Y to make an offsetting real cash transfer, and bank Y goes bankrupt (or is declared insolvent or whatever), then bank X is out that money. There are three possible solutions. One partial solution is to not treat e-cash as cash -- the balance does not become available at bank X until a settlement period has passed. At this point, you might as well stop calling it e-cash, and call it an e-check. It's still a non-trivial situation if the bank the check is written on goes belly-up, but there is less exposure to fraud, with an offsetting nervousness on the part of the merchant that the e-check will bounce. The second possibility is for all the clearing house members to trust some central entity to handle the clearing and insulate them from the bankruptcy of the individual members. This is how Fedwire works, and it is arguably simpler than various types of peer-to-peer clearing systems, but requires a great deal of trust in that central entity. It also could have more catastrophic consequences in the event of the failure of that central entity. The third is that X and Y belong to a clearing association. Banks might settle deficit positions with one another (a 'net' system), and could negotiate a certain deficit level with all others in the system. If a deficit was exceeded during the clearing, a partial settlement would be required from one member to another. A variant on this is the 'net-net' system, where banks are allowed a certain deficit position with respect to the clearing system as a whole, and losses are shared according to some formula in the event of a bankruptcy. Settlement is done by a bank's paying into (or receiving from) the system according to its position at the end of the settlement period. This doesn't sound too complex, until you start to read the relevant parts of the Uniform Commercial Code. To paraphrase the docco for the xterm source code, "If you think you understand this right away, you probably don't. It is a hideous mess." The question of what should happen to e-cash caught in the flux of the bankruptcy of a member of an e-cash clearing association is not immediately clear and is every bit as important a question as the specification of the computer protocols. It involves careful contemplation of the relevant law, carefully construted contractural arrangements, and robust, well-written software. Note that it becomes almost exponentially dicier when you try to scale it to an international level (assuming you want to try to continue to work within the legal frameworks of the various countries, and probably even if you don't want to.) Now, take bankruptcy, and replace it with "systematic fraud." Suppose that the same fine type of folks who got involved in S&Ls get into e-cash in a big way... the mind boggles.