r16666@tombo: nickm | 2008-07-02 15:17:46 -0400 (1188df9c) · Commits · The Tor Project / Core / Tor

doc/spec/proposals/000-index.txt

+6 −4

Original line number	Diff line number	Diff line
		@@ -67,8 +67,9 @@ Proposals by number:
		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:
		@@ -82,8 +83,6 @@ 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
		@@ -91,6 +90,9 @@ Proposals by status:
		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

doc/spec/proposals/145-newguard-flag.txt

+1 −1

Original line number	Diff line number	Diff line
		@@ -4,7 +4,7 @@ Version: $Revision$
		Last-Modified: $Date$
		Author: Nick Mathewson
		Created: 1-Jul-2008
		Status: Draft
		Status: Open

		Overview

doc/spec/proposals/146-long-term-stability.txt

+1 −1

Original line number	Diff line number	Diff line
		@@ -4,7 +4,7 @@ Version: $Revision$
		Last-Modified: $Date$
		Author: Nick Mathewson
		Created: 19-Jun-2008
		Status: Draft
		Status: Open

		Overview

doc/spec/proposals/147-prevoting-opinions.txt

0 → 100644

+54 −0

Original line number	Diff line number	Diff line
		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.