-----BEGIN PGP SIGNED MESSAGE----- [It is with some trepidation that I try, for the third time, to send this to the list. Ever since I tried the first time my email to the list has silently failed. This is pretty strange, given the topic of the mail!] If we have digital cash, we may want to send it through the mail. Sending regular cash through regular mail is not safe, as we all know. The cash could get lost or stolen. With digital cash, stealing can be made less of a problem; it can be encrypted with the public key of the person who wants to receive it. But loss is still a problem. Email is not perfectly reliable. All too often we experience mail bounces, errors, or mysterious disappearances. Given the heterogenous nature of the net and the many systems through which mail must often pass, this is not too surprising. People have to learn to adapt to the vagaries and inconsistencies involved and take special care when they are sending something important. (I've been trying for the last three days to send a particular message (part 7 of a 13-part archive) from my school account to my work account. So far I've sent it three times. I'm hoping it will come through today.) With digital cash, this problem will come to the fore. Many people never send anything too important through email, but once they start sending cash, they will care if it disappears. Losing money gets people's attention. The solution, generally, is to keep a copy of whatever important mail you send, so that you can re-send it if it doesn't appear. Then, if and when you get confirmation that the mail has arrived, you can delete the copy. It will complicate any implementation of digital cash if it has to be aware of and concerned with this problem. The protocols involved with a secure cash system can be complicated enough on their own without having also to deal with an unreliable transport system. My suggestion is that this problem should be solved at the level of the email system. There should be a protocol for reliable email. Software to implement reliable email would save copies of outgoing mail, automatically send receipts when mail arrives, re-send mail which does not arrive after a certain period of time, handle duplicate mail arrivals, and so on. It would present to the user a model of an email system which is reliable as far as message delivery. All the issues of dealing with an unreliable network would be hidden by the reliable email system. This would be analogous to how network protocols implement reliable stream connections on top of unreliable datagram packet connections. Imagine how difficult it would be to write network software if all we had to work with were unreliable packets. The stream abstraction makes it far easier to use the network. It lets programmers concentrate on the protocols specific to their application. Reliable email would have advantages beyond digital cash, of course. As we move to a world where more commercial data travels on the network the impact of lost email will increase. I'm sure we can all think of applications which would benefit from a truly reliable mail model. I recognize that implementing reliable email would not be easy given the vast range of mail agents which exist on the net. I think the first step would be to specify a protocol for receipt and re-transmission so that "reliable-aware" mail agents would have the tools needed to implement the reliable transmission. Then it would be a matter of time and user pressure to get this support built into more mail agents. The real point of my suggestion is that implementors of digital cash should not worry about message transmission. I was trying to work out a dcash system some time back and this became a big headache - when to safely delete a digital "banknote" which had been sent to a vendor. My feeling now is that the digital cash system should ignore this problem, encouraging users to put pressure on their email servers to provide them with reliable mail. Hal Finney hfinney@shell.portal.com -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLMFPPKgTA69YIUw3AQEWoQQAg5v20Y4yZkd2GAF0hZgcRAHG30sJcAXS zDhc7qNesbkR2o7ym7f84Z2zxHE/q6UOf50mWLJn5/dU79HLmwvwtlzq8RfCSy1A UsYtaAk23Nh+pMjUTxUYrCVt3IgvlcbC+qP/+hOyIixgANgv96bKZXRWnUmovpof vtGYytp0qv4= =3RLN -----END PGP SIGNATURE-----