At 22:27 6/20/96, Timothy C. May wrote:
Again, I always enjoy gedankenexperiments about digital postage. But I am chagrinned that nearly four years after the first remailers we are still operating in thought experiment mode for the most part.
I believe this is because there really is very little market at this time for anonymous remailings. Those who mostly use remailers appear to be willing to use casual-grade remailers, with few of the real Chaumian protections. And they are not very concerned about reliablity, cover traffic, etc.
While it is true that there is a relatively small market for remailers and therefore insufficient incentive to spend great efforts on developing for-pay remailers, there is a relatively simple technical modification to Ecash that might lower the development barrier to a level at which for-pay remailers may be deployed. Clearly, the task of designing a new remailer architecture as well as a payment system suitable for use in such an architecture is prohibitive at the current market size. If currently deployed remailer and payment systems could be modified to interoperate, developing for-pay remailers would be considerably easier. Unfortunately, there are technical reasons that have kept the two main contenders for building such a hybrid system, Mixmaster and Ecash, from interoperating in a smooth fashion. Mixmaster has certain constraints on the maximum number of bytes a potential payment sting can have. [Note: the constraint is in the Mixmaster header, it has nothing to do with total message size]. To stay within that limit, the client used to access the Ecash wallet would have to be able to specify the exact denominations of coins to be used to make a payment of a given amount. Neither DigiCash's current Ecash client, nor the recently released official Ecash API allow for this level of control over the composition of a payment. When there is a fully working implementation of Ecash that allows the detailed control required to create payment messages that Mixmaster can incorporate in its messages, implementing for-pay remailers should be trivial. It is difficult to predict at this time if such out of the box for-pay remailer will be commercially viable -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred. Disclaimer: My opinions are my own.