Re: [tor-bugs] #25999 [Core Tor/Stem]: Build an abstraction layer over different consensus flavours

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#25999: Build an abstraction layer over different consensus flavours
---------------------------+-----------------------------------
 Reporter:  teor           |          Owner:  atagar
     Type:  enhancement    |         Status:  needs_information
 Priority:  Medium         |      Milestone:
Component:  Core Tor/Stem  |        Version:
 Severity:  Normal         |     Resolution:
 Keywords:  descriptor     |  Actual Points:
Parent ID:                 |         Points:
 Reviewer:                 |        Sponsor:
---------------------------+-----------------------------------

Comment (by teor):

 Replying to [comment:5 atagar]:
 > > I might have missed a document type or two, but I can't see any we
 could remove or even combine.
 >
 > At the end of the day data comes from three sources...
 >
 > * From relays via a server descriptor.
 > * From relays via an extrainfo descriptor.
 > * From authorities via the router status entry (ex. flags, bwauth
 measurements, etc).
 >
 > Microdescriptors are nothing more than a distillation of the server
 descriptor so downloads are smaller. Unless I'm missing something there's
 no reason anyone beside tor itself should care about those.
 >
 > The thing I think we *can* simplify is the consensus. I'm at a loss for
 a reason to have both a standard and microdescriptor consensus. Maybe the
 split's for historical backward compatibility?
 >
 > > ns (original) consensus flavour - a comprehensive consensus, used by
 old clients, and for detailed analysis by tools and people
 >
 > That's what I'm unsure about. Microdescriptors were added enough years
 ago that we likely already cut them out of the network.

 No, relays on 0.2.8 and earlier use descriptors for their circuits, and
 there are still a few of them around (even though they are unsupported,
 they still work). So do some really old clients, which at the very least
 will need a consensus substitute to avoid misbehaving and bringing down
 the network:
 https://gitweb.torproject.org/torspec.git/tree/proposals/266-removing-
 current-obsolete-clients.txt

 Also, Torflow and now sbws depend on the ns consensus. I bet Onionoo,
 depictor, and doctor would also fail if we got rid of the ns consensus. If
 we want to migrate away from it, that's a lot of work.

 > As for analysis, the microdescriptor consensus and server descriptors
 have the same data.
 >
 > > Ok, that would be very helpful.
 >
 > Do we have anyone eager to use such a class? It would be sad to
 implement such a thing only to see it go unused. ;)

 If it was available, sbws would have used it.
 If it was available, we could more easily migrate sbws, depictor and
 doctor away from using ns consensuses.

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