Brands excluded from digicash beta
-----BEGIN PGP SIGNED MESSAGE----- Last month I complained that my multiple attempts to request an account to try out the digicash beta-test ecash system had been ignored. I got half a dozen replies from people who had had exactly the same experience. Shortly afterwards, though, I got email from digicash saying that my account would be activated in a few days. This was on Oct. 21, and I have heard nothing since then. I just figured that I didn't have enough clout for them to bother to respond to me, but today on the www-buyinfo list, Stefan Brands, who many think has the best ecash technology available today, posted that he had had the same experience! Brands himself has still not been given an opportunity to join the beta test. He did not sound very happy about this. I can see that Chaum and Brands are potential competitors to an extent; they both have or will soon have patents which will be necessary for efficient offline systems. But it is clear to me that some form of cross licensing is going to be necessary to have a really clear patent situation. Under the circumstances it seems silly for Chaum to antagonize such an important player in the game. Of course, it may well be a matter of incompetence rather than insult, but the net result is the same. The more I see of digicash's lack of consideration towards their potential customers and important figures like Brands the more I question whether they have the potential to succeed. Hal -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAwUBLt35LhnMLJtOy9MBAQEyPwIA7gDKNK7T+vCp1I+YnUrsDb1sDhTWFO4T olTEgTZnLtbQMLe70bNni2jjL0SShFqHRpSNZbsEPt0UAdmf5Pcf+A== =MZXU -----END PGP SIGNATURE-----
I also have had no luck getting a beta client from digicash. I "registered" through their WWW forms page, and got no response for about a month. Then they sent me mail saying that they would be sending a client, but that they were unrolling it in stages. That was about a month ago. Perhaps this means I will get my client soon. This does not speak well for digicash. If they were not ready to beta their stuff, they should not have announced it. As it is, it makes them look like a flake. BTW, I am beginning to amass NexusBucks. I would _really_ like to buy something with them, just to prove their viability. They are exchangable 1-for-1 for US$, but only in terms of services on Sameer's system. If anyone has a t-shirt or somehting similar that they'd like to sell, please let me know. Perhaps we should make the Cypherpunks motto a bit less ambitious. Instead of "Cypherpunks write code," how about merely "Cypherpunks use tools." Raph
-----BEGIN PGP SIGNED MESSAGE----- I'm going to tie together two threads on ecash: one here (Hal and Rishab have both mentioned the ecash system test recently) and one from www-buyinfo about scalability. If you dislike ecash, hit 'n' now I'm running one of the prototype shops (http://www.iquest.com/~fairgate), so let me chime in with my e$0.02 of comments. (no, that doesn't mean I'll pay you e$0.02 to read them!) Hal said:
I just figured that I didn't have enough clout for them to bother to respond to me, but today on the www-buyinfo list, Stefan Brands, who many think has the best ecash technology available today, posted that he had had the same experience! Brands himself has still not been given an opportunity to join the beta test. He did not sound very happy about this.
I was in the same boat-- I sent in several requests, all of which were ignored. After Digicash issued a call for prototype shops, I signed up. WHAM. I immediately started getting mail asking when I'd have my shop ready-- sometimes two or three messages a day. Once I got everything up and running, I didn't hear further from them. Since then, an accident on my WWW server has rendered the e-shop inoperable. I've asked Digicash, in the form of Paul Diniessen, for help reconstructing the bank records. No go.
Of course, it may well be a matter of incompetence rather than insult, but the net result is the same. The more I see of digicash's lack of consideration towards their potential customers and important figures like Brands the more I question whether they have the potential to succeed.
The more I deal with Digicash, the better First Virtual looks. My technical preference is for using Brands or Chaum cash; at present, though, there aren't any shipping Brands servers, and the Digicash folks don't seem to be able to get all their socks in one bag. Digicash's system doesn't scale entirely cleanly, but it's Good Enough if there's one central bank which all other banks can use, just as the credit card companies have a central clearinghouse which allows my credit union Visa to be used with merchants whose accounts are at Citibank. The problems with Digicash thus far have been political and business problems, not technical ones. 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. - -Paul - -- Paul Robichaux, KD4JZG | Good software engineering doesn't reduce the perobich@ingr.com | amount of work you put into a product; it just Not speaking for Intergraph. | redistributes it differently. ### http://www.intergraph.com ### -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLt44Xafb4pLe9tolAQH4AgP/U93rIqM73vBYb/wByCjfBDENuYKTSRe4 C4sRzMt6mgFqs/RSeTczA4x8CZi/ytVw5zjN4ApWuWC9BZpnSrHjBxls/pwRwhGB 2OrViy5jVYtlJ+v78JemsZhiKqOBU2bZ0TDWYVmSKcvWN20fG3fri77lKrpMpYT1 feNB7+T+Q1w= =SZ9T -----END PGP SIGNATURE-----
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
-----BEGIN PGP SIGNED MESSAGE-----
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...
I've asked them to say something. The best I could get out of Paul Dineissen is that they're talking with banks. Well, duh. The _present_ reality is that I can sell things ** and get paid ** if I use First Virtual, but not if I use ecash.
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.
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'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. - -Paul - -- Paul Robichaux, KD4JZG | Good software engineering doesn't reduce the perobich@ingr.com | amount of work you put into a product; it just Not speaking for Intergraph. | redistributes it differently. ### http://www.intergraph.com ### -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLt5Hxqfb4pLe9tolAQGA0gQAgd8BcSVu199NjEx3uMq4/ZrtaRA34z/g X/VOMOIfUOuftj2wIiF5iVM5CMOoxMUz4J3gPESIOjZnVEtDUsfsD5aCtTuJW+39 Dmmjkm1nlTynDag7A0tsW39AfqGCpWy4gqcgwhHrvUvKt2Tts/XkvFwkT/wjLM0f 3reNbfPMSZY= =y4mZ -----END PGP SIGNATURE-----
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 Robichaux writes
I'm sure that the design of a robust, usable [clearing] 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.
The tools will be vastly simpler and smaller than Fedwire, etc but the system will be vastly larger an more complex than Fedwire etc, because "the system" will consist of many diverse people using these tools in diverse ways for diverse purposes. Attempts to design an all encompassing well organized system run counter to the way the internet works and are therefore likely to fail. If it does not work by spontaneous order, it probably will not work. Regrettably, there is an obvious conflict between full and true anonymity, and spontaneous order. On the other hand, absent a centralized system, anonymity is less critical. -- --------------------------------------------------------------------- We have the right to defend ourselves and our property, because of the kind of animals that we James A. Donald are. True law derives from this right, not from the arbitrary power of the omnipotent state. jamesd@acm.org
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.
participants (6)
-
db@Tadpole.COM -
Hal -
jamesd@netcom.com -
mccoy@io.com -
paul@poboy.b17c.ingr.com -
raph@netcom.com