Yeah, this could work. Since I was working with a confidence level of 90% on
the predictions, assuming three jumps would fall within that (well, it isn't
that simple when you multiply random variables, of course). Since we are
assuming 12 seconds per jump, even 3 jumps is more then half a minute of
course...

Man, I hated statistics - why does it have to be so god damn useful?

On Fri, 14 Apr 2000, Lee Daniel Crocker wrote:
> 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
-- 

Oskar Sandberg

md98-osa at nada.kth.se

#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

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

Reply via email to