[tor-commits] [torspec/master] prop224: Minor cleanup of [WHERE-HSDESC] section.

[asn at torproject.org]

commit c00e9370c3ceb09006da0bd05a7738e3f2c270df
Author: George Kadianakis <desnacked at riseup.net>
Date:   Mon Jun 13 15:15:00 2016 +0300

    prop224: Minor cleanup of [WHERE-HSDESC] section.
---
 proposals/224-rend-spec-ng.txt | 25 +++++++------------------
 1 file changed, 7 insertions(+), 18 deletions(-)

diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt
index e8225e5..f9e61e6 100644
--- a/proposals/224-rend-spec-ng.txt
+++ b/proposals/224-rend-spec-ng.txt
@@ -737,18 +737,13 @@ Table of contents:
    The following consensus parameters control where a hidden service
    descriptor is stored;
 
-        hsdir_n_replicas = an integer in range [1,16]
-                             with default value 2.
-
-        hsdir_spread_fetch = an integer in range [1,128]
-                             with default value 3.
-
-        hsdir_spread_store = an integer in range [1,128]
-                             with default value 3.
+        hsdir_n_replicas = an integer in range [1,16] with default value 2.
+        hsdir_spread_fetch = an integer in range [1,128] with default value 3.
+        hsdir_spread_store = an integer in range [1,128] with default value 3.
 
    To determine where a given hidden service descriptor will be stored
    in a given period, after the blinded public key for that period is
-   derived, the uploading or downloading party calculate
+   derived, the uploading or downloading party calculates:
 
         for replicanum in 1...hsdir_n_replicas:
             hs_index(replicanum) = H("store-at-idx" |
@@ -756,8 +751,9 @@ Table of contents:
                                  INT_8(replicanum) |
                                  INT_8(period_num) )
 
-   where blinded_public_key is specified in section KEYBLIND, and period_num is
-   defined in section [TIME-PERIODS].
+   where blinded_public_key is specified in section [KEYBLIND], and period_num
+   is calculated using the current consensus "valid-after" as specified in
+   section [TIME-PERIODS].
 
    Then, for each node listed in the current consensus with the HSDirV3 flag,
    we compute a directory index for that node as:
@@ -777,13 +773,6 @@ Table of contents:
    service, any nodes already chosen are disregarded (i.e. skipped over)
    when choosing a replica's hsdir_spread_store nodes.
 
-   [ XX/teor - because the positions don't match the key, this might leak
-     the fact that nodes from other replicas are nearby to a HSDir.
-     But this is preferable to having fewer HSDirs for a service.
-     I think the probability of a collision is approximately:
-     1 / (n_hsdirs / (hsdir_n_replicas * hsdir_spread_store)) = 6 / n_hsdirs,
-     where n_hsdirs is the total number of HSDirs in the hash ring. ]
-
    When choosing an HSDir to download from, clients choose randomly from
    among the first hsdir_spread_fetch nodes after the indices.  (Note
    that, in order to make the system better tolerate disappearing