Bob Hettinga <rah@shipwright.com> writes:
[metaphors, <html tags> snipped, do you _have_ to :-)]
Adam Back <aba@dcs.ex.ac.uk> writes:
How about this, rather than interface your ecash system with US dollars yourself through credit cards/ debit cards/ cheques / cash, just set up an entirely disconnected system.
Nah. I want to have real money backing it up. Any attempt to make money less negotiable reduces its usefulness. Remember the Soviet Ruble? An extreme example in the opposite direction, surely, but you get the idea.
It's not an attempt to make money less negotiable, though this is of course the effect. It's just another approach to avoiding the banking regulations. As you admit the market will take care of the exchange mechanism, it just adds inconvenience in locating the exchange mechanisms, and the stigma that the mechanisms are not official.
However this means you've got to trust the bank not to mint unlimited amounts of money for it's own use.
Right. That's why you have a separate trustee holding the reserve capital.
So now you get to trust the trustee. Doesn't seem like a big improvement.
Anyway, in the first stages, I claim a trustee should be an actual, real, um, "hoity-toity", bank. In the same way that SET and Cybercash and ATM machines "blind" their transactions through the host bank onto a settlement network to the customer's own bank, there can be sufficient blinding of the transaction through the trustee so that the only thing the trustee sees is a confirmation to pay and a settlement wire from the cash purchaser's bank.
I don't think VISA and friends want anonymous settlement, they like comprehensive transaction logs to keep people like FinCEN happy. You're not suggesting that SET offers anonymity are you? Anyway, I'm not against this initial approach necessarily. Once you've got one non-anonymous electronic payment system with low entry costs to obtaining both a merchant and a purchaser, and is widely accepted, you can boot strap an anonymous payment system off it. The net model is that it should be that a merchant and a customer account are the same, and can be had by filling in a web page in real time. However, aren't they trying to make big bucks out of merchant accounts? Will SET and Cybercash make it easier to be a merchant than it is to be a VISA merchant? Becoming a credit card merchant is a rather onerous expensive, slow process I hear.
Of course, at some point, the trustee can just hold other bearer certificates instead of keeping the issuer's reserves in book-entry assets. When there are other bearer certificates to hold, anyway...
You lost me there. Above you described the trustee's function as holding the ability to issue money to keep the bank honest. What _is_ a bearer certificate in this discussion? A digitally signed share certificate, or other representation of an unit of value? Who issues the bearer certificates? What does possesion of the bearer certificate represent in terms of ownership of assetts?
How you issue those certificates mechanically is not nearly as important as the fact that you *can* issue them uniquely. Ideas like hashcash and micromint work real well for very small transactions, for example, precisely because of the cost to generate the first one in the series, which forces you to print a whole bunch of subsequent ones to pay for the computational resources you've used.
Actually it's micromint which has the threshold function feature through use of k-way hashes, my hash cash is quite simple, and probably impractical to use as a basis for a currency you wished to connect to a real currency. There is a cost of printing hashcash coins, which can be made high (say a weeks CPU for a P100), but basically anyone can mint all the money they have CPU power for. This is interesting for throttling systematic abuse of limited net resources, and combining with a digicash system you could have transferability as well as anonymity. However the stability of the money supply is probably not up to it. It's kind of like allowing anyone to print money, but making it cost them in time only; the resources they already have.
However, once again, um, no offense, what cryptographic protocol you use to generate the certificate is the functional equivalent of <analogy-warning> doodling, the process which makes those complex graphic fills on paper currency which were designed to moire up any attempt to photoengrave a certificate copy. </analogy> The point is, you need cryptography for a digital bearer certificate market, but it's not sufficient to create that market.
You think you can create a digital bearer certificate market on the back of your architecture of issuers, and trustees. I don't see a great difference between this and a traditional bank. How is it going to reduce the per transaction overhead, and how is it in any way distributed. (I presume your term "geodisic" refers to a distributed value transfer system).
But if you've got multiple banks then you've got to have an exchange mechanism. The market could probably take care of this, setting exchange rates based on banks reputations.
Exactly. For instance, (hint, hint) if someone were to build Eudora/Netscape/Quicken plugins for FSTC electronic checks, and a plug-and-play deposit server for banks to receive them and convert them into ACH transactions, who says you need the ACH system to settle the checks anymore? All the different bank servers could just clear against themselves on the net at some point, cutting their ACH fees out completely. Someday.
What is an ACH transaction? A electronic bank clearing protocol? FSTC is Financial Securities Trading... electronic checks? Isn't this going to be just another electronic check, with full transaction log, and associated overhead, banking regulations giving banks enough effective monopoly to charge high handling fees? I don't find electronic checks that interesting. What we want is fully anonymous, ultra low transaction cost, transferable units of exchange. If we get that going (and obviously there are some people trying DigiCash, and a couple of others), the banks will become the obsolete dinasaurs they deserve to become. I think this would be a good outcome, and I'd rather see this happen than see anyone go to any great effort to get the banks involved. Let them stick to electronic "cash" systems (what a misuse of the word) based on credit cards and checks. See how that survives against _real_ distributed electronic cash with transaction costs 10 to 100 times lower, with 0 red tape barriers to entry for both sellers and buyers. This is what I find interesting. The net is becoming more and more important as an mechanism for information exchange in it's own right. This is why I think just cutting the ties with the physical world and having a payment system working now would be interesting. Deployment wins and all that. Hashcash is completely distributed; there is NO bank. You can not forge hash cash, you can not double spend hash cash. You can print as much hashcash as you have CPU time for. You can resell hashcash for real money on an unoffical exchange, or trade hashcash for different services.
However it would be nicer to have something which required no trust and which had no posssibility of cheating rather than relying on reputation to sort them out.
Actually, I think there is no such thing as finance without reputation. :-). I'd be very interested to see how you can prove otherwise...
I don't see any particular inherent reason why an electronic payment protocol can't be designed which requires no trust of the bank; at least it should be possible to arrange it so that the bank minting funds for it's own use will be detected. All you need is that the protocol is publically verifiable. Digicash already prevents double spending through the database of protocoins. Adam -- Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`