<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>Tor uses shared random values (SRVs) in the consensus to determine<br>positions of relays within a hash ring.  Which shared random value is to<br>be used for a given time period depends upon the time at which that<br>shared random value became valid.<br><br>But right now, the consensus voting period is closely tied to the shared<br>random value voting cycle: and clients need to understand both of these<br>in order to determine when a shared random value became current.<br><br>This creates tight coupling between:<br>   * The voting schedule<br>   * The SRV liveness schedule<br>   * The hsdir_interval parameter that determines the length of the<br>     an HSDIR index<br><br>To decouple these values, this proposal describes a forward compatible<br>change to how Tor reports SRVs in consensuses, and how Tor decides which<br>hash ring to use when.<br><br><br>## Reporting SRV timestamps<br><br>In consensus documents, parties should begin to accept<br>`shared-rand-*-value` lines with an additional argument, in the format<br>of an IsoTimeNospace timestamp (like "1985-10-26T00:00:00").  When<br>present, this timestamp indicates the time at which the given shared<br>random value first became the "current" SRV.<br><br>Additionally, we define a new consensus method that adds these<br>timestamps to the consensus.<br><br>We specify that, in the absence of such a timestamp, parties are to<br>assume that the `shared-rand-current-value` SRV became "current" at the<br>first 00:00 UTC on the UTC day of the consensus's valid-after timestamp,<br>and that the `shard-rand-previous-value` SRV became "current" at 00:00<br>UTC on the previous UTC day.<br><br><br>## Generalizing HSDir index scheduling.<br><br>Under the current HSDir design, there is one SRV for each time period,<br>and one time period for which each SRV is in use.  Decoupling<br>`hsdir_interval` from 24 hours will require that we change this notion<br>slightly.<br><br>We therefore propose this set of generalized directory behavior rules,<br>which should be equivalent to the current rules under current<br>parameters.<br><br>The calculation of time periods remains the same (see `rend-spec-v3.txt`<br>section `[TIME PERIODS]`).<br><br>A single SRV is associated with each time period: specifically, the SRV<br>that was "current" at the start of the time period.<br><br>There is a separate hash ring associated with each time period and its<br>SRV.<br><br>Whenever fetching an onion service descriptor, the client uses the hash<br>ring for the time period that contains the start of the liveness<br>interval of the current consensus.  Call this the "Consensus" time period.<br><br>Whenever uploading an onion service descriptor, the service uses _two or<br>three_ hash rings:<br>  * The "consensus" time period (see above).<br>  * The immediately preceding time period, if the SRV to calculate that<br>    hash ring is available in the consensus.<br>  * The immediately following time period, if the SRV to calculate that<br>    hash ring is available in the consensus.<br><br>(Under the current parameters, where `hsdir_interval = SRV_interval`,<br>there will never be more than two possible time periods for which the<br>service can qualify.)<br><br>## Migration<br><br>We declare that, for at least the lifetime of the C tor client, we will<br>not make any changes to the voting interval, the SRV interval, or the<br>`hsdir_interval`.  As such, we do not need to prioritize implementing<br>these changes in the C client: we can make them in Arti only.<br><br>## Issues left unsolved<br><br>There are likely other lingering issues that would come up if we try to<br>change the voting interval.  This proposal does not attempt to solve<br>them.<br><br>This proposal does not attempt to add flexibility to the SRV voting<br>algorithm itself.<br><br>Changing `hsdir_interval` would create a flag day where everybody using<br>old and new values of `hsdir_interval` would get different hash<br>rings. We do not try to solve that here.<br><br>## Acknowledgments<br><br>Thanks to David Goulet for explaining all of this stuff to me!<br></div>