Pay per use remailers and remailer reliability tracking.

[Steve Schear]

At 04:51 PM 12/19/2001 -0800, Len Sassaman wrote:

<snip>

>"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 one assumes that delivery failures between remailers are the exception 
rather than the rule then remailers could publish delivery failure 
notifications in message pools (e.g., Usenet alt.anon.messages) encrypted 
with a sender provided key and subject line.  The user's remailer client 
could then scan the group for the subject line to detect problems.


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

One important aspect of preserving the efficacy of a bearer token based 
value system is fraud prevention.  If the tokens are to be exchangeable for 
outside value (e.g., dollars) then there must be effective way to prevent 
the purchaser from defrauding the mint.  There has been considerable debate 
on the "e-gold Discussion" <e-gold-list at talk.e-gold.com> list on the risks 
of accepting other payment forms for e-gold (which generally cannot be 
repudiated).  One e-gold market maker, particularly stung by cheats, made 
some recommendations 
http://www.gold-age.net/ldf/ThemeStreamArticle-01-2001.html

                                                    'May Scale' of monetary 
hardness
Hardness        Item
1                    Street cash, US dollars
(Hard)
2                   Street cash, euro currencies, japan
3                   e-gold
4                   Street cash, other regions
5                   Interbank transfers of various sorts (wires etc), bank 
checks
6                   personal checks
7                  Consumer-level electronic account transfers (eg bPay)
8                  Business-account-level retail transfer systems
(Soft)
9                   Paypal and similar 'new money' entities, beenz
10                 Credit cards
(Ridiculously soft)

Observe that say stock brokerages definitely do not accept credit cards or 
paypal to fund an account. They will only accept instruments that are very 
hard, such as wire transfers or certified bank checks. When hard money is 
required, only money-types with a hardness of about 5 or better will do the 
job.   Observe though that even money order and bank wires can and have 
been reversed.