commit f1ea369418afc2bbbce3288ab2b5f1c1d88a8e5d Author: Nick Mathewson nickm@torproject.org Date: Mon Apr 14 16:49:18 2014 -0400
Add proposals 233 and 234 from Virgil Griffith et al --- proposals/233-quicken-tor2web-mode.txt | 32 ++++++++++++++++++++++++++++ proposals/234-remittance-addresses.txt | 36 ++++++++++++++++++++++++++++++++ 2 files changed, 68 insertions(+)
diff --git a/proposals/233-quicken-tor2web-mode.txt b/proposals/233-quicken-tor2web-mode.txt new file mode 100644 index 0000000..433e2a7 --- /dev/null +++ b/proposals/233-quicken-tor2web-mode.txt @@ -0,0 +1,32 @@ +Filename: 233-quicken-tor2web-mode.txt +Title: Making Tor2Web mode faster +Author: Virgil Griffith, Fabio Pietrosanti, Giovanni Pellerano +Created: 2014-03-27 +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. + + +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.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 diff --git a/proposals/234-remittance-addresses.txt b/proposals/234-remittance-addresses.txt new file mode 100644 index 0000000..55cd8bd --- /dev/null +++ b/proposals/234-remittance-addresses.txt @@ -0,0 +1,36 @@ +Filename: 234-remittance-addresses.txt +Title: Adding remittance field to directory specification +Author: Virgil Griffith, Leif Ryge, Rob Jansen +Created: 2014-03-27 +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. + + +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> + +For an example using an actual bitcoin and namecoin address, this is: + +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. + +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. +