Well here are the answers that I'm working with in my model:

Example 1, the fractional-cent transaction, will be tough to address by any technology IMO. Even with ecash, there are a lot of questions. Is it on- line or off-line? Does the server actually try to validate each half-cent or does it just trust people? If the latter, how much fraud is likely, and how would we track down and penalize the half-cent counterfeiters? Solving these problems is going to add overhead which will make it hard to deal with such small sums efficiently. How many cash businesses sell low-value items for pennies today? Not many.

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. If two people try to record the same payment, the person who records it first (according to a distributed byzantine agreement algorithm) gets the money. Now if its a small amount, you can feel comfortable dealing with it off-line. If its a large amount, you want to hold off closing the transaction until you get confirmation that the payment which you recorded has been accepted by the majority as the first. Clearly this is not at all simple, but it is provably do-able. And its my attempt to do this that led me to join this list (although the complex parts have turned out to be dealing with the perfect hashing that makes things scalable and not cryptography.) 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. So effectively, tiny transactions are taken care of differently (although there is no reason why this has to be the case other than efficiency [you actually have to pay the global community for validating everything so it is simply cheaper to use account based ecash]).

...

Isn't the point of digital cash that you *can* send it through unsecure mail and buy things?

No, I don't think you can. Ecash can generally be cashed by the bearer so it has to be sent through secure mail. That is why I was saying that echecks might be better for those purposes.

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.

I don't understand the Telescript agent world well enough to judge whether it would drive a market for ecash. I have the impression that at least with the initial implementations the agents will not be on the Internet as we know it but rather on a separate AT&T network of special servers. So they may not have much impact for a while on the "net" as we know it.

Where can I find information about telescript? JWS