1996-06-21 - Re: Recipients get the postage

Header Data

From: shamrock@netcom.com (Lucky Green)
To: cypherpunks@toad.com
Message Hash: f4fefd668fe56673651bf95ad7e098541930a1a97751ae4e118e3e2a87112da7
Message ID: <v02120d78adf01a8ebfbd@[192.0.2.1]>
Reply To: N/A
UTC Datetime: 1996-06-21 21:48:51 UTC
Raw Date: Sat, 22 Jun 1996 05:48:51 +0800

Raw message

From: shamrock@netcom.com (Lucky Green)
Date: Sat, 22 Jun 1996 05:48:51 +0800
To: cypherpunks@toad.com
Subject: Re: Recipients get the postage
Message-ID: <v02120d78adf01a8ebfbd@[192.0.2.1]>
MIME-Version: 1.0
Content-Type: text/plain


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.







Thread