1993-03-01 - Future of anonymity (short-term vs. long-term)

Header Data

From: Eric Hughes <hughes@soda.berkeley.edu>
To: cypherpunks@toad.com
Message Hash: bbd606c4fb9bf27c122612d5d1609cd20b8389b313e43e1438cae61fb059e7a6
Message ID: <9303010148.AA16696@soda.berkeley.edu>
Reply To: <9303010103.AA08082@toad.com>
UTC Datetime: 1993-03-01 01:51:38 UTC
Raw Date: Sun, 28 Feb 93 17:51:38 PST

Raw message

From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Sun, 28 Feb 93 17:51:38 PST
To: cypherpunks@toad.com
Subject: Future of anonymity (short-term vs. long-term)
In-Reply-To: <9303010103.AA08082@toad.com>
Message-ID: <9303010148.AA16696@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain

Marc's short-term suggestion of bandwidth limiting from a particular
source seems like a reasonable exigency.  Let me suggest a way of
doing that which does not require keeping long-term logs.

Suppose your bandwidth limiter kept totals of all bytes sent in the
last week.  In order to keep that data current, it needs to know when
to remove byte counts that are a week old.  Thus it needs to keep logs
of the last week's worth of messages, at least in byte count form.

Instead of that, you can just make the byte count decay.  Once a day,
a process goes through the byte counts and reduces them.  Remove any
entries are <= 0.  If this decaying byte count is bigger than some
threshold, bounce the message.

I would suggest that the reduction equation be linear: multiply by
some constant between one and zero, and subtract off a fixed amount,
drop the fractional part.  The multiplicative factor, which I would
set between .9 and 1.0, means that an occasional large file could be
sent through without completely eliminating email delivery for a
while.  The subtractive amount cleans out the database more quickly.