<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 10, 2023 at 8:22 AM Nick Mathewson <<a href="mailto:nickm@torproject.org">nickm@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"><div dir="ltr">```<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></div></blockquote><div><br></div><div>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,</div><div><br></div><div>"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)."</div><div><br></div><div>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).</div><div><br></div><div>David, do you have any thoughts on the right solution here?  Some options are:</div><div>  * We could document the current behavior.</div><div>  * We could add a consensus parameter for the time period offset.</div><div>  * We could define the time period offset as exactly 12 hours in all cases. (I guess this would break test networks though?)</div><div>  * Something else?</div><div><br></div><div>best wishes,<br></div><div>-- <br></div><div>Nick<br></div><div> <br></div></div></div>