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