-----BEGIN PGP SIGNED MESSAGE----- I agree with Mike Ingle's points re NetCash. I had some pretty strong criticisms of their proposal when it first came out. They didn't seem too familiar with the literature on digital cash. Their system was more like cashier's checks than cash. The anonymity was not strong. Nick has some interesting ideas re the use of "reputation capital" to discourage double-spending of dcash. You wouldn't want to destroy your reputation by cheating on a small sum of money, not if the reputation was one which you had built up over a period of time. In considering these ideas, there are a lot of questions about the whole infrastructure in which the dcash is being used. Is this something which we would see occuring in the near future, the next couple of years, in which case current systems of electronic communication would be used? In that case, we might imagine people purchasing items via the more progressive on-line services, like the new MUD-based systems people are working on (metaverse, virtual city, ...). Or companies might simply advertise items for sale on the internet and accept orders by email or perhaps TCP connection. One technical detail is that dcash systems require a multi-step protocol for spending and withdrawal. This would make email orders more difficult to deal with since mail would have to bounce back and forth. Actually, Chaum's simplest dcash scheme has a one-step protocol for spending (just send the cash), but that requires on-line verification. TCP connections can handle the back-and-forth very quickly so that may be a preferred communications method. Today, most credit card transactions do an on-line check, so I don't think that on-line systems should be ruled out, although eventually a dedicated network separate from the internet would probably be needed. The total data transfer per transaction is not large, a few hundred bytes. One question in considering whether double-spending is likely to be a problem is whether bank accounts are anonymous. One possible system is for bank accounts to be non-anonymous, but for transactions to be untraceable. Then if someone double-spends the cheating is traced, not to a "nym", but to a real person. (There is still the possibility Mike raised of stealing someone's cash, similar to how you might steal someone's PGP secret key today, but perhaps this will not occur often enough to be a problem.) In this case you don't have to have an infrastructure of reputations and credit ratings in order to use the cash. Nick's idea sounds like it would take some time to develop. Our hundreds of years of experience in giving credit will require some readjustement to a world in which "nyms" can disappear much more easily than physical people can. Another technical detail with the two forms of digital cash that I am more familiar with, Chaum's on-line and off-line systems from his Crypto 88 paper, is that even the off-line system requires the vendor to communicate with the bank for every transaction. He has to send in the spent cash, as well as the results of his protocol with the customer, for every piece of cash he gets. The difference is that he doesn't have to do it right away. So this off-line system will actually require more bandwidth for communication with the bank than Chaum's on-line system would (because of the extra transaction information that has to be sent). It seems that on-line and off-line cash systems both have pros and cons. Initially my feeling is that an on-line system might be preferable because there is less need for trust between the parties involved. Each person checks at each stage to make sure he is not being cheated. There is no need for a legal system to prove double-spending and force cheaters to make good. The protocols are much simpler and easier to understand. And the bandwidth requirements are less. The main disadvantage is the need for enough redundancy in the bank to allow continual accessibility, although even this would not be an issue for purchases which are delivered after a delay, typical of electronic purchases today. Hal Finney hfinney@shell.portal.com -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLN0b86gTA69YIUw3AQEw+wP/daSj1lrRoYB/YuXVq1JGVvqxANOwVEyb KeG53eOaauxn4BlhG6z7jMZYLeTJO1Ct045ZbeKwfgMEDKFyDJyfwquDz7VcgtQH 5N1E4yLRYiIyy6UEiIz6Vg2BLOp1yYqux4h/n6F13xY7HgXYSzHTwZAp+9UFvh5v lUxNkVkC8Tk= =n4aj -----END PGP SIGNATURE-----