JWS writes:
Well here are the answers that I'm working with in my model:
First, what you set up has to work off-line. At the same time, validation, by its very nature, is a process that can only be accomplished online. The part of my code that I am in the middle of right now (and strugling with) uses a distributed dynamic hashing scheme (with some attempt at periodic space minimalization [this is what is making it tricky]) whereby information is recorded in the public system such that if one part of a bill is used twice, the cheat's identity is revealed. [...] For types of small transactions that will be executed frequently, the best idea is to establish accounts. In my system, when ever an agent enters somebody else's computer, it gives the local wizard (the agent with the final say on computational cycles, storage space, and communications) a deposit which neither the agent nor the wizard can cash without agreement by both [do public validation and recording but hold off on the last steps which allow the wizard to use the money]. The money is thus recorded globally as having been spoken for. Then, for all transactions on the local machine, the agent simply uses its local account, just as anybody would in a much simpler bank-based protocol, like the ones we have now.
This seems like a good approach for a lot of cases. You end up having three classes of transactions: small, medium, and large, with slightly different strategies for each. For large, you do on-line checking; for medium, you detect double-spending after the fact and use crypto to find his identity; and for small you set up an account and dip into that a bit at a time. I am curious about whether you are focussing more on some size range in your plans. One problem I still see is the small transaction where you don't tend to use the same provider again and again. On the net there are a few sites (well, quite a few, I suppose) which are heavily used, but there are a lot of places I might like to just browse through. Paying a penny per site isn't going to bother me much, but if I have to set up an account for each one ahead of time I'm probably not going to bother. So I still think there are problems with the fractional-cent-per-web-site model which I have been hearing about.
I don't agree on this point. I prefer license based e-cash which is modified on each transaction (and unfortunatelly gets slightly bigger -- the downside of this method). If we're going to make the conversion to ecash, we might as well make it as powerful as mathematics will allow.
Is this an approach where you determine to whom you will be sending the cash, then make it into a "check" which can only be spent by that recipient? Doesn't that require the bank's (cash issuer's) help? Or is this something else? Hal