On 24 Jan (09:05:18), Nick Mathewson wrote: > On Tue, Jan 24, 2023 at 9:02 AM David Goulet <dgoulet@xxxxxxxxxxxxxx> wrote: > > > On 23 Jan (13:31:49), Nick Mathewson wrote: > > > On Tue, Jan 10, 2023 at 8:22 AM Nick Mathewson <nickm@xxxxxxxxxxxxxx> > > wrote: > > > > > > > ``` > > > > Filename: 342-decouple-hs-interval.md > > > > Title: Decoupling hs_interval and SRV lifetime > > > > Author: Nick Mathewson > > > > Created: 9 January 2023 > > > > Status: Draft > > > > ``` > > > > > > > > # Motivation and introduction > > > > > > > > > > > I think there's another issue to address here too: the offset from the > > Unix > > > Epoch at which the first Time Period begins. According to rend-spec-v3, > > > > > > "we want our time periods to start at 12:00UTC every day, so > > > we subtract a "rotation time offset" of 12*60 minutes from the number of > > > minutes since the epoch, before dividing by the time period (effectively > > > making "our" epoch start at Jan 1, 1970 12:00UTC)." > > > > > > But this isn't exactly what the C Tor implementation does. In > > > `hs_get_time_period_num(),` it defines the offset as > > > `sr_state_get_phase_duration()`, which is tied to the voting interval and > > > the constant SHARED_RANDOM_N_ROUNDS (which is 12). > > > > > > David, do you have any thoughts on the right solution here? Some options > > > are: > > > * We could document the current behavior. > > > * We could add a consensus parameter for the time period offset. > > > * We could define the time period offset as exactly 12 hours in all > > > cases. (I guess this would break test networks though?) > > > * Something else? > > > > My intuition here would be to document current behavior. This shared random > > ritual is tied to the voting protocol (interval) because it has these > > commit + > > reveal phases thus using the voting interval between phase rounds is > > foundational. > > > > And so, I would keep those two tied and simply document. > > > > What we can think of is to add consensus parameters for how many rounds per > > phase instead of these hardcoded values in our C-tor code but unclear to me > > what it would give us in the long run. But for the interval, I would keep > > the > > voting one. We get TestingNetwork for free also with this. > > > > Whatever we do, the very important piece here is that we can't end up with > > a > > protocol taking more time than our MinUptimeHidServDirectoryV2 value > > (minimum > > uptime for a relay before becoming an HSDir). > > > > And so let say one day we change the voting interval to every 4 hours then > > we > > end up with 24 rounds of voting to complete the commit + reveal phases > > meaning > > a total of 96 hours (which is current value of MinUptimeHidServDirectoryV2) > > thus borderline no good. > > > > (Maybe something to keep in mind for arti-relay authorities to check > > on...). > > > > Hope this help with your question? > > > > > Sure! It sounds to me that we should then change rend-spec to say > something like this: > > "We want our time periods to start at a regular offset from the SRV voting > schedule, so > we subtract a "rotation time offset" of 12 voting periods from the number of > minutes since the epoch, before dividing by the time period (effectively > making "our" epoch start at Jan 1, 1970 12:00UTC when the voting period is > 1 hour.)" Excellent. David -- pG2H247H2MnipNmet9NVk2ZChKK1OeFLQ50ZwK2ROe4=
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev