[tor-dev] Patch to improve time-period interval changes in 224-rend-spec-ng.txt

[Adrien Johnson]

Hello all,
I have a patch for proposal 224-rend-spec-ng.txt that clarifies the 
definition of time periods and improves the behaviour when the time 
period duration needs to be changed.
-Adrien Johnson



-------------- next part --------------
From b4dee3bdd7143929d2f3ef0ee1a1c9a4e13d5bad Mon Sep 17 00:00:00 2001
From: Adrien Johnson <adrienj at adrienj.com>
Date: Sat, 7 Mar 2015 13:16:48 -0500
Subject: [PATCH] Added offset to time period calc. in prop224

---
 proposals/224-rend-spec-ng.txt | 63 ++++++++++++++++++++++++++++++++----------
 1 file changed, 48 insertions(+), 15 deletions(-)

diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt
index ffef617..391b2f1 100644
--- a/proposals/224-rend-spec-ng.txt
+++ b/proposals/224-rend-spec-ng.txt
@@ -615,25 +615,58 @@ Status: Draft
 
 2.2.1. Dividing time into periods [TIME-PERIODS]
 
-   To prevent a single set of hidden service directory from becoming a
+   To prevent a single set of hidden service directories from becoming a
    target by adversaries looking to permanently censor a hidden service,
    hidden service descriptors are uploaded to different locations that
    change over time.
 
-   The length of a "time period" is controlled by the consensus
-   parameter 'hsdir-interval', and is a number of minutes between 30 and
-   14400 (10 days). The default time period length is 1500 (one day plus
-   one hour).
-
-   Time periods start with the Unix epoch (Jan 1, 1970), and are
-   computed by taking the number of whole minutes since the epoch and
-   dividing by the time period. So if the current time is 2013-11-12
-   13:44:32 UTC, making the seconds since the epoch 1384281872, the
-   number of minutes since the epoch is 23071364.  If the current time
-   period length is 1500 (the default), then the current time period
-   number is 15380. It began 15380*1500*60 seconds after the epoch at
-   2013-11-11 20:00:00 UTC, and will end at (15380+1)*1500*60 seconds
-   after the epoch at 2013-11-12 21:00:00 UTC.
+   Time is divided into infinitely many discrete "time periods" of
+   identical duration. Each time period is sequentially numbered according
+   to how many whole periods have elapsed since the Unix epoch
+   (1970-1-1 00:00:00 UTC) at the start of that period, plus an offset.
+   The time between the Unix epoch and the start of any time period is
+   evenly divisible by the time period duration.
+
+   current_period = floor((current_time - unix_epoch) / duration) + offset
+
+   Time period duration is controlled by the consensus parameter
+   'hsdir-interval', which is a number of minutes between 30 and
+   14400 (10 days). The default time period duration is 1500 (one day plus
+   one hour). The time period numbering offset is controlled by the
+   consensus parameter 'hsdir-offset' which is a signed 32 bit integer.
+   The default numbering offset is 0.
+
+   For example if the current time is 2013-11-14 13:44:32 UTC, and the
+   current time period duration is 1500 minutes (the default), then the
+   number of whole periods that have elapsed since the Unix epoch is
+   15382. If the current numbering offset is 5, then the current period
+   is 15387. Period 15387 began (15387-5)*1500*60 seconds after the epoch
+   at 2013-11-13 20:00:00 UTC, and will end (15387+1-5)*1500*60 seconds
+   after the epoch at 2013-11-14 21:00:00 UTC.
+
+   When a new time period duration is needed, a new numbering offset is
+   also chosen such that on the expected date consensus is reached on the
+   new values, the then-current time period number will remain the same.
+   This prevents changes to the time period duration from invalidating the
+   current keys and descriptors for all hidden services.
+
+   [NOTE: Depending on how accurately the consensus date can be predicted,
+   this may still be a problem, and it will get worse the further away we
+   are from the epoch. This could be improved by choosing a different epoch
+   closer to the present, or even one in the future.
+
+   An even more robust fix would be to have the epoch date set by a
+   third consensus parameter. This could be changed without altering the
+   progression of period numbers by also giving a new offset. In advance
+   of an expected need for a new duration, a new epoch date could be set
+   in the immediate future and a new offset given. Once consensus is
+   reached on this new epoch date, a new duration and offset are given,
+   timed so that consensus will be reached as close as possible to the
+   epoch date. This would almost guarantee monotonically increasing time
+   period numbers, even across very large duration changes. This assumes
+   consensus parameter value updates are atomic, i.e. if new consensus
+   parameter values are given in a single Tor update, consensus will be
+   reached on all the new values at the same time.]
 
 2.2.2. Overlapping time periods to avoid thundering herds [TIME-OVERLAP]
 
-- 
1.9.5.msysgit.0