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

[David Goulet]

On 24 Jan (09:05:18), Nick Mathewson wrote:
> 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.)"

Excellent.

David

-- 
pG2H247H2MnipNmet9NVk2ZChKK1OeFLQ50ZwK2ROe4=
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20230124/b6151a8e/attachment.sig>