Re: Voice/Fax Checks
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
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
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. There are more categories than these, actually. There's already a banking distinction between large and very large. One of the high end funds transfer systems in the world has a _minimum_ transaction size of about two million dollars. You can bet that these are handled differently than a one thousand dollar check (still "large"). In addition to direct costs of provision, there are also effective costs of collection risk. At each level, these collection risks have to be estimated and taken into account. Since the real desire is for a known upper bound, some fraud or other form of transaction failure can be expected. When credit is being offered (even intra-day), the risk increases proportionally. Every off-line system offers some amount of credit, however small. 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. You can still use an account mechanism, but with an intermediary whose business it is to aggregate small amounts as these proposed and clear the total periodically. That's now one account setup for the customer. Eric
participants (3)
-
Hal -
hughes＠ah.com -
solman＠MIT.EDU