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

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

#16943: Implement prop250 (Random Number Generation During Tor Voting)
-------------------------+------------------------------------
 Reporter:  asn          |          Owner:
     Type:  enhancement  |         Status:  needs_review
 Priority:  High         |      Milestone:  Tor: 0.2.8.x-final
Component:  Tor          |        Version:
 Severity:  Normal       |     Resolution:
 Keywords:  tor-hs       |  Actual Points:
Parent ID:  #8244        |         Points:  large
  Sponsor:  SponsorR     |
-------------------------+------------------------------------

Comment (by teor):

 Replying to [comment:24 asn]:
 > Replying to [comment:22 teor]:
 > > Replying to [comment:21 dgoulet]:
 > > > After proposal review that happened few days ago on #tor-dev, we
 made some adjustments to the specification and code.
 > > >
 > > > Please find the latest code here: `prop250_final_v3`
 > > >
 > > > Proposal 250 has been updated with the latest in torspec.git
 > >
 > > Code review:
 > >
 > > General comments:
 > >
 > > get_start_time_of_current_round() doesn't take
 TestingV3AuthVotingStartOffset into account. Why not use:
 > > {{{
 > > time_t next_start = voting_schedule.interval_starts;
 > > time_t curr_start = dirvote_get_start_of_next_interval(next_start -
 interval - 1,interval,
 > >                       options->TestingV3AuthVotingStartOffset);
 > > }}}
 > >
 > > get_next_valid_after_time() duplicates code in
 dirvote_recalculate_timing().
 > > Why not use `voting_schedule.interval_starts`?
 > > (You'd need to make sure dirvote_recalculate_timing() had been called
 before either of these functions used `voting_schedule.interval_starts`.)
 > >
 >
 > Hmm, I would like to do that but it doesn't seem so easy.
 `dirvote_recalculate_timing()`  has not been called when we call
 `state_new()`, since we call it when we boot up and we haven't voted yet
 at that point.
 >
 > I then called `dirvote_recalculate_timing()` myself and everything
 worked fine, but I'm not sure if it's actually correct. That function
 updates the global `voting_schedule` structure which is then used by other
 parts of the codebase and I'm not sure if initializing it with 'now' set
 to the next 'valid_after' would be correct here :x

 Can we refactor the relevant calculations out of
 dirvote_recalculate_timing(), and call them from
 dirvote_recalculate_timing() and get_next_valid_after_time() and
 get_start_time_of_current_round()?

 My concern is that we'll break test networks that use
 TestingV3AuthVotingStartOffset by ignoring it during shared random
 calculations. And that these 3 functions should produce the same results.

 Do get_next_valid_after_time() and get_start_time_of_current_round()
 belong in the core dirserv file instead? They don't seem to be specific to
 shared random.

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