Pay per use remailers and remailer reliability tracking.

[Nomen Nescio]

Len Sassaman writes:

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

This contradicts your previous point.  If the coins have no monetary
value, that is, they can't be spent for anything useful, then it will
not be possible to meet your objectives of allowing a remailer operator
to make money off his remailer or at least recoup his losses.  You can
give someone all the Monopoly money in the world and it won't encourage
them to go into the business.

And the real sticking point is if these remailer tokens are not based
on cash, how do the remailer users get them?  If they just send in a
request and are given them for free, then there is little point to the
whole exercise.  You could charge hashcash for them as was proposed
earlier, but then you might just as well use hashcash directly in the
remailer chain.

If the tokens are non-free, that will raise the costs of running pingers
and cover traffic.  Of the 5000 messages a large remailer handles per
day, surely the majority will fall into this category.  Making people
pay for remailers will drive down usage levels (by standard economics)
and make the remailers less secure.

Digital cash tokens must be checked in real time with the bank for
validity.  Otherwise you have a double spending problem.  (Hashcash
avoids this by embedding the payee in the token.)  That will increase
the complexity of the remailer, the amount of traffic it must support,
and give more information to eavesdroppers.

Clearly it is mandatory to use fully blinded cash/tokens for this
application.  For some situations blinding is not all that important,
but for remailer chains it is absolutely essential.  Otherwise the bank
would be able to trace messages through the remailer network.  Hence you
will run into the complicated patent situation which will exist at least
through 2005.

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

The same thing could be achieved by putting a nonce into each message
packet which the remailers would publish.  The user knows the chain of
nonces he used and can determine whether his message made it through
the remailer.  Something like this was suggested by John Gilmore several
years ago.

The bottom line is that while the idea is seductive, ultimately it
doesn't make sense.  Charging for remailers would make them harder to
use (adding the overhead of figuring out how to get tokens and possibly
paying for them), less secure (opening new lines of information for an
attacker), and less anonymous (since fewer people would use the network).
There are other, equally good methods for increasing remailer reliability.
Since people appear to be adequately motivated to run remailers even
without profits, there is no need to move to a system which would add
cash tokens with all of their attendant disadvantages.