On Tue, Jan 24, 2023 at 9:02 AM David Goulet dgoulet@torproject.org wrote:
On 23 Jan (13:31:49), Nick Mathewson wrote:
On Tue, Jan 10, 2023 at 8:22 AM Nick Mathewson nickm@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?