The problem of sending requests with HTL=1 to probe a node, and
the problem of minimum depth Hal pointed out are really just the
same problem for opposite ends, and can share the same solution.
Adam's "Random Death" idea doesn't have enough detail to actually
solve the problem, so I'm offering specifics here that might--
please tell me if you think this will work.

When receiving a message, if HTL is 2 or greater, decrement it.
If it is 1, apply the following:

Rec'd HTL       Probability     New HTL

1               60%             0 (and therefore timeout)
1               40%             1

That is, decrement it 60% of the time, leave it at 1 40% of
the time.  On the average, this is equivalent to subtracting
0.6 from HTL, so the message will eventually terminate (in fact,
it will take an extra hop 40% of the time, 2 extra hops 16%
of the time, 3 extra hops 6.4%...falling off rapidly.  But the
fact that it can sometimes take that many adds deniability.
There is always a full 40% likelihood that a request with HTL=1
getting fulfilled does not pinpoint the data, which ought to be
plausible enough deniability.  And you can't just send multiple
requests and use Bayes Theorem because the first request may
have cached the result from a downstream.  When the HTL _does_
go from 1 to 0, and the node does have the data, it can
introduce a small delay equal to a typical small message round
trip to a neighbor.  This will only be done once (since it is
only done when the data  is found), so it is not a big
performance penalty.

To solve the Depth problem, apply the same idea in reverse.
Depth starts at 1.  When a node receives a message with
depth greater than 1, it increments.  If it receives a
Depth of 1, it increments 60% of the time, and leaves it
at 1 40% of the time.

A node receiving a Depth=1 can only conclude that the node
sending the message was the originator with 60% likelihood.
There is a 40% it was 1 hop away, 16% it was 2 hops, 6.4% it
was 3, etc.  The final value of Depth when the data is found
will very rarely more than 3 or 4 hops too small, so the
replying node can just add 10 to compute hops home and be
pretty safe (1 in 1000 chance of failure, not accounting for
the extra hop or two HTL may add on the way back).

--
Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lcrocker.html>
"All inventions or works of authorship original to me, herein and past,
are placed irrevocably in the public domain, and may be used or modified
for any purpose, without permission, attribution, or notification."--LDC


_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev

Reply via email to