[tor-bugs] #16943 [Tor]: Implement prop250 (Random Number Generation During Tor Voting)

[Tor Bug Tracker & Wiki]

#16943: Implement prop250 (Random Number Generation During Tor Voting)
------------------------+--------------------------
     Reporter:  asn     |      Owner:
         Type:  defect  |     Status:  new
     Priority:  normal  |  Milestone:  Tor: 0.2.???
    Component:  Tor     |    Version:
   Resolution:          |   Keywords:  tor-hs
Actual Points:          |  Parent ID:  #8244
       Points:          |
------------------------+--------------------------

Comment (by asn):

 OK. Some very initial work can be found at `shared-random-refactor1` in my
 repo.

 The main contribution here is refactoring `dirvote_compute_consensuses()`.
 This is the function that will eventually create the SR doc, and it was a
 big clusterfuck. The first three commits of my branch try to refactor in a
 way that will allow us to add code to it, without complicating it even
 more.

 The final commit (`80bd3da`) adds in some of the SR stuff that we wrote
 during camp plus a few more stuff. These are just ideas and scaffolding,
 so don't take it seriously.
 However, I didn't manage to proceed with this too much because the
 consensus signature code is very thick. It seems to me that more
 refactoring is needed.

 The main problem is that when `dirvote.c` thinks consensus, it actually
 thinks of networkstatus. So all consensus-related functions are created
 with networkstatus documents in mind, which is totally different from the
 SR doc. You can see this by seeing how `pending_consensus_t` is used
 around the code, and also by taking a look at the following functions:
 {{{
 networkstatus_add_detached_signatures()
 dirvote_fetch_missing_signatures()
 dirvote_add_signatures_to_pending_consensus()
 dirvote_add_signatures_to_all_pending_consensuses()
 dirvote_add_signatures()
 networkstatus_check_consensus_signature()
 }}}

 Also, grep for `N_CONSENSUS_FLAVORS` to see various places where tor loops
 over all the various flavors and expect to find networkstatus documents
 underneath. All the above functions will need to be refactored, or their
 caller will need to handle SR doc totally different.

 We will need to find a nice solution to this. We could for example
 introduce a new data structure called `consensus_t` that is a union that
 hosts either a networkstatus or an SR doc. And then write various methods
 for it, to be able to interact with it. I did a beginning with this, but
 it required shitloads of changes all around the codebase and then I
 dropped it.

 A lame fix here would be to just stuff all the SR info into a
 `networkstatus_t`, which might solve a few problems, but it's terrible.

 Seems like the "Ah, let's just use a new consensus flavor. What can go
 wrong." idea is starting to show its complexity :)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16943#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online