On Wed, 19 Dec 2001, Len Sassaman wrote:
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 importance of having a large number of remailer users is made even greater by this system. While it might be easy for a TLA to monitor all network traffic and compile a list of all remailer users, having a bank make that list for them in an easily subpoena-able form saves them some work.
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.
Not to say that you should not implement hashcash in remailers, but is it really necessary that these two features be linked? Thinking about this further, could you not implement the tracking system using random client-generated tokens that the user generated, the remailer published, and were meaningless to anyone else? One problem with this sort of system that springs to mind immediately is the need for user assurance that the tracking tokens are not being used as a covert channel. -MW-