Pay per use remailers and remailer reliability tracking.

Tim May tcmay at got.net
Wed Dec 19 23:33:54 PST 2001


On Wednesday, December 19, 2001, at 04:51 PM, Len Sassaman wrote:

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

Indeed, we can talk about how money affects liability another time. (But 
I will add that many people here and on the Net have a wrong-headed 
notion that "if you don't charge money, you are protected." This doesn't 
work with software piracy cases, this doesn't work with trespassing in 
physical or cyberspaces, and so on. "Not charging money" is not the 
cloak of protection some seem to think it is.)

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

Yes, coupons or tokens (like subway tokens, like casino chips, though 
these are not the same thing) can be used in ways that  don't require 
"true digital money" (say what? I will argue later that "true digital 
money" is a misleading meme).

Even Magic Money (circa 1993, Pr0duct Cypher) or Tacky Tokens (approx. 
ditto) would be an interesting experiment.

Even tokens _specific_ to the remailer! ("Use of this remailer costs 1 
Melon"). Mixing tokens as a crude way to anonymize is possible.

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

Yes, Chaum happens to be sort of right in this particular case: the 
identity of the remailer is assumed to be traceable (because remailers 
usually operate openly), hence only buyer-untraceability is required, 
hence Chaum Version 2 ecash is OK. Anonymous remailers are possible, 
using broadcast or "message pool" models. For example, sending a message 
to alt.anonymous.messages and having remailers scan the pool for 
messages they can decrypt. This then requires seller-anonymity as well. 
Solvable.

Agnostic digital cash (a la Barnes) could be deployed for remailers 
without an extensive "digital cash infrastructure" involving banks.

One of the reasons I wanted to have a CP meeting focused on implementing 
Chaum protocols without the niceties of licensing from Chaum (or the 
Canadians who now own the patents) was to do this. Alas, our meeting 
went off into other directions....some of you were at that meeting last 
summer.

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

Yes, this is how markets for remailing services would likely develop. 
All of the usual stuff about price discovery, competition, discounts, 
advertising, etc.

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

I am painfully aware of the negative effects of saying "That's an old 
idea."

But, of course, it is. No big deal, as it's all the way a paid remailer 
system would almost certainly have to operate. (Multiply-nested, with 
tokens obviously also nested...has to be this way.)

This is how we modeled paid remailers at the very first physical 
meeting, in fact. (We used envelopes within envelopes to model nested, 
chained encryption/remailing, and we used Monopoly money to model 
payments at each stage. The simulated remailer operators even advertised 
discount prices...)

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

This sounds likes a good line of thinking.



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

I wish you the best of luck and encourage others to help.

We old-timers are accused of saying "That's been thought of before." 
Only because the outlines of these things unfolded pretty quickly (see 
the 1992-93 list traffic, for example).

But true progress has historically come when someone pushed the 
implementation, as with the earliest remailers themselves, and later 
remailer sytems like Mixmaster.

A token-based remailer system, while an "obvious" system, would be a 
major accomplishment.

--Tim May
"As my father told me long ago, the objective is not to convince someone
  with your arguments but to provide the arguments with which he later
  convinces himself." -- David Friedman





More information about the cypherpunks-legacy mailing list