142 Combine Introduction and Rendezvous Points [OPEN]
143 Improvements of Distributed Storage for Tor Hidden Service Descriptors [OPEN]
144 Increase the diversity of circuits by detecting nodes belonging the [DRAFT]
-145 Separate "suitable as a guard" from "suitable as a new guard" [DRAFT]
-146 Add new flag to reflect long-term stability [DRAFT]
+145 Separate "suitable as a guard" from "suitable as a new guard" [OPEN]
+146 Add new flag to reflect long-term stability [OPEN]
+147 Eliminate the need for v2 directories in generating v3 directories [OPEN]
Proposals by status:
134 More robust consensus voting with diverse authority sets
141 Download server descriptors on demand
144 Increase the diversity of circuits by detecting nodes belonging the
- 145 Separate "suitable as a guard" from "suitable as a new guard"
- 146 Add new flag to reflect long-term stability
OPEN:
120 Shutdown descriptors when Tor servers stop
121 Hidden Service Authentication
140 Provide diffs between consensuses
142 Combine Introduction and Rendezvous Points
143 Improvements of Distributed Storage for Tor Hidden Service Descriptors
+ 145 Separate "suitable as a guard" from "suitable as a new guard"
+ 146 Add new flag to reflect long-term stability
+ 147 Eliminate the need for v2 directories in generating v3 directories
NEEDS-REVISION:
110 Avoiding infinite length circuits
117 IPv6 exits
--- /dev/null
+Filename: 147-prevoting-opinions.txt
+Title: Eliminate the need for v2 directories in generating v3 directories
+Version: $Revision$
+Last-Modified: $Date$
+Author: Nick Mathewson
+Created: 2-Jul-2008
+Status: Open
+
+Overview
+
+ We propose a new v3 vote document type to replace the role of v2
+ networkstatus information in generating v3 consensuses.
+
+Motivation
+
+ When authorities vote on which descriptors are to be listed in the
+ next consensus, it helps if they all know about the same descriptors
+ as one another. But a hostile, confused, or out-of-date server may
+ upload a descriptor to only some authorities. In the current v3
+ directory design, the authorities don't have a good way to tell one
+ another about the new descriptor until they exchange votes... but by
+ the time this happens, they are already committed to their votes,
+ and they can't add anybody they learn about from other authorities
+ until the next voting cycle. That's no good!
+
+ The current Tor implementation avoids this problem by having
+ authorities also look at v2 networkstatus documents, but we'd like
+ in the long term to eliminate these, once 0.1.2.x is obsolete.
+
+Design:
+
+ We add a new value for vote-status in v3 consensus documents in
+ addition to "consensus" and "vote": "opinion". Authorities generate
+ and sign an opinion document as if they were generating a vote,
+ except that they send it to one another earlier than they send
+ votes.
+
+ Authorities don't need to generate more than one opinion document
+ per voting interval, but may. They should send it to the other
+ authorities they know about, at the regular vote upload URL, before
+ the authorities begin voting, so that enough time remains for the
+ authorities to fetch new descriptors.
+
+ Upon receiving an opinion document, authorities scan it for any
+ descriptors that:
+ - They might accept.
+ - Are for routers they don't know about, or are published more
+ recently than any descriptor they have for that router.
+ Authorities then begin downloading such descriptors from authorities
+ that claim to have them.
+
+ Authorities MAY cache opinion documents, but don't need to.
+
+
projects / thirdparty / tor.git / commitdiff
