[tor-dev] Proposal 342: Decouple hs_interval and SRV lifetime

[Nick Mathewson]

On Tue, Jan 24, 2023 at 9:02 AM David Goulet <dgoulet at torproject.org> wrote:

> On 23 Jan (13:31:49), Nick Mathewson wrote:
> > On Tue, Jan 10, 2023 at 8:22 AM Nick Mathewson <nickm at torproject.org>
> 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.)"

How would that be?

-- 
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20230124/6523afb3/attachment.htm>