cryptoanarchy.wiki

Arise, you have nothing to lose but your barbed wire fences!

1994-08-06 - Remailer ideas

Header Data

From: hughes@ah.com (Eric Hughes)
To: cypherpunks@toad.com
Message Hash: 5d0d37b0b2570246c91da04892c9e39de236424ddeea16104cad4d73232e612f
Message ID: <9408062331.AA17257@ah.com>
Reply To: <199408061724.NAA05169@bwh.harvard.edu>
UTC Datetime: 1994-08-06 23:59:46 UTC
Raw Date: Sat, 6 Aug 94 16:59:46 PDT

Raw message

From: hughes@ah.com (Eric Hughes)
Date: Sat, 6 Aug 94 16:59:46 PDT
To: cypherpunks@toad.com
Subject: Remailer ideas
In-Reply-To: <199408061724.NAA05169@bwh.harvard.edu>
Message-ID: <9408062331.AA17257@ah.com>
MIME-Version: 1.0
Content-Type: text/plain


	   On M/N reordering schemes: A relatively simple way to avoid
   the unlucky message sitting in the queue problem would be to store a
   timestamped, ordered list of messages waiting to go.

The key word in the above sentence is the word "unlucky".  When I
formalize the word unlucky, I get "expected value is arbitrarily close
to zero".  Therefore, I completely ignore this situation, because it
just doesn't happen often enough to worry about.

If you have a higher level protocol which corrects errors, then
staying in a mix too long is just another cause of failure.  It should
be tallied up with the rest of the causes of failure and then, once
its contribution to unreliability has been established, ignored.

The probabilistic reasoning which says that "the message will get out
with the following distribution of latencies" is perfectly fine, and
as long as the systemic consequences of late messages have a fixed
upper bound, the total effect of delayed messages does also.  Estimate
the damage, and if it's workable just don't worry about it.

And when I claim that some folks just empathize too much with that
poor little datagram who went on an incredible journey through lots of
out-of-the-way place to finally come home, well, I'm exactly half
joking.

Eric

Thread