Pay per use remailers and remailer reliability tracking.

[Len Sassaman]

Dear Cypherpunks and other unsavory characters,

I was recapping for some other remops a conversation that Tim sparked at
the last cypherpunks meeting regarding pay-per-use remailers, and I had
some additional thoughts. I'm not an expert on digital cash, so please
pardon me if I make any obvious errors. I welcome criticism of these ideas
and explanations as to why they won't work as well as tips for
improvement.

I've been thinking about how to create pay-per-use remailers for some
time. The reasons for needing a remailer payment system are obvious: aside
from handling spamming and flooding, it would encourage more people to run
remailers. If a remailer operator can expect to make money off of a
remailer, or at least recoup his losses, he's more likely to do so.
(Discussion of how liability changes when money is involved is for a
different time.)

"Digital cash" in the traditional sense isn't necessary for a pay-per-use
remailer system. Like MojoNation, I am going to refer to the digital cash
coins as something that has no monetary value in the traditional sense.
Tim pointed out at the last meeting that what we think of as "money" has
no inherent value. If you think of the remailer digital cash coins as
tokens with a very specific purpose, a lot of the objections to using
digital cash disappear.

Additionally, I am assuming that there would be a suitable digital cash
algorithm that could be used for these purposes. I am aware that there are
algorithms similar to Chaum's in existence, but my level of knowledge
isn't sufficient to know if they would work for these purposes. In any
event, the Chaum patents expire soon enough. In this scheme, while the
anonymity of the token buyer is essential, neither the bank nor the seller
will have their anonymity protected.


The system would work as follows, from the point of view of the user:

The user would purchase remailer tokens (digital cash) from a token vendor
(the bank). This is an exchange similar to car wash tokens or
TicketMaster[tm], where the seller receives "real cash" and the buyer
receives a tangible promise of a future service. The tokens could be
purchased online using PayPal, credit cards, etc. (Yes, this means the
number of paying remailer customers must be large enough to constitute a
crowd.)

The user than fires up his remailer client, and each remailer has pricing
and token service information associated with its key and reliability
stats. (In this system, multiple token vendors could exist, and remailers
could be their own vendors. For simplicity's sake, I am going to assume
that all remailers in this user's client accept the same ticket vendor's
tokens.)

Each remailer sets a price (i.e., number of tokens) for its use. Remailers
could even charge a different amount depending on where in the chain it
fell, with exit hop services costing more than beginning/middle chain
positions. The user would select his chain based on the reliability stats
and the pricing information for each remailer. The client would tally the
cost, and when the user approved, it would remove tokens from the user's
"purse" and attach them to the outgoing message, interwoven in the various
layers of encryption in the message.

Now, from the remailer's point of view:

A message is received, and the encryption stripped off. Inside is a
remailer token, which the remailer redeems with the token vendor after
ensuring that the token covered the price of the message (accumulating a
balance in his account, which can then be exchanged for cash by the
remop.) The message is then delivered to the next hop, and so forth.


I came up with this idea after an interesting conversation with Bram Cohen
one night, and then after researching it realized that others had said
basically the same thing. I'm interested in hearing problems with the
above proposal, but for now I am going to assume it is sound. I have a
further enhancement to this system that I just now realized might be
possible, and this is what I'm really interested in discussing.

One of the big problems with remailers currently is reliability. We can
attempt to make remailer software more stable, place remailers on better,
faster systems, add message redundancy to the protocol, etc., and we still
don't eliminate the major flaw receipt verification. There is no way to
report back to a message sender that a message did not make delivery, so
when something does go wrong, the end user rarely has any idea why. Hal
Finney discussed this, and a possible solution to the problem, here:
http://nymip.velvet.com/pipermail/nymip-res-group/2001-August/000146.html

If a system as I have described above were to be implemented, we could
solve this problem (as well as the inevitable problems of remailers
cheating and collecting payment without delivering mail, and the problem
of double-spending) without having to reveal any useful information to an
attacker who doesn't already have ability to observe the entire mix
network.

If the remailer client were to keep track of which tokens were paid to
which remailer, the user could determine where in a chain message delivery
failed, or if the message exited the last hop (not exactly the same as if
it was delivered, but close. The last remailer could cheat, or the
recipient's mail server could fail. There's ways to improve this, though.)

After the remailer redeems the token with the token vendor, the token
vendor publishes the token. No one but the user and the remailer know
which message a given token was linked to, so information leakage is
minimized. The user can query the token vendor for the most recent token
redemptions, and will be able to determine where his message either is
currently waiting in the chain, or where it died.

(This isn't exact either. Failure, in this case, is pinpointed at the link
between two remailers, rather than at a given remailer. If a user queried
the bank and discovered that, out of a 5 remailer chain, remailers A, B,
and C redeemed the tokens but D did not, this either means C is cheating,
C is broken on sending, or D is broken on receiving. Further tests would
be necessary to determine the exact nature of the failure.)

Does anyone have any thoughts on this? Reasons why the payment system
would not work? Reasons why the verification system would not work?
Improvements to either system? Thoughts on the specifics of the digital
cash algorithms needed?



--Len.