A few days ago I got my ecash account set up with the Mark Twain bank. Presently only one merchant is officially listed at <URL: http://www.marktwain.com/shops.html>, Delorie Software. As I understand it, only people with merchant accounts are eligible to be listed here. However, you don't have to have a merchant account to receive ecash or to set up shop software. If anyone else has set up a shop to receive Mark Twain ecash using a user account, perhaps they could post here and we could keep a list of unofficial vendors. The other thing I wanted to write about is ecash speed. One idea people have had is to use ecash for micropayments, such as one cent to read a web page. The question is, is the current ecash software sufficiently fast for this? Maybe someone could set up a site using either Twain ecash or DigiCash ecash which actually charged you a penny for each page you browsed around. It would be interesting to see how much of an obstacle it presents in browsing the web. The impression I've had from the few times I've used ecash is that in fact it does slow things down way too much for this to be practical. But it would be good to actually do the experiment. One reason I was thinking about this is reading a new paper by Rivest and Shamir, <URL:http://theory.lcs.mit.edu/~rivest/RivestShamir-mpay.ps>. It is about a couple of proposed systems for micropayments, specifically oriented towards the penny-per-web-page model. They are offline systems, designed so that a minimum of calculation is done by the vendor, user and bank. So they should be very efficient. However, the big problem is that they are not anonymous. The cash tokens are recognizable by the bank when spent tokens are sent in by the vendors - the bank knows who spent them. Maybe for penny level transactions that is not a big deal, although if for-pay web browsing becomes common then it does seem like it would present a privacy threat. Every web site you visit (not the specific pages, but the overall site names) would be known by the bank - quite a significant piece of marketing data. The point is that if the anonymity afforded by ecash is too costly in terms of time, then we may end up stuck with a non-anonymous system simply because that is the only one efficient enough to work. It would be good to find out if that is a serious problem. Hal Finney
Hal writes:
The point is that if the anonymity afforded by ecash is too costly in terms of time, then we may end up stuck with a non-anonymous system simply because that is the only one efficient enough to work. It would be good to find out if that is a serious problem.
I suspect that as CPU speed exponentiates this will become less and less of a problem. It doesn't especially worry me. Perry
"Perry E. Metzger" <perry@piermont.com> writes:
Hal writes:
The point is that if the anonymity afforded by ecash is too costly in terms of time, then we may end up stuck with a non-anonymous system simply because that is the only one efficient enough to work. It would be good to find out if that is a serious problem.
I suspect that as CPU speed exponentiates this will become less and less of a problem. It doesn't especially worry me.
Consider, though, what happens in the current ecash system if it were used to charge a penny per page. You would click on a link in your web browser to go to the new page. It would set the GET request to the remote server as usual. The server would fire up a CGI script which will run the shop software. That software will make a TCP stream connection back to your ecash wallet software which is running on the system where your client is. It sends a request to get payed $.01. Assuming the wallet is configured to automatically approve such a payment, it will send a one penny coin to the shop software along the opened link. (This may also involve doing a PK encryption on the coin as an anti-theft measure; this aspect of the current ecash system is not documented AFAIK.) The shop software then opens a TCP stream connection to the bank, and forwards the coin there. The bank receives it, and checks the public key signature in the coin. It then compares the coin against every other coin which has ever been spent (within the validity period of the coin) to make sure it is not being doubly spent. If this all checks out it sends back some authentication message to the original server. The shop software then delivers the new page to the client browser. This all has to happen whenever you click on a link in your browser. Even with fast CPU's I think the extra step of connecting to the bank, having it check against all coins, and getting approval will be considerable for each link traversal. Hal
Hal writes:
This all has to happen whenever you click on a link in your browser. Even with fast CPU's I think the extra step of connecting to the bank, having it check against all coins, and getting approval will be considerable for each link traversal.
A system like Stephen Brands' should significantly improve the situation. There's no benefit in double-spending micropayments since you'll be identified after the fact. For small enough payments, you can skip the on-line validation and handle them in batch-mode later. It becomes a matter of risk management, then.
Hal writes:
"Perry E. Metzger" <perry@piermont.com> writes:
Hal writes:
The point is that if the anonymity afforded by ecash is too costly in terms of time, then we may end up stuck with a non-anonymous system simply because that is the only one efficient enough to work. It would be good to find out if that is a serious problem.
I suspect that as CPU speed exponentiates this will become less and less of a problem. It doesn't especially worry me.
Consider, though, what happens in the current ecash system if it were used to charge a penny per page. [Describes lots of steps...]
I'm really not that convinced that this is a problem in either direction. With users everywhere on the net connected via multi-megabit per second links, high speed CPUs, etc, a few extra TCP connections and RSA operations really might not be noticed in a half dozen years.
This all has to happen whenever you click on a link in your browser. Even with fast CPU's I think the extra step of connecting to the bank, having it check against all coins, and getting approval will be considerable for each link traversal.
Again, I'm not convinced either way. I believe we have to wait and see how fast things really are in practice. Perry
participants (3)
-
Hal -
Perry E. Metzger -
Scott Brickner