[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

#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 asn):

 Replying to [comment:26 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:
 > > >
 > > > <snip>
 > > >
 > > > 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`.)
 > > >
 > > <snip>
 >
 > 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.

 OK, I implemented the above logic in my branch `prop250_final_v4`:
 https://gitweb.torproject.org/user/asn/tor.git/log/?h=prop250_final_v4

 The refactoring was a bit more messy than I expected, but the branch seems
 to work in chutney. The tests still pass without any changes, so that's
 good.

 I also moved `get_next_valid_after_time()` in `dirvote.c` as you
 suggested.

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