Re: [tor-bugs] #572 [Tor Client]: fallback-consensus needs autoconf voodoo

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#572: fallback-consensus needs autoconf voodoo
---------------------------+------------------------------------------------
 Reporter:  arma           |         Type:  enhancement
   Status:  new            |     Priority:  minor      
Milestone:  post 0.2.1.x   |    Component:  Tor Client 
  Version:  0.2.0.9-alpha  |   Resolution:  None       
 Keywords:                 |       Parent:             
---------------------------+------------------------------------------------

Comment(by arma):

 The main remaining goal is to give Tor clients a lot more than 8 IP
 addresses to bootstrap into the network.

 We haven't moved forward on the fallback consensus design because we would
 use it in place of the 8 directory authorities when trying to bootstrap,
 and if half the relays in it are down, we spend a lot of time timing out
 before we find one that works.

 I think a good compromise approach would be to only fall back to the
 fallback consensus when the 8 known bootstrap points have failed. It will
 mean it takes longer for your Tor to bootstrap in the case where before it
 wouldn't have worked at all, but it won't slow things down if they're
 going to work normally.

 Another approach would just be to stick a pile of IP addresses in each
 release, and run some metrics function over the recent directory archives
 to spit out the 500 addresses that seem most promising. But formatting
 things as a consensus seems like it should save some coding, specifying,
 etc.

 In the distant future we could add some sort of flag like
 IsLikelyToStillBeInThisLocationLater (I think there's a proposal for
 that), but if the only use for that flag is having clients read it from
 disk in their fallback consensus, it's kind of weird to tell it to all
 clients all the time.

 Yet another approach would be having directory authorities able to vote on
 a special consensus that includes only relays they think will be around
 for a while. They would vote on it and write it to disk every day or so,
 and we could just package the most recent version of that file in each
 release.

 Yet yet another approach would be to have the metrics script generate
 something that looks like a consensus but has no signatures, and then we'd
 ship that and the only Tor code changes would be having Tor not worry
 about signatures when handling that file.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/572#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs