diff options
| -rw-r--r-- | doc/spec/proposals/000-index.txt | 2 | ||||
| -rw-r--r-- | doc/spec/proposals/175-automatic-node-promotion.txt | 15 |
2 files changed, 9 insertions, 8 deletions
diff --git a/doc/spec/proposals/000-index.txt b/doc/spec/proposals/000-index.txt index f6f313e58d..8ea73540a3 100644 --- a/doc/spec/proposals/000-index.txt +++ b/doc/spec/proposals/000-index.txt @@ -94,6 +94,7 @@ Proposals by number: 172 GETINFO controller option for circuit information [ACCEPTED] 173 GETINFO Option Expansion [ACCEPTED] 174 Optimistic Data for Tor: Server Side [OPEN] +175 Automatically promoting Tor clients to nodes [DRAFT] Proposals by status: @@ -106,6 +107,7 @@ Proposals by status: 144 Increase the diversity of circuits by detecting nodes belonging the same provider 169 Eliminate TLS renegotiation for the Tor connection handshake [for 0.2.2] 170 Configuration options regarding circuit building + 175 Automatically promoting Tor clients to nodes [for ] NEEDS-REVISION: 131 Help users to verify they are using Tor OPEN: diff --git a/doc/spec/proposals/175-automatic-node-promotion.txt b/doc/spec/proposals/175-automatic-node-promotion.txt index bbe6b37bf2..c990b3f060 100644 --- a/doc/spec/proposals/175-automatic-node-promotion.txt +++ b/doc/spec/proposals/175-automatic-node-promotion.txt @@ -1,9 +1,8 @@ -Filename: xxx-automatic-node-promotion.txt +Filename: 175-automatic-node-promotion.txt Title: Automatically promoting Tor clients to nodes Author: Steven Murdoch Created: 12-Mar-2010 Status: Draft -Target: 1. Overview @@ -28,7 +27,7 @@ Target: countries. By automatically promoting Tor clients to bridges, and perhaps also to full public relays, this proposal aims to solve these problems. - + Only Tor clients which are sufficiently useful should be promoted, and the process of determining usefulness should be performed without reporting the existence of the client to the central @@ -150,22 +149,22 @@ Target: the number of successes >= num_useful, Tor should consider promotion to a bridge end. - + When Tor starts, it must fill in the samples for which it was not running. This can only happen once the consensus has downloaded, because the value of check_period is needed. - + 1. Tor generates a random number y from the Poisson distribution [1] with lambda = (current_time - last_check) * (1 / check_period) - 2. Tor sets the value last_check to the current_time (in seconds) + 2. Tor sets the value last_check to the current_time (in seconds) 3. Add y test failures to the ring buffer measurements_results 4. Tor saves last_check and measurements_results to disk - + In this way, a Tor client will measure its bandwidth and reachability every check_period seconds, on average. Provided check_period is sufficiently greater than a minute (say, at least an hour), the times of check will follow a Poisson distribution. [2] - + While this does require that Tor does record the state of a client over time, this does not leak much information. Only a binary reachable/non-reachable is stored, and the timing of samples becomes |