From fa215a8f77bcab6c792a4226245e2a8b991eb43b Mon Sep 17 00:00:00 2001 From: Roger Dingledine Date: Thu, 8 Nov 2007 04:43:43 +0000 Subject: [PATCH] decide that messing with fallback-concensus for 0.2.0.10-alpha isn't worth it. also mention bug 546 again. svn:r12432 --- doc/TODO | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/doc/TODO b/doc/TODO index 4ca3f0758d..99bfe5a9d4 100644 --- a/doc/TODO +++ b/doc/TODO @@ -15,6 +15,7 @@ J - Jeff claims X Abandoned Items blocking 0.2.0.10-alpha: + - Some resolution for (the reopened) bug 546. - We should back out the MBTF->WFU Guard factors, since they open us up to new attacks, and don't this "median" notion doesn't necessarily help us distinguish between "was good enough to be a guard when @@ -31,20 +32,14 @@ Here's a go: median WFU of the set. In addition, anybody born more than a month ago who has >=50% WFU is always a winner. - - Should we ship with a fallback-consensus? Where in the tarball does - it go? What's the process for choosing it? - - We can, but we don't have to now. Stick it in place of the - empty fallback-consensus file in src/config if you like. -NM - - To choose, just grab the most recent consensus you have. -NM - - If 1.5*MaxCircuitDirtiness is more than KeepAlive, do we then send a KeepAlive and reset our timeout, thus never reaching 1.5*MCD? - Aw, crud. We could keep track of how long it's been since we last did anything _other_ than a keepalive, I guess. -NM - o "When reporting clock skew, and we only have a lower bound on - the amount of skew, amount anyway, marked as a lower bound. - [XXX Nick: what does this mean??]" +For Tor 0.2.0.11-alpha: + - Put a consensus in place of the empty fallback-consensus file in + src/config and see what breaks. Things we'd like to do in 0.2.0.x: -- 2.11.4.GIT