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.
Well I've only got small implemented right now, so I guess that's where things are focused now. Whether there is more medium or large depends on how comfortable vendors feel with their customers. I imagine that certification agencies will develope using my primitives, that will certify (by betting money on it) that certain people are likely not trying to double spend. Economics will sort things out. People will chose whatever form makes them the most money.
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.
Well, I'm expecting a major shift in how people view transactions once the agents are available to obscure the details. The account based money is intended to support a market based system whereby competing bits of information and advertisements vie for the user's attention. In this sort of system there are LOTS of tiny transactions on one system. Also, I don't expect the large scale money transactions to wind up costing more than a penny or less after everything is set up. The problem is that initially there will be few transactions to amortize processing and communications costs over. When there are large numbers of transactions occuring, even the medium/large scale transactions will be cheap.
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?
In systems like this, a bank initially issues the user a license. The bank verifies the identity of the user and issues him a license authenticated by the bank in a manner that prevents the bank from knowing which license the user got... unless the user cheats at a latter time in which case the vendor which knows the license and the bank which knows the ID will each find out the other and track down the user. Okamoto and Ohta proposed a centralized one of these in Crypto '91. I'm using some results from papers on minimalist and dynamic hashing functions (two groups that do not normally get along well) to create a truly distributed analog to this system. JWS