RISKS of using email for dcash

[nobody@alumni.cco.caltech.edu]

-----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-----