Re: [tor-bugs] #6232 [Analysis]: Make entropy-over-time graph

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

#6232: Make entropy-over-time graph
-------------------------+--------------------------------------------------
 Reporter:  arma         |          Owner:                
     Type:  enhancement  |         Status:  needs_revision
 Priority:  normal       |      Milestone:                
Component:  Analysis     |        Version:                
 Keywords:               |         Parent:                
   Points:               |   Actualpoints:                
-------------------------+--------------------------------------------------

Comment(by karsten):

 Replying to [comment:34 gsathya]:
 > Replying to [comment:32 karsten]:
 > >  - I wonder if entropies based on subsets of Exit and Guard flagged
 relays are correct.  [...] I want to hear back from Mike or Roger if my
 understanding of path selection is correct.

 Mike says in
 [https://trac.torproject.org/projects/tor/ticket/5755#comment:15 #5755]
 that the calculation of P_exit and P_guard in that ticket looks correct.

 That means, instead of just looking at the subsets of Exit or Guard
 flagged relays and using their unmodified consensus weights, we'll want to
 do the following:

  - To calculate entropy of exits,
    - consider only those relays with the Exit flag,
    - multiply the consensus weight of a relay with Exit and Guard flag
 with Wed,
    - multiply the consensus weight of a relay with only Exit flag with
 Wee,
    - use "weighted" consensus weights wherever unweighted consensus
 weights were used before.

  - To calculate entropy of guards,
    - consider only those relays with the Guard flag,
    - multiply the consensus weight of a relay with Exit and Guard flag
 with Wgd,
    - multiply the consensus weight of a relay with only Guard flag with
 Wgg,
    - use "weighted" consensus weights wherever unweighted consensus
 weights were used before.

 > Yep, all the three comments can be done pretty easily.

 Cool!

 > Actually stem can parse the server descriptors now. So this wouldn't be
 hard at all. I can teach the script to use stem for both families and
 advertised bandwidths.

 Okay.  I'd think that advertised bandwidths are higher priority than
 families though, and I'm not entirely sure how complex it is to extract
 families from server descriptors.  I think we only consider N relays to be
 in the same family if they all reference the N-1 others as family members.
 If a relay is not contained in a family, it constitutes a family of size
 1.  Doesn't sound impossible to implement, but who knows.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6232#comment:35>
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