[tor-commits] [torspec/master] Reflow proposals 233, 234.

[nickm at torproject.org]

commit 1c57e5de3b0de3eee2ee44b1ae2a0c800c2d5a76
Author: Nick Mathewson <nickm at torproject.org>
Date:   Mon Apr 14 16:52:29 2014 -0400

    Reflow proposals 233, 234.
---
 proposals/000-index.txt                |    4 ++++
 proposals/233-quicken-tor2web-mode.txt |   35 ++++++++++++++-------------
 proposals/234-remittance-addresses.txt |   41 +++++++++++++++++---------------
 3 files changed, 45 insertions(+), 35 deletions(-)

diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index 6964e2e..dc257ae 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -153,6 +153,8 @@ Proposals by number:
 230  How to change RSA1024 relay identity keys [DRAFT]
 231  Migrating authority RSA1024 identity keys [DRAFT]
 232  Pluggable Transport through SOCKS proxy [OPEN]
+233  Making Tor2Web mode faster [OPEN]
+234  Adding remittance field to directory specification [OPEN]
 
 
 Proposals by status:
@@ -208,6 +210,8 @@ Proposals by status:
    227  Include package fingerprints in consensus documents
    228  Cross-certifying identity keys with onion keys
    232  Pluggable Transport through SOCKS proxy [for 0.2.6.x]
+   233  Making Tor2Web mode faster
+   234  Adding remittance field to directory specification
  ACCEPTED:
    140  Provide diffs between consensuses
    172  GETINFO controller option for circuit information
diff --git a/proposals/233-quicken-tor2web-mode.txt b/proposals/233-quicken-tor2web-mode.txt
index 433e2a7..325ff87 100644
--- a/proposals/233-quicken-tor2web-mode.txt
+++ b/proposals/233-quicken-tor2web-mode.txt
@@ -6,27 +6,30 @@ Status: Open
 
 
 1. Introduction
-While chatting with the Tor archons at the winter meeting, two speed
-optimizations for tor2web mode [1] were put forward.  This proposal specifies
-concretizes these two optimizations.  As with the current tor2web mode, this
-quickened tor2web mode negates any client anonymity.
 
+   While chatting with the Tor archons at the winter meeting, two speed
+   optimizations for tor2web mode [1] were put forward.  This proposal
+   specifies concretizes these two optimizations.  As with the current
+   tor2web mode, this quickened tor2web mode negates any client
+   anonymity.
 
 2. Tor2web optimizations
-  2.1) self-rendezvous
-  In the current tor2web mode, the client establishes a 1-hop circuit (direct
-  connection) to a chosen rendezvous point.  We propose that, alternatively,
-  the client set *itself* as the rendezvous point. This coincides with ticket
-  #9685[2].
 
+2.1. Self-rendezvous
 
-  2.2) direct-introduction
-  Identical to the non-tor2web mode, in the current tor2web mode, the
-  client establishes a 3-hop circuit to the introduction point.
-  We propose that, alternatively, the client builds a 1-hop circuit to
-  the introduction point.
+  In the current tor2web mode, the client establishes a 1-hop circuit
+  (direct connection) to a chosen rendezvous point.  We propose that,
+  alternatively, the client set *itself* as the rendezvous point. This
+  coincides with ticket #9685[2].
+
+2.2. direct-introduction
 
+  Identical to the non-tor2web mode, in the current tor2web mode, the
+  client establishes a 3-hop circuit to the introduction point.  We
+  propose that, alternatively, the client builds a 1-hop circuit to the
+  introduction point.
 
 4. References
-[1] Tor2web mode: https://trac.torproject.org/projects/tor/ticket/2553
-[2] Self-rendezvous: https://trac.torproject.org/projects/tor/ticket/9685
+
+  [1] Tor2web mode: https://trac.torproject.org/projects/tor/ticket/2553
+  [2] Self-rendezvous: https://trac.torproject.org/projects/tor/ticket/9685
diff --git a/proposals/234-remittance-addresses.txt b/proposals/234-remittance-addresses.txt
index 55cd8bd..303df85 100644
--- a/proposals/234-remittance-addresses.txt
+++ b/proposals/234-remittance-addresses.txt
@@ -6,31 +6,34 @@ Status: Open
 
 
 1. Motivation
-We wish to add the ability for individual users to donate to the owners of
-relay operators using a cryptocurrency.  We propose adding an optional line to
-the torrc file which will be published in the directory consensus and listed
-on https://compass.torproject.org.
+
+  We wish to add the ability for individual users to donate to the
+  owners of relay operators using a cryptocurrency.  We propose adding
+  an optional line to the torrc file which will be published in the
+  directory consensus and listed on https://compass.torproject.org.
 
 
 2. Proposal
-Allow an optional "RemittanceAddresses" line to the torrc file containing
-comma-delimited cryptocurrency URIs.  The format is:
 
-RemittanceAddressses <currency1>:<address>1,<currency2>:<address2>
+  Allow an optional "RemittanceAddresses" line to the torrc file
+  containing comma-delimited cryptocurrency URIs.  The format is:
+
+    RemittanceAddressses <currency1>:<address>1,<currency2>:<address2>
 
-For an example using an actual bitcoin and namecoin address, this is:
+  For an example using an actual bitcoin and namecoin address, this is:
 
-RemittanceAddressses bitcoin:19mP9FKrXqL46Si58pHdhGKow88SUPy1V8,namecoin:NAMEuWT2icj3ef8HWJwetZyZbXaZUJ5hFT
+    RemittanceAddressses bitcoin:19mP9FKrXqL46Si58pHdhGKow88SUPy1V8,namecoin:NAMEuWT2icj3ef8HWJwetZyZbXaZUJ5hFT
 
-The contents of a relay's RemittanceAddresses line will be mirrored in
-the relay's router descriptor (which is then published in the directory
-consensus).  This line will be treated akin to the ContactInfo field.  A
-cryptocurrency address may not contain a colon, comma, whitespace, or other
-nonprintable ASCII.
+  The contents of a relay's RemittanceAddresses line will be mirrored in
+  the relay's router descriptor (which is then published in the
+  directory consensus).  This line will be treated akin to the
+  ContactInfo field.  A cryptocurrency address may not contain a colon,
+  comma, whitespace, or other nonprintable ASCII.
 
-Like the ContactInfo line, there is no explicit length limit for
-RemittanceAddressses---the only limit is the length of the entire descriptor.
-If the relay lists multiple addresses of the same currency type (e.g., two
-bitcoin addresses), only the first (left-most) one of each currency is
-published in the directory consensus.
+  Like the ContactInfo line, there is no explicit length limit for
+  RemittanceAddressses---the only limit is the length of the entire
+  descriptor.  If the relay lists multiple addresses of the same
+  currency type (e.g., two bitcoin addresses), only the first
+  (left-most) one of each currency is published in the directory
+  consensus.