[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-commits] [tor/release-0.2.2] Remove specs from 0.2.1 branch: they have moved to a new repository.



commit 7bdb7d4811bb5ff027e124e6558181167c2e2f91
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
Date:   Mon Feb 21 16:02:16 2011 -0500

    Remove specs from 0.2.1 branch: they have moved to a new repository.
---
 doc/Makefile.am                                    |    6 +-
 doc/spec/Makefile.am                               |    5 -
 doc/spec/README                                    |   10 +
 doc/spec/address-spec.txt                          |   68 -
 doc/spec/bridges-spec.txt                          |  250 ---
 doc/spec/control-spec-v0.txt                       |  499 -----
 doc/spec/control-spec.txt                          | 1854 -------------------
 doc/spec/dir-spec-v1.txt                           |  315 ----
 doc/spec/dir-spec-v2.txt                           |  897 ---------
 doc/spec/dir-spec.txt                              | 1898 --------------------
 doc/spec/path-spec.txt                             |  423 -----
 doc/spec/proposals/000-index.txt                   |  161 --
 doc/spec/proposals/001-process.txt                 |  187 --
 doc/spec/proposals/098-todo.txt                    |  109 --
 doc/spec/proposals/099-misc.txt                    |   30 -
 doc/spec/proposals/100-tor-spec-udp.txt            |  424 -----
 doc/spec/proposals/101-dir-voting.txt              |  285 ---
 doc/spec/proposals/102-drop-opt.txt                |   40 -
 doc/spec/proposals/103-multilevel-keys.txt         |  206 ---
 doc/spec/proposals/104-short-descriptors.txt       |  183 --
 doc/spec/proposals/105-handshake-revision.txt      |  325 ----
 doc/spec/proposals/106-less-tls-constraint.txt     |  113 --
 doc/spec/proposals/107-uptime-sanity-checking.txt  |   56 -
 doc/spec/proposals/108-mtbf-based-stability.txt    |   90 -
 doc/spec/proposals/109-no-sharing-ips.txt          |   92 -
 doc/spec/proposals/110-avoid-infinite-circuits.txt |  122 --
 doc/spec/proposals/111-local-traffic-priority.txt  |  153 --
 .../proposals/112-bring-back-pathlencoinweight.txt |  165 --
 .../proposals/113-fast-authority-interface.txt     |   87 -
 doc/spec/proposals/114-distributed-storage.txt     |  441 -----
 doc/spec/proposals/115-two-hop-paths.txt           |  387 ----
 .../proposals/116-two-hop-paths-from-guard.txt     |  120 --
 doc/spec/proposals/117-ipv6-exits.txt              |  412 -----
 doc/spec/proposals/118-multiple-orports.txt        |   86 -
 doc/spec/proposals/119-controlport-auth.txt        |  142 --
 doc/spec/proposals/120-shutdown-descriptors.txt    |   85 -
 .../121-hidden-service-authentication.txt          |  778 --------
 doc/spec/proposals/122-unnamed-flag.txt            |  138 --
 doc/spec/proposals/123-autonaming.txt              |   56 -
 doc/spec/proposals/124-tls-certificates.txt        |  315 ----
 doc/spec/proposals/125-bridges.txt                 |  293 ---
 doc/spec/proposals/126-geoip-reporting.txt         |  412 -----
 .../proposals/127-dirport-mirrors-downloads.txt    |  157 --
 doc/spec/proposals/128-bridge-families.txt         |   66 -
 doc/spec/proposals/129-reject-plaintext-ports.txt  |  116 --
 doc/spec/proposals/130-v2-conn-protocol.txt        |  186 --
 doc/spec/proposals/131-verify-tor-usage.txt        |  150 --
 .../proposals/132-browser-check-tor-service.txt    |  147 --
 doc/spec/proposals/133-unreachable-ors.txt         |  128 --
 doc/spec/proposals/134-robust-voting.txt           |  105 --
 doc/spec/proposals/135-private-tor-networks.txt    |  283 ---
 doc/spec/proposals/136-legacy-keys.txt             |  100 -
 doc/spec/proposals/137-bootstrap-phases.txt        |  237 ---
 .../138-remove-down-routers-from-consensus.txt     |   51 -
 .../139-conditional-consensus-download.txt         |   94 -
 doc/spec/proposals/140-consensus-diffs.txt         |  149 --
 doc/spec/proposals/141-jit-sd-downloads.txt        |  325 ----
 .../142-combine-intro-and-rend-points.txt          |  279 ---
 .../143-distributed-storage-improvements.txt       |  196 --
 .../proposals/144-enforce-distinct-providers.txt   |  165 --
 doc/spec/proposals/145-newguard-flag.txt           |   41 -
 doc/spec/proposals/146-long-term-stability.txt     |   86 -
 doc/spec/proposals/147-prevoting-opinions.txt      |   60 -
 .../proposals/148-uniform-client-end-reason.txt    |   59 -
 doc/spec/proposals/149-using-netinfo-data.txt      |   44 -
 doc/spec/proposals/150-exclude-exit-nodes.txt      |   48 -
 .../proposals/151-path-selection-improvements.txt  |  147 --
 doc/spec/proposals/152-single-hop-circuits.txt     |   64 -
 .../153-automatic-software-update-protocol.txt     |  177 --
 doc/spec/proposals/154-automatic-updates.txt       |  379 ----
 .../155-four-hidden-service-improvements.txt       |  122 --
 doc/spec/proposals/156-tracking-blocked-ports.txt  |  529 ------
 doc/spec/proposals/157-specific-cert-download.txt  |  104 --
 doc/spec/proposals/158-microdescriptors.txt        |  207 ---
 doc/spec/proposals/159-exit-scanning.txt           |  144 --
 doc/spec/proposals/ideas/xxx-auto-update.txt       |   39 -
 .../proposals/ideas/xxx-bridge-disbursement.txt    |  174 --
 .../ideas/xxx-controllers-intercept-extends.txt    |   44 -
 .../proposals/ideas/xxx-exit-scanning-outline.txt  |   44 -
 doc/spec/proposals/ideas/xxx-geoip-survey-plan.txt |  137 --
 .../proposals/ideas/xxx-grand-scaling-plan.txt     |   97 -
 doc/spec/proposals/ideas/xxx-hide-platform.txt     |   39 -
 doc/spec/proposals/ideas/xxx-port-knocking.txt     |   93 -
 doc/spec/proposals/ideas/xxx-rate-limit-exits.txt  |   63 -
 .../ideas/xxx-separate-streams-by-port.txt         |   61 -
 doc/spec/proposals/ideas/xxx-what-uses-sha1.txt    |  140 --
 doc/spec/proposals/reindex.py                      |  117 --
 doc/spec/rend-spec.txt                             |  768 --------
 doc/spec/socks-extensions.txt                      |   79 -
 doc/spec/tor-spec.txt                              |  993 ----------
 doc/spec/version-spec.txt                          |   45 -
 91 files changed, 13 insertions(+), 20783 deletions(-)

diff --git a/doc/Makefile.am b/doc/Makefile.am
index 79123d8..2959813 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -2,11 +2,11 @@
 EXTRA_DIST = HACKING                                         \
              tor-resolve.1 tor-gencert.1                     \
              tor-osx-dmg-creation.txt tor-rpm-creation.txt   \
-             tor-win32-mingw-creation.txt
+             tor-win32-mingw-creation.txt spec/README
 
 man_MANS = tor.1 tor-resolve.1 tor-gencert.1
 
-SUBDIRS = design-paper spec
+SUBDIRS = design-paper
 
-DIST_SUBDIRS = design-paper spec
+DIST_SUBDIRS = design-paper
 
diff --git a/doc/spec/Makefile.am b/doc/spec/Makefile.am
deleted file mode 100644
index 208901d..0000000
--- a/doc/spec/Makefile.am
+++ /dev/null
@@ -1,5 +0,0 @@
-
-EXTRA_DIST = tor-spec.txt rend-spec.txt control-spec.txt     \
-             dir-spec.txt socks-extensions.txt path-spec.txt \
-             version-spec.txt address-spec.txt
-
diff --git a/doc/spec/README b/doc/spec/README
new file mode 100644
index 0000000..a7fa170
--- /dev/null
+++ b/doc/spec/README
@@ -0,0 +1,10 @@
+The Tor specifications and proposals have moved to a new repository.
+
+To browse the specifications, go to 
+    https://gitweb.torproject.org/torspec.git/tree
+
+To check out the specification repository, run
+    git clone git://git.torproject.org/torspec.git
+
+For other information on the repository, see
+    http://gitweb.torproject.org/torspec.git
diff --git a/doc/spec/address-spec.txt b/doc/spec/address-spec.txt
deleted file mode 100644
index 2a84d85..0000000
--- a/doc/spec/address-spec.txt
+++ /dev/null
@@ -1,68 +0,0 @@
-$Id$
-
-                          Special Hostnames in Tor
-                               Nick Mathewson
-
-1. Overview
-
-  Most of the time, Tor treats user-specified hostnames as opaque:  When
-  the user connects to www.torproject.org, Tor picks an exit node and uses
-  that node to connect to "www.torproject.org".  Some hostnames, however,
-  can be used to override Tor's default behavior and circuit-building
-  rules.
-
-  These hostnames can be passed to Tor as the address part of a SOCKS4a or
-  SOCKS5 request.  If the application is connected to Tor using an IP-only
-  method (such as SOCKS4, TransPort, or NatdPort), these hostnames can be
-  substituted for certain IP addresses using the MapAddress configuration
-  option or the MAPADDRESS control command.
-
-2. .exit
-
-  SYNTAX:  [hostname].[name-or-digest].exit
-           [name-or-digest].exit
-
-  Hostname is a valid hostname; [name-or-digest] is either the nickname of a
-  Tor node or the hex-encoded digest of that node's public key.
-
-  When Tor sees an address in this format, it uses the specified hostname as
-  the exit node.  If no "hostname" component is given, Tor defaults to the
-  published IPv4 address of the exit node.
-
-  It is valid to try to resolve hostnames, and in fact upon success Tor
-  will cache an internal mapaddress of the form
-  "www.google.com.foo.exit=64.233.161.99.foo.exit" to speed subsequent
-  lookups.
-
-  EXAMPLES:
-     www.example.com.exampletornode.exit
-
-        Connect to www.example.com from the node called "exampletornode."
-
-     exampletornode.exit
-
-        Connect to the published IP address of "exampletornode" using
-        "exampletornode" as the exit.
-
-3. .onion
-
-  SYNTAX:  [digest].onion
-
-  The digest is the first eighty bits of a SHA1 hash of the identity key for
-  a hidden service, encoded in base32.
-
-  When Tor sees an address in this format, it tries to look up and connect to
-  the specified hidden service.  See rend-spec.txt for full details.
-
-4. .noconnect
-
-  SYNTAX:  [string].noconnect
-
-  When Tor sees an address in this format, it immediately closes the
-  connection without attaching it to any circuit.  This is useful for
-  controllers that want to test whether a given application is indeed using
-  the same instance of Tor that they're controlling.
-
-5. [XXX Is there a ".virtual" address that we expose too, or is that
-just intended to be internal? -RD]
-
diff --git a/doc/spec/bridges-spec.txt b/doc/spec/bridges-spec.txt
deleted file mode 100644
index 4a9b373..0000000
--- a/doc/spec/bridges-spec.txt
+++ /dev/null
@@ -1,250 +0,0 @@
-$Id$
-
-                          Tor bridges specification
-
-0. Preface
-
-  This document describes the design decisions around support for bridge
-  users, bridge relays, and bridge authorities. It acts as an overview
-  of the bridge design and deployment for developers, and it also tries
-  to point out limitations in the current design and implementation.
-
-  For more details on what all of these mean, look at blocking.tex in
-  /doc/design-paper/
-
-1. Bridge relays
-
-  Bridge relays are just like normal Tor relays except they don't publish
-  their server descriptors to the main directory authorities.
-
-1.1. PublishServerDescriptor
-
-  To configure your relay to be a bridge relay, just add
-    BridgeRelay 1
-    PublishServerDescriptor bridge
-  to your torrc. This will cause your relay to publish its descriptor
-  to the bridge authorities rather than to the default authorities.
-
-  Alternatively, you can say
-    BridgeRelay 1
-    PublishServerDescriptor 0
-  which will cause your relay to not publish anywhere. This could be
-  useful for private bridges.
-
-1.2. Recommendations.
-
-  Bridge relays should use an exit policy of "reject *:*". This is
-  because they only need to relay traffic between the bridge users
-  and the rest of the Tor network, so there's no need to let people
-  exit directly from them.
-
-  We invented the RelayBandwidth* options for this situation: Tor clients
-  who want to allow relaying too. See proposal 111 for details. Relay
-  operators should feel free to rate-limit their relayed traffic.
-
-1.3. Implementation note.
-
-  Vidalia 0.0.15 has turned its "Relay" settings page into a tri-state
-  "Don't relay" / "Relay for the Tor network" / "Help censored users".
-
-  If you click the third choice, it forces your exit policy to reject *:*.
-
-  If all the bridges end up on port 9001, that's not so good. On the
-  other hand, putting the bridges on a low-numbered port in the Unix
-  world requires jumping through extra hoops. The current compromise is
-  that Vidalia makes the ORPort default to 443 on Windows, and 9001 on
-  other platforms.
-
-  At the bottom of the relay config settings window, Vidalia displays
-  the bridge identifier to the operator (see Section 3.1) so he can pass
-  it on to bridge users.
-
-2. Bridge authorities.
-
-  Bridge authorities are like normal v3 directory authorities, except
-  they don't create their own network-status documents or votes. So if
-  you ask a bridge authority for a network-status document or consensus,
-  they behave like a directory mirror: they give you one from one of
-  the main authorities. But if you ask the bridge authority for the
-  descriptor corresponding to a particular identity fingerprint, it will
-  happily give you the latest descriptor for that fingerprint.
-
-  To become a bridge authority, add these lines to your torrc:
-    AuthoritativeDirectory 1
-    BridgeAuthoritativeDir 1
-
-  Right now there's one bridge authority, running on the Tonga relay.
-
-2.1. Exporting bridge-purpose descriptors
-
-  We've added a new purpose for server descriptors: the "bridge"
-  purpose. With the new router-descriptors file format that includes
-  annotations, it's easy to look through it and find the bridge-purpose
-  descriptors.
-
-  Currently we export the bridge descriptors from Tonga to the
-  BridgeDB server, so it can give them out according to the policies
-  in blocking.pdf.
-
-2.2. Reachability/uptime testing
-
-  Right now the bridge authorities do active reachability testing of
-  bridges, so we know which ones to recommend for users.
-
-  But in the design document, we suggested that bridges should publish
-  anonymously (i.e. via Tor) to the bridge authority, so somebody watching
-  the bridge authority can't just enumerate all the bridges. But if we're
-  doing active measurement, the game is up. Perhaps we should back off on
-  this goal, or perhaps we should do our active measurement anonymously?
-
-  Answering this issue is scheduled for 0.2.1.x.
-
-2.3. Future work: migrating to multiple bridge authorities
-
-  Having only one bridge authority is both a trust bottleneck (if you
-  break into one place you learn about every single bridge we've got)
-  and a robustness bottleneck (when it's down, bridge users become sad).
-
-  Right now if we put up a second bridge authority, all the bridges would
-  publish to it, and (assuming the code works) bridge users would query
-  a random bridge authority. This resolves the robustness bottleneck,
-  but makes the trust bottleneck even worse.
-
-  In 0.2.2.x and later we should think about better ways to have multiple
-  bridge authorities.
-
-3. Bridge users.
-
-  Bridge users are like ordinary Tor users except they use encrypted
-  directory connections by default, and they use bridge relays as both
-  entry guards (their first hop) and directory guards (the source of
-  all their directory information).
-
-  To become a bridge user, add the following line to your torrc:
-    UseBridges 1
-
-  and then add at least one "Bridge" line to your torrc based on the
-  format below.
-
-3.1. Format of the bridge identifier.
-
-  The canonical format for a bridge identifier contains an IP address,
-  an ORPort, and an identity fingerprint:
-    bridge 128.31.0.34:9009 4C17 FB53 2E20 B2A8 AC19 9441 ECD2 B017 7B39 E4B1
-
-  However, the identity fingerprint can be left out, in which case the
-  bridge user will connect to that relay and use it as a bridge regardless
-  of what identity key it presents:
-    bridge 128.31.0.34:9009
-  This might be useful for cases where only short bridge identifiers
-  can be communicated to bridge users.
-
-  In a future version we may also support bridge identifiers that are
-  only a key fingerprint:
-    bridge 4C17 FB53 2E20 B2A8 AC19 9441 ECD2 B017 7B39 E4B1
-  and the bridge user can fetch the latest descriptor from the bridge
-  authority (see Section 3.4).
-
-3.2. Bridges as entry guards
-
-  For now, bridge users add their bridge relays to their list of "entry
-  guards" (see path-spec.txt for background on entry guards). They are
-  managed by the entry guard algorithms exactly as if they were a normal
-  entry guard -- their keys and timing get cached in the "state" file,
-  etc. This means that when the Tor user starts up with "UseBridges"
-  disabled, he will skip past the bridge entries since they won't be
-  listed as up and usable in his networkstatus consensus. But to be clear,
-  the "entry_guards" list doesn't currently distinguish guards by purpose.
-
-  Internally, each bridge user keeps a smartlist of "bridge_info_t"
-  that reflects the "bridge" lines from his torrc along with a download
-  schedule (see Section 3.5 below). When he starts Tor, he attempts
-  to fetch a descriptor for each configured bridge (see Section 3.4
-  below). When he succeeds at getting a descriptor for one of the bridges
-  in his list, he adds it directly to the entry guard list using the
-  normal add_an_entry_guard() interface. Once a bridge descriptor has
-  been added, should_delay_dir_fetches() will stop delaying further
-  directory fetches, and the user begins to bootstrap his directory
-  information from that bridge (see Section 3.3).
-
-  Currently bridge users cache their bridge descriptors to the
-  "cached-descriptors" file (annotated with purpose "bridge"), but
-  they don't make any attempt to reuse descriptors they find in this
-  file. The theory is that either the bridge is available now, in which
-  case you can get a fresh descriptor, or it's not, in which case an
-  old descriptor won't do you much good.
-
-  We could disable writing out the bridge lines to the state file, if
-  we think this is a problem.
-
-  As an exception, if we get an application request when we have one
-  or more bridge descriptors but we believe none of them are running,
-  we mark them all as running again. This is similar to the exception
-  already in place to help long-idle Tor clients realize they should
-  fetch fresh directory information rather than just refuse requests.
-
-3.3. Bridges as directory guards
-
-  In addition to using bridges as the first hop in their circuits, bridge
-  users also use them to fetch directory updates. Other than initial
-  bootstrapping to find a working bridge descriptor (see Section 3.4
-  below), all further non-anonymized directory fetches will be redirected
-  to the bridge.
-
-  This means that bridge relays need to have cached answers for all
-  questions the bridge user might ask. This makes the upgrade path
-  tricky --- for example, if we migrate to a v4 directory design, the
-  bridge user would need to keep using v3 so long as his bridge relays
-  only knew how to answer v3 queries.
-
-  In a future design, for cases where the user has enough information
-  to build circuits yet the chosen bridge doesn't know how to answer a
-  given query, we might teach bridge users to make an anonymized request
-  to a more suitable directory server.
-
-3.4. How bridge users get their bridge descriptor
-
-  Bridge users can fetch bridge descriptors in two ways: by going directly
-  to the bridge and asking for "/tor/server/authority", or by going to
-  the bridge authority and asking for "/tor/server/fp/ID". By default,
-  they will only try the direct queries. If the user sets
-    UpdateBridgesFromAuthority 1
-  in his config file, then he will try querying the bridge authority
-  first for bridges where he knows a digest (if he only knows an IP
-  address and ORPort, then his only option is a direct query).
-
-  If the user has at least one working bridge, then he will do further
-  queries to the bridge authority through a full three-hop Tor circuit.
-  But when bootstrapping, he will make a direct begin_dir-style connection
-  to the bridge authority.
-
-  As of Tor 0.2.0.10-alpha, if the user attempts to fetch a descriptor
-  from the bridge authority and it returns a 404 not found, the user
-  will automatically fall back to trying a direct query. Therefore it is
-  recommended that bridge users always set UpdateBridgesFromAuthority,
-  since at worst it will delay their fetches a little bit and notify
-  the bridge authority of the identity fingerprint (but not location)
-  of their intended bridges.
-
-3.5. Bridge descriptor retry schedule
-
-  Bridge users try to fetch a descriptor for each bridge (using the
-  steps in Section 3.4 above) on startup. Whenever they receive a
-  bridge descriptor, they reschedule a new descriptor download for 1
-  hour from then.
-
-  If on the other hand it fails, they try again after 15 minutes for the
-  first attempt, after 15 minutes for the second attempt, and after 60
-  minutes for subsequent attempts.
-
-  In 0.2.2.x we should come up with some smarter retry schedules.
-
-3.6. Implementation note.
-
-  Vidalia 0.1.0 has a new checkbox in its Network config window called
-  "My ISP blocks connections to the Tor network." Users who click that
-  box change their configuration to:
-    UseBridges 1
-    UpdateBridgesFromAuthority 1
-  and should add at least one bridge identifier.
-
diff --git a/doc/spec/control-spec-v0.txt b/doc/spec/control-spec-v0.txt
deleted file mode 100644
index faf75a6..0000000
--- a/doc/spec/control-spec-v0.txt
+++ /dev/null
@@ -1,499 +0,0 @@
-$Id$
-
-                   TC: A Tor control protocol (Version 0)
-
--1. Deprecation
-
-THIS PROTOCOL IS DEPRECATED.  It is still documented here because Tor
-0.1.1.x happens to support much of it; but the support for v0 is not
-maintained, so you should expect it to rot in unpredictable ways.  Support
-for v0 will be removed some time after Tor 0.1.2.
-
-0. Scope
-
-This document describes an implementation-specific protocol that is used
-for other programs (such as frontend user-interfaces) to communicate
-with a locally running Tor process.  It is not part of the Tor onion
-routing protocol.
-
-We're trying to be pretty extensible here, but not infinitely
-forward-compatible.
-
-1. Protocol outline
-
-TC is a bidirectional message-based protocol.  It assumes an underlying
-stream for communication between a controlling process (the "client") and
-a Tor process (the "server").  The stream may be implemented via TCP,
-TLS-over-TCP, a Unix-domain socket, or so on, but it must provide
-reliable in-order delivery.  For security, the stream should not be
-accessible by untrusted parties.
-
-In TC, the client and server send typed variable-length messages to each
-other over the underlying stream.  By default, all messages from the server
-are in response to messages from the client.  Some client requests, however,
-will cause the server to send messages to the client indefinitely far into
-the future.
-
-Servers respond to messages in the order they're received.
-
-2. Message format
-
-The messages take the following format:
-
-   Length [2 octets; big-endian]
-   Type   [2 octets; big-endian]
-   Body   [Length octets]
-
-Upon encountering a recognized Type, implementations behave as described in
-section 3 below.  If the type is not recognized, servers respond with an
-"ERROR" message (code UNRECOGNIZED; see 3.1 below), and clients simply ignore
-the message.
-
-2.1. Types and encodings
-
-  All numbers are given in big-endian (network) order.
-
-  OR identities are given in hexadecimal, in the same format as identity key
-  fingerprints, but without spaces; see tor-spec.txt for more information.
-
-3. Message types
-
-  Message types are drawn from the following ranges:
-
-  0x0000-0xEFFF   : Reserved for use by official versions of this spec.
-  0xF000-0xFFFF   : Unallocated; usable by unofficial extensions.
-
-3.1. ERROR (Type 0x0000)
-
-  Sent in response to a message that could not be processed as requested.
-
-  The body of the message begins with a 2-byte error code.  The following
-  values are defined:
-
-        0x0000 Unspecified error
-               []
-
-        0x0001 Internal error
-               [Something went wrong inside Tor, so that the client's
-                request couldn't be fulfilled.]
-
-        0x0002 Unrecognized message type
-               [The client sent a message type we don't understand.]
-
-        0x0003 Syntax error
-               [The client sent a message body in a format we can't parse.]
-
-        0x0004 Unrecognized configuration key
-               [The client tried to get or set a configuration option we don't
-                recognize.]
-
-        0x0005 Invalid configuration value
-               [The client tried to set a configuration option to an
-                incorrect, ill-formed, or impossible value.]
-
-        0x0006 Unrecognized byte code
-               [The client tried to set a byte code (in the body) that
-                we don't recognize.]
-
-        0x0007 Unauthorized.
-               [The client tried to send a command that requires
-                authorization, but it hasn't sent a valid AUTHENTICATE
-                message.]
-
-        0x0008 Failed authentication attempt
-               [The client sent a well-formed authorization message.]
-
-        0x0009 Resource exhausted
-               [The server didn't have enough of a given resource to
-                fulfill a given request.]
-
-        0x000A No such stream
-
-        0x000B No such circuit
-
-        0x000C No such OR
-
-  The rest of the body should be a human-readable description of the error.
-
-  In general, new error codes should only be added when they don't fall under
-  one of the existing error codes.
-
-3.2. DONE (Type 0x0001)
-
-  Sent from server to client in response to a request that was successfully
-  completed, with no more information needed.  The body is usually empty but
-  may contain a message.
-
-3.3. SETCONF (Type 0x0002)
-
-  Change the value of a configuration variable. The body contains a list of
-  newline-terminated key-value configuration lines.  An individual key-value
-  configuration line consists of the key, followed by a space, followed by
-  the value. The server behaves as though it had just read the key-value pair
-  in its configuration file.
-
-  The server responds with a DONE message on success, or an ERROR message on
-  failure.
-
-  When a configuration options takes multiple values, or when multiple
-  configuration keys form a context-sensitive group (see below), then
-  setting _any_ of the options in a SETCONF command is taken to reset all of
-  the others.  For example, if two ORBindAddress values are configured,
-  and a SETCONF command arrives containing a single ORBindAddress value, the
-  new command's value replaces the two old values.
-
-  To _remove_ all settings for a given option entirely (and go back to its
-  default value), send a single line containing the key and no value.
-
-3.4. GETCONF (Type 0x0003)
-
-  Request the value of a configuration variable.  The body contains one or
-  more NL-terminated strings for configuration keys.  The server replies
-  with a CONFVALUE message.
-
-  If an option appears multiple times in the configuration, all of its
-  key-value pairs are returned in order.
-
-  Some options are context-sensitive, and depend on other options with
-  different keywords.  These cannot be fetched directly.  Currently there
-  is only one such option: clients should use the "HiddenServiceOptions"
-  virtual keyword to get all HiddenServiceDir, HiddenServicePort,
-  HiddenServiceNodes, and HiddenServiceExcludeNodes option settings.
-
-3.5. CONFVALUE (Type 0x0004)
-
-  Sent in response to a GETCONF message; contains a list of "Key Value\n"
-  (A non-whitespace keyword, a single space, a non-NL value, a NL)
-  strings.
-
-3.6. SETEVENTS (Type 0x0005)
-
-  Request the server to inform the client about interesting events.
-  The body contains a list of 2-byte event codes (see "event" below).
-  Any events *not* listed in the SETEVENTS body are turned off; thus, sending
-  SETEVENTS with an empty body turns off all event reporting.
-
-  The server responds with a DONE message on success, and an ERROR message
-  if one of the event codes isn't recognized.  (On error, the list of active
-  event codes isn't changed.)
-
-3.7. EVENT (Type 0x0006)
-
-  Sent from the server to the client when an event has occurred and the
-  client has requested that kind of event.  The body contains a 2-byte
-  event code followed by additional event-dependent information.  Event
-  codes are:
-      0x0001 -- Circuit status changed
-
-                Status [1 octet]
-                   0x00 Launched - circuit ID assigned to new circuit
-                   0x01 Built    - all hops finished, can now accept streams
-                   0x02 Extended - one more hop has been completed
-                   0x03 Failed   - circuit closed (was not built)
-                   0x04 Closed   - circuit closed (was built)
-                Circuit ID [4 octets]
-                   (Must be unique to Tor process/time)
-                Path [NUL-terminated comma-separated string]
-                   (For extended/failed, is the portion of the path that is
-                   built)
-
-      0x0002 -- Stream status changed
-
-                Status [1 octet]
-                   (Sent connect=0,sent resolve=1,succeeded=2,failed=3,
-                    closed=4, new connection=5, new resolve request=6,
-                    stream detached from circuit and still retriable=7)
-                Stream ID [4 octets]
-                   (Must be unique to Tor process/time)
-                Target (NUL-terminated address-port string]
-
-      0x0003 -- OR Connection status changed
-
-                Status [1 octet]
-                   (Launched=0,connected=1,failed=2,closed=3)
-                OR nickname/identity [NUL-terminated]
-
-      0x0004 -- Bandwidth used in the last second
-
-                Bytes read [4 octets]
-                Bytes written [4 octets]
-
-      0x0005 -- Notice/warning/error occurred
-
-                Message [NUL-terminated]
-
-                <obsolete: use 0x0007-0x000B instead.>
-
-      0x0006 -- New descriptors available
-
-                OR List [NUL-terminated, comma-delimited list of
-                    OR identity]
-
-      0x0007 -- Debug message occurred
-      0x0008 -- Info message occurred
-      0x0009 -- Notice message occurred
-      0x000A -- Warning message occurred
-      0x000B -- Error message occurred
-
-                Message [NUL-terminated]
-
-3.8. AUTHENTICATE (Type 0x0007)
-
-  Sent from the client to the server.  Contains a 'magic cookie' to prove
-  that client is really allowed to control this Tor process.  The server
-  responds with DONE or ERROR.
-
-  The format of the 'cookie' is implementation-dependent; see 4.1 below for
-  information on how the standard Tor implementation handles it.
-
-3.9. SAVECONF (Type 0x0008)
-
-  Sent from the client to the server. Instructs the server to write out
-  its config options into its torrc. Server returns DONE if successful, or
-  ERROR if it can't write the file or some other error occurs.
-
-3.10. SIGNAL (Type 0x0009)
-
-  Sent from the client to the server. The body contains one byte that
-  indicates the action the client wishes the server to take.
-
-       1 (0x01) -- Reload: reload config items, refetch directory.
-       2 (0x02) -- Controlled shutdown: if server is an OP, exit immediately.
-                   If it's an OR, close listeners and exit after 30 seconds.
-      10 (0x0A) -- Dump stats: log information about open connections and
-                   circuits.
-      12 (0x0C) -- Debug: switch all open logs to loglevel debug.
-      15 (0x0F) -- Immediate shutdown: clean up and exit now.
-
-  The server responds with DONE if the signal is recognized (or simply
-  closes the socket if it was asked to close immediately), else ERROR.
-
-3.11. MAPADDRESS (Type 0x000A)
-
-  Sent from the client to the server.  The body contains a sequence of
-  address mappings, each consisting of the address to be mapped, a single
-  space, the replacement address, and a NL character.
-
-  Addresses may be IPv4 addresses, IPv6 addresses, or hostnames.
-
-  The client sends this message to the server in order to tell it that future
-  SOCKS requests for connections to the original address should be replaced
-  with connections to the specified replacement address.  If the addresses
-  are well-formed, and the server is able to fulfill the request, the server
-  replies with a single DONE message containing the source and destination
-  addresses.  If request is malformed, the server replies with a syntax error
-  message.  The server can't fulfill the request, it replies with an internal
-  ERROR message.
-
-  The client may decline to provide a body for the original address, and
-  instead send a special null address ("0.0.0.0" for IPv4, "::0" for IPv6, or
-  "." for hostname), signifying that the server should choose the original
-  address itself, and return that address in the DONE message.  The server
-  should ensure that it returns an element of address space that is unlikely
-  to be in actual use.  If there is already an address mapped to the
-  destination address, the server may reuse that mapping.
-
-  If the original address is already mapped to a different address, the old
-  mapping is removed.  If the original address and the destination address
-  are the same, the server removes any mapping in place for the original
-  address.
-
-  {Note: This feature is designed to be used to help Tor-ify applications
-  that need to use SOCKS4 or hostname-less SOCKS5.  There are three
-  approaches to doing this:
-     1. Somehow make them use SOCKS4a or SOCKS5-with-hostnames instead.
-     2. Use tor-resolve (or another interface to Tor's resolve-over-SOCKS
-        feature) to resolve the hostname remotely.  This doesn't work
-        with special addresses like x.onion or x.y.exit.
-     3. Use MAPADDRESS to map an IP address to the desired hostname, and then
-        arrange to fool the application into thinking that the hostname
-        has resolved to that IP.
-  This functionality is designed to help implement the 3rd approach.}
-
-  [XXXX When, if ever, can mappings expire?  Should they expire?]
-  [XXXX What addresses, if any, are safe to use?]
-
-3.12 GETINFO (Type 0x000B)
-
-  Sent from the client to the server.  The message body is as for GETCONF:
-  one or more NL-terminated strings.  The server replies with an INFOVALUE
-  message.
-
-  Unlike GETCONF, this message is used for data that are not stored in the
-  Tor configuration file, but instead.
-
-  Recognized key and their values include:
-
-    "version" -- The version of the server's software, including the name
-      of the software. (example: "Tor 0.0.9.4")
-
-    "desc/id/<OR identity>" or "desc/name/<OR nickname>" -- the latest server
-      descriptor for a given OR, NUL-terminated.  If no such OR is known, the
-      corresponding value is an empty string.
-
-    "network-status" -- a space-separated list of all known OR identities.
-      This is in the same format as the router-status line in directories;
-      see tor-spec.txt for details.
-
-    "addr-mappings/all"
-    "addr-mappings/config"
-    "addr-mappings/cache"
-    "addr-mappings/control" -- a NL-terminated list of address mappings, each
-      in the form of "from-address" SP "to-address".  The 'config' key
-      returns those address mappings set in the configuration; the 'cache'
-      key returns the mappings in the client-side DNS cache; the 'control'
-      key returns the mappings set via the control interface; the 'all'
-      target returns the mappings set through any mechanism.
-
-3.13 INFOVALUE (Type 0x000C)
-
-  Sent from the server to the client in response to a GETINFO message.
-  Contains one or more items of the format:
-
-     Key          [(NUL-terminated string)]
-     Value        [(NUL-terminated string)]
-
-  The keys match those given in the GETINFO message.
-
-3.14 EXTENDCIRCUIT (Type 0x000D)
-
-  Sent from the client to the server.  The message body contains two fields:
-      Circuit ID [4 octets]
-      Path [NUL-terminated, comma-delimited string of OR nickname/identity]
-
-  This request takes one of two forms: either the Circuit ID is zero, in
-  which case it is a request for the server to build a new circuit according
-  to the specified path, or the Circuit ID is nonzero, in which case it is a
-  request for the server to extend an existing circuit with that ID according
-  to the specified path.
-
-  If the request is successful, the server sends a DONE message containing
-  a message body consisting of the four-octet Circuit ID of the newly created
-  circuit.
-
-3.15 ATTACHSTREAM (Type 0x000E)
-
-  Sent from the client to the server.  The message body contains two fields:
-      Stream ID [4 octets]
-      Circuit ID [4 octets]
-
-  This message informs the server that the specified stream should be
-  associated with the specified circuit.  Each stream may be associated with
-  at most one circuit, and multiple streams may share the same circuit.
-  Streams can only be attached to completed circuits (that is, circuits that
-  have sent a circuit status 'built' event).
-
-  If the circuit ID is 0, responsibility for attaching the given stream is
-  returned to Tor.
-
-  {Implementation note: By default, Tor automatically attaches streams to
-  circuits itself, unless the configuration variable
-  "__LeaveStreamsUnattached" is set to "1".  Attempting to attach streams
-  via TC when "__LeaveStreamsUnattached" is false may cause a race between
-  Tor and the controller, as both attempt to attach streams to circuits.}
-
-3.16 POSTDESCRIPTOR (Type 0x000F)
-
-  Sent from the client to the server.  The message body contains one field:
-      Descriptor [NUL-terminated string]
-
-  This message informs the server about a new descriptor.
-
-  The descriptor, when parsed, must contain a number of well-specified
-  fields, including fields for its nickname and identity.
-
-  If there is an error in parsing the descriptor, the server must send an
-  appropriate error message.  If the descriptor is well-formed but the server
-  chooses not to add it, it must reply with a DONE message whose body
-  explains why the server was not added.
-
-3.17 FRAGMENTHEADER (Type 0x0010)
-
-  Sent in either direction.  Used to encapsulate messages longer than 65535
-  bytes in length.
-
-      Underlying type [2 bytes]
-      Total Length    [4 bytes]
-      Data            [Rest of message]
-
-  A FRAGMENTHEADER message MUST be followed immediately by a number of
-  FRAGMENT messages, such that lengths of the "Data" fields of the
-  FRAGMENTHEADER and FRAGMENT messages add to the "Total Length" field of the
-  FRAGMENTHEADER message.
-
-  Implementations MUST NOT fragment messages of length less than 65536 bytes.
-  Implementations MUST be able to process fragmented messages that not
-  optimally packed.
-
-3.18 FRAGMENT (Type 0x0011)
-
-      Data           [Entire message]
-
-  See FRAGMENTHEADER for more information
-
-3.19 REDIRECTSTREAM (Type 0x0012)
-
-  Sent from the client to the server. The message body contains two fields:
-      Stream ID [4 octets]
-      Address [variable-length, NUL-terminated.]
-
-  Tells the server to change the exit address on the specified stream.  No
-  remapping is performed on the new provided address.
-
-  To be sure that the modified address will be used, this event must be sent
-  after a new stream event is received, and before attaching this stream to
-  a circuit.
-
-3.20 CLOSESTREAM (Type 0x0013)
-
-  Sent from the client to the server.  The message body contains three
-  fields:
-      Stream ID [4 octets]
-      Reason    [1 octet]
-      Flags     [1 octet]
-
-  Tells the server to close the specified stream.  The reason should be
-  one of the Tor RELAY_END reasons given in tor-spec.txt.  Flags is not
-  used currently.  Tor may hold the stream open for a while to flush
-  any data that is pending.
-
-3.21 CLOSECIRCUIT (Type 0x0014)
-
-  Sent from the client to the server.  The message body contains two
-  fields:
-     Circuit ID [4 octets]
-     Flags      [1 octet]
-
-  Tells the server to close the specified circuit.  If the LSB of the flags
-  field is nonzero, do not close the circuit unless it is unused.
-
-4. Implementation notes
-
-4.1. Authentication
-
-  By default, the current Tor implementation trusts all local users.
-
-  If the 'CookieAuthentication' option is true, Tor writes a "magic cookie"
-  file named "control_auth_cookie" into its data directory.  To authenticate,
-  the controller must send the contents of this file.
-
-  If the 'HashedControlPassword' option is set, it must contain the salted
-  hash of a secret password.  The salted hash is computed according to the
-  S2K algorithm in RFC 2440 (OpenPGP), and prefixed with the s2k specifier.
-  This is then encoded in hexadecimal, prefixed by the indicator sequence
-  "16:".  Thus, for example, the password 'foo' could encode to:
-     16:660537E3E1CD49996044A3BF558097A981F539FEA2F9DA662B4626C1C2
-        ++++++++++++++++**^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-           salt                       hashed value
-                       indicator
-  You can generate the salt of a password by calling
-           'tor --hash-password <password>'
-  or by using the example code in the Python and Java controller libraries.
-  To authenticate under this scheme, the controller sends Tor the original
-  secret that was used to generate the password.
-
-4.2. Don't let the buffer get too big.
-
-  If you ask for lots of events, and 16MB of them queue up on the buffer,
-  the Tor process will close the socket.
-
diff --git a/doc/spec/control-spec.txt b/doc/spec/control-spec.txt
deleted file mode 100644
index cf92e2b..0000000
--- a/doc/spec/control-spec.txt
+++ /dev/null
@@ -1,1854 +0,0 @@
-$Id$
-
-                   TC: A Tor control protocol (Version 1)
-
-0. Scope
-
-  This document describes an implementation-specific protocol that is used
-  for other programs (such as frontend user-interfaces) to communicate with a
-  locally running Tor process.  It is not part of the Tor onion routing
-  protocol.
-
-  This protocol replaces version 0 of TC, which is now deprecated.  For
-  reference, TC is described in "control-spec-v0.txt".  Implementors are
-  recommended to avoid using TC directly, but instead to use a library that
-  can easily be updated to use the newer protocol.  (Version 0 is used by Tor
-  versions 0.1.0.x; the protocol in this document only works with Tor
-  versions in the 0.1.1.x series and later.)
-
-1. Protocol outline
-
-  TC is a bidirectional message-based protocol.  It assumes an underlying
-  stream for communication between a controlling process (the "client"
-  or "controller") and a Tor process (or "server").  The stream may be
-  implemented via TCP, TLS-over-TCP, a Unix-domain socket, or so on,
-  but it must provide reliable in-order delivery.  For security, the
-  stream should not be accessible by untrusted parties.
-
-  In TC, the client and server send typed messages to each other over the
-  underlying stream.  The client sends "commands" and the server sends
-  "replies".
-
-  By default, all messages from the server are in response to messages from
-  the client.  Some client requests, however, will cause the server to send
-  messages to the client indefinitely far into the future.  Such
-  "asynchronous" replies are marked as such.
-
-  Servers respond to messages in the order messages are received.
-
-2. Message format
-
-2.1. Description format
-
-  The message formats listed below use ABNF as described in RFC 2234.
-  The protocol itself is loosely based on SMTP (see RFC 2821).
-
-  We use the following nonterminals from RFC 2822: atom, qcontent
-
-  We define the following general-use nonterminals:
-
-     String = DQUOTE *qcontent DQUOTE
-
-  There are explicitly no limits on line length.  All 8-bit characters are
-  permitted unless explicitly disallowed.
-
-  Wherever CRLF is specified to be accepted from the controller, Tor MAY also
-  accept LF.  Tor, however, MUST NOT generate LF instead of CRLF.
-  Controllers SHOULD always send CRLF.
-
-2.2. Commands from controller to Tor
-
-    Command = Keyword Arguments CRLF / "+" Keyword Arguments CRLF Data
-    Keyword = 1*ALPHA
-    Arguments = *(SP / VCHAR)
-
-  Specific commands and their arguments are described below in section 3.
-
-2.3. Replies from Tor to the controller
-
-    Reply = SyncReply / AsyncReply
-    SyncReply = *(MidReplyLine / DataReplyLine) EndReplyLine
-    AsyncReply = *(MidReplyLine / DataReplyLine) EndReplyLine
-
-    MidReplyLine = StatusCode "-" ReplyLine
-    DataReplyLine = StatusCode "+" ReplyLine Data
-    EndReplyLine = StatusCode SP ReplyLine
-    ReplyLine = [ReplyText] CRLF
-    ReplyText = XXXX
-    StatusCode = 3DIGIT
-
-  Specific replies are mentioned below in section 3, and described more fully
-  in section 4.
-
-  [Compatibility note:  versions of Tor before 0.2.0.3-alpha sometimes
-  generate AsyncReplies of the form "*(MidReplyLine / DataReplyLine)".
-  This is incorrect, but controllers that need to work with these
-  versions of Tor should be prepared to get multi-line AsyncReplies with
-  the final line (usually "650 OK") omitted.]
-
-2.4. General-use tokens
-
-  ; Identifiers for servers.
-  ServerID = Nickname / Fingerprint
-
-  Nickname = 1*19 NicknameChar
-  NicknameChar = "a"-"z" / "A"-"Z" / "0" - "9"
-  Fingerprint = "$" 40*HEXDIG
-
-  ; A "=" indicates that the given nickname is canonical; a "~" indicates
-  ; that the given nickname is not canonical.  If no nickname is given at
-  ; all, Tor does not even have a guess for what this router calls itself.
-  LongName = Fingerprint [ ( "=" / "~" ) Nickname ]
-
-  ; How a controller tells Tor about a particular OR.  There are four
-  ; possible formats:
-  ;    $Digest -- The router whose identity key hashes to the given digest.
-  ;        This is the preferred way to refer to an OR.
-  ;    $Digest~Name -- The router whose identity key hashes to the given
-  ;        digest, but only if the router has the given nickname.
-  ;    $Digest=Name -- The router whose identity key hashes to the given
-  ;        digest, but only if the router is Named and has the given
-  ;        nickname.
-  ;    Name -- The Named router with the given nickname, or, if no such
-  ;        router exists, any router whose nickname matches the one given.
-  ;        This is not a safe way to refer to routers, since Named status
-  ;        could under some circumstances change over time.
-  ServerSpec = LongName / Nickname
-
-  ; Unique identifiers for streams or circuits.  Currently, Tor only
-  ; uses digits, but this may change
-  StreamID = 1*16 IDChar
-  CircuitID = 1*16 IDChar
-  IDChar = ALPHA / DIGIT
-
-  Address = ip4-address / ip6-address / hostname   (XXXX Define these)
-
-  ; A "Data" section is a sequence of octets concluded by the terminating
-  ; sequence CRLF "." CRLF.  The terminating sequence may not appear in the
-  ; body of the data.  Leading periods on lines in the data are escaped with
-  ; an additional leading period as in RFC 2821 section 4.5.2.
-  Data = *DataLine "." CRLF
-  DataLine = CRLF / "." 1*LineItem CRLF / NonDotItem *LineItem CRLF
-  LineItem = NonCR / 1*CR NonCRLF
-  NonDotItem = NonDotCR / 1*CR NonCRLF
-
-3. Commands
-
-  All commands are case-insensitive, but most keywords are case-sensitive.
-
-3.1. SETCONF
-
-  Change the value of one or more configuration variables.  The syntax is:
-
-    "SETCONF" 1*(SP keyword ["=" value]) CRLF
-    value = String / QuotedString
-
-  Tor behaves as though it had just read each of the key-value pairs
-  from its configuration file.  Keywords with no corresponding values have
-  their configuration values reset to 0 or NULL (use RESETCONF if you want
-  to set it back to its default).  SETCONF is all-or-nothing: if there
-  is an error in any of the configuration settings, Tor sets none of them.
-
-  Tor responds with a "250 configuration values set" reply on success.
-  If some of the listed keywords can't be found, Tor replies with a
-  "552 Unrecognized option" message. Otherwise, Tor responds with a
-  "513 syntax error in configuration values" reply on syntax error, or a
-  "553 impossible configuration setting" reply on a semantic error.
-
-  When a configuration option takes multiple values, or when multiple
-  configuration keys form a context-sensitive group (see GETCONF below), then
-  setting _any_ of the options in a SETCONF command is taken to reset all of
-  the others.  For example, if two ORBindAddress values are configured, and a
-  SETCONF command arrives containing a single ORBindAddress value, the new
-  command's value replaces the two old values.
-
-  Sometimes it is not possible to change configuration options solely by
-  issuing a series of SETCONF commands, because the value of one of the
-  configuration options depends on the value of another which has not yet
-  been set. Such situations can be overcome by setting multiple configuration
-  options with a single SETCONF command (e.g. SETCONF ORPort=443
-  ORListenAddress=9001).
-
-3.2. RESETCONF
-
-  Remove all settings for a given configuration option entirely, assign
-  its default value (if any), and then assign the String provided.
-  Typically the String is left empty, to simply set an option back to
-  its default. The syntax is:
-
-    "RESETCONF" 1*(SP keyword ["=" String]) CRLF
-
-  Otherwise it behaves like SETCONF above.
-
-3.3. GETCONF
-
-  Request the value of a configuration variable.  The syntax is:
-
-    "GETCONF" 1*(SP keyword) CRLF
-
-  If all of the listed keywords exist in the Tor configuration, Tor replies
-  with a series of reply lines of the form:
-      250 keyword=value
-  If any option is set to a 'default' value semantically different from an
-  empty string, Tor may reply with a reply line of the form:
-      250 keyword
-
-  Value may be a raw value or a quoted string.  Tor will try to use
-  unquoted values except when the value could be misinterpreted through
-  not being quoted.
-
-  If some of the listed keywords can't be found, Tor replies with a
-  "552 unknown configuration keyword" message.
-
-  If an option appears multiple times in the configuration, all of its
-  key-value pairs are returned in order.
-
-  Some options are context-sensitive, and depend on other options with
-  different keywords.  These cannot be fetched directly.  Currently there
-  is only one such option: clients should use the "HiddenServiceOptions"
-  virtual keyword to get all HiddenServiceDir, HiddenServicePort,
-  HiddenServiceNodes, and HiddenServiceExcludeNodes option settings.
-
-3.4. SETEVENTS
-
-  Request the server to inform the client about interesting events.  The
-  syntax is:
-
-     "SETEVENTS" [SP "EXTENDED"] *(SP EventCode) CRLF
-
-     EventCode = "CIRC" / "STREAM" / "ORCONN" / "BW" / "DEBUG" /
-         "INFO" / "NOTICE" / "WARN" / "ERR" / "NEWDESC" / "ADDRMAP" /
-         "AUTHDIR_NEWDESCS" / "DESCCHANGED" / "STATUS_GENERAL" /
-         "STATUS_CLIENT" / "STATUS_SERVER" / "GUARD" / "NS" / "STREAM_BW" /
-         "CLIENTS_SEEN"
-
-  Any events *not* listed in the SETEVENTS line are turned off; thus, sending
-  SETEVENTS with an empty body turns off all event reporting.
-
-  The server responds with a "250 OK" reply on success, and a "552
-  Unrecognized event" reply if one of the event codes isn't recognized.  (On
-  error, the list of active event codes isn't changed.)
-
-  If the flag string "EXTENDED" is provided, Tor may provide extra
-  information with events for this connection; see 4.1 for more information.
-  NOTE: All events on a given connection will be provided in extended format,
-  or none.
-  NOTE: "EXTENDED" is only supported in Tor 0.1.1.9-alpha or later.
-
-  Each event is described in more detail in Section 4.1.
-
-3.5. AUTHENTICATE
-
-  Sent from the client to the server.  The syntax is:
-     "AUTHENTICATE" [ SP 1*HEXDIG / QuotedString ] CRLF
-
-  The server responds with "250 OK" on success or "515 Bad authentication" if
-  the authentication cookie is incorrect.  Tor closes the connection on an
-  authentication failure.
-
-  The format of the 'cookie' is implementation-dependent; see 5.1 below for
-  information on how the standard Tor implementation handles it.
-
-  Before the client has authenticated, no command other than PROTOCOLINFO,
-  AUTHENTICATE, or QUIT is valid.  If the controller sends any other command,
-  or sends a malformed command, or sends an unsuccessful AUTHENTICATE
-  command, or sends PROTOCOLINFO more than once, Tor sends an error reply and
-  closes the connection.
-
-  To prevent some cross-protocol attacks, the AUTHENTICATE command is still
-  required even if all authentication methods in Tor are disabled.  In this
-  case, the controller should just send "AUTHENTICATE" CRLF.
-
-  (Versions of Tor before 0.1.2.16 and 0.2.0.4-alpha did not close the
-  connection after an authentication failure.)
-
-3.6. SAVECONF
-
-  Sent from the client to the server.  The syntax is:
-     "SAVECONF" CRLF
-
-  Instructs the server to write out its config options into its torrc. Server
-  returns "250 OK" if successful, or "551 Unable to write configuration
-  to disk" if it can't write the file or some other error occurs.
-
-3.7. SIGNAL
-
-  Sent from the client to the server. The syntax is:
-
-     "SIGNAL" SP Signal CRLF
-
-     Signal = "RELOAD" / "SHUTDOWN" / "DUMP" / "DEBUG" / "HALT" /
-              "HUP" / "INT" / "USR1" / "USR2" / "TERM" / "NEWNYM" /
-              "CLEARDNSCACHE"
-
-  The meaning of the signals are:
-
-      RELOAD    -- Reload: reload config items, refetch directory. (like HUP)
-      SHUTDOWN  -- Controlled shutdown: if server is an OP, exit immediately.
-                   If it's an OR, close listeners and exit after 30 seconds.
-                   (like INT)
-      DUMP      -- Dump stats: log information about open connections and
-                   circuits. (like USR1)
-      DEBUG     -- Debug: switch all open logs to loglevel debug. (like USR2)
-      HALT      -- Immediate shutdown: clean up and exit now. (like TERM)
-      CLEARDNSCACHE -- Forget the client-side cached IPs for all hostnames.
-      NEWNYM    -- Switch to clean circuits, so new application requests
-                   don't share any circuits with old ones.  Also clears
-                   the client-side DNS cache.  (Tor MAY rate-limit its
-                   response to this signal.)
-
-  The server responds with "250 OK" if the signal is recognized (or simply
-  closes the socket if it was asked to close immediately), or "552
-  Unrecognized signal" if the signal is unrecognized.
-
-3.8. MAPADDRESS
-
-  Sent from the client to the server.  The syntax is:
-
-    "MAPADDRESS" 1*(Address "=" Address SP) CRLF
-
-  The first address in each pair is an "original" address; the second is a
-  "replacement" address.  The client sends this message to the server in
-  order to tell it that future SOCKS requests for connections to the original
-  address should be replaced with connections to the specified replacement
-  address.  If the addresses are well-formed, and the server is able to
-  fulfill the request, the server replies with a 250 message:
-    250-OldAddress1=NewAddress1
-    250 OldAddress2=NewAddress2
-
-  containing the source and destination addresses.  If request is
-  malformed, the server replies with "512 syntax error in command
-  argument".  If the server can't fulfill the request, it replies with
-  "451 resource exhausted".
-
-  The client may decline to provide a body for the original address, and
-  instead send a special null address ("0.0.0.0" for IPv4, "::0" for IPv6, or
-  "." for hostname), signifying that the server should choose the original
-  address itself, and return that address in the reply.  The server
-  should ensure that it returns an element of address space that is unlikely
-  to be in actual use.  If there is already an address mapped to the
-  destination address, the server may reuse that mapping.
-
-  If the original address is already mapped to a different address, the old
-  mapping is removed.  If the original address and the destination address
-  are the same, the server removes any mapping in place for the original
-  address.
-
-  Example:
-    C: MAPADDRESS 0.0.0.0=torproject.org 1.2.3.4=tor.freehaven.net
-    S: 250-127.192.10.10=torproject.org
-    S: 250 1.2.3.4=tor.freehaven.net
-
-  {Note: This feature is designed to be used to help Tor-ify applications
-  that need to use SOCKS4 or hostname-less SOCKS5.  There are three
-  approaches to doing this:
-     1. Somehow make them use SOCKS4a or SOCKS5-with-hostnames instead.
-     2. Use tor-resolve (or another interface to Tor's resolve-over-SOCKS
-        feature) to resolve the hostname remotely.  This doesn't work
-        with special addresses like x.onion or x.y.exit.
-     3. Use MAPADDRESS to map an IP address to the desired hostname, and then
-        arrange to fool the application into thinking that the hostname
-        has resolved to that IP.
-  This functionality is designed to help implement the 3rd approach.}
-
-  Mappings set by the controller last until the Tor process exits:
-  they never expire. If the controller wants the mapping to last only
-  a certain time, then it must explicitly un-map the address when that
-  time has elapsed.
-
-3.9. GETINFO
-
-  Sent from the client to the server.  The syntax is as for GETCONF:
-    "GETINFO" 1*(SP keyword) CRLF
-  one or more NL-terminated strings.  The server replies with an INFOVALUE
-  message, or a 551 or 552 error.
-
-  Unlike GETCONF, this message is used for data that are not stored in the Tor
-  configuration file, and that may be longer than a single line.  On success,
-  one ReplyLine is sent for each requested value, followed by a final 250 OK
-  ReplyLine.  If a value fits on a single line, the format is:
-      250-keyword=value
-  If a value must be split over multiple lines, the format is:
-      250+keyword=
-      value
-      .
-  Recognized keys and their values include:
-
-    "version" -- The version of the server's software, including the name
-      of the software. (example: "Tor 0.0.9.4")
-
-    "config-file" -- The location of Tor's configuration file ("torrc").
-
-    ["exit-policy/prepend" -- The default exit policy lines that Tor will
-      *prepend* to the ExitPolicy config option.
-     -- Never implemented. Useful?]
-
-    "exit-policy/default" -- The default exit policy lines that Tor will
-      *append* to the ExitPolicy config option.
-
-    "desc/id/<OR identity>" or "desc/name/<OR nickname>" -- the latest
-      server descriptor for a given OR, NUL-terminated.
-
-    "desc-annotations/id/<OR identity>" -- outputs the annotations string
-      (source, timestamp of arrival, purpose, etc) for the corresponding
-      descriptor. [First implemented in 0.2.0.13-alpha.]
-
-    "extra-info/digest/<digest>"  -- the extrainfo document whose digest (in
-      hex) is <digest>.  Only available if we're downloading extra-info
-      documents.
-
-    "ns/id/<OR identity>" or "ns/name/<OR nickname>" -- the latest router
-      status info (v2 directory style) for a given OR.  Router status
-      info is as given in
-      dir-spec.txt, and reflects the current beliefs of this Tor about the
-      router in question. Like directory clients, controllers MUST
-      tolerate unrecognized flags and lines.  The published date and
-      descriptor digest are those believed to be best by this Tor,
-      not necessarily those for a descriptor that Tor currently has.
-      [First implemented in 0.1.2.3-alpha.]
-
-    "ns/all" -- Router status info (v2 directory style) for all ORs we
-      have an opinion about, joined by newlines. [First implemented
-      in 0.1.2.3-alpha.]
-
-    "ns/purpose/<purpose>" -- Router status info (v2 directory style)
-      for all ORs of this purpose. Mostly designed for /ns/purpose/bridge
-      queries. [First implemented in 0.2.0.13-alpha.]
-
-    "desc/all-recent" -- the latest server descriptor for every router that
-      Tor knows about.
-
-    "network-status" -- a space-separated list (v1 directory style)
-      of all known OR identities. This is in the same format as the
-      router-status line in v1 directories; see dir-spec-v1.txt section
-      3 for details.  (If VERBOSE_NAMES is enabled, the output will
-      not conform to dir-spec-v1.txt; instead, the result will be a
-      space-separated list of LongName, each preceded by a "!" if it is
-      believed to be not running.) This option is deprecated; use
-      "ns/all" instead.
-
-    "address-mappings/all"
-    "address-mappings/config"
-    "address-mappings/cache"
-    "address-mappings/control" -- a \r\n-separated list of address
-      mappings, each in the form of "from-address to-address expiry".
-      The 'config' key returns those address mappings set in the
-      configuration; the 'cache' key returns the mappings in the
-      client-side DNS cache; the 'control' key returns the mappings set
-      via the control interface; the 'all' target returns the mappings
-      set through any mechanism.
-      Expiry is formatted as with ADDRMAP events, except that "expiry" is
-      always a time in GMT or the string "NEVER"; see section 4.1.7.
-      First introduced in 0.2.0.3-alpha.
-
-    "addr-mappings/*" -- as for address-mappings/*, but without the
-      expiry portion of the value.  Use of this value is deprecated
-      since 0.2.0.3-alpha; use address-mappings instead.
-
-    "address" -- the best guess at our external IP address. If we
-      have no guess, return a 551 error. (Added in 0.1.2.2-alpha)
-
-    "fingerprint" -- the contents of the fingerprint file that Tor
-      writes as a server, or a 551 if we're not a server currently.
-      (Added in 0.1.2.3-alpha)
-
-    "circuit-status"
-      A series of lines as for a circuit status event. Each line is of
-      the form:
-         CircuitID SP CircStatus [SP Path] CRLF
-
-    "stream-status"
-      A series of lines as for a stream status event.  Each is of the form:
-         StreamID SP StreamStatus SP CircID SP Target CRLF
-
-    "orconn-status"
-      A series of lines as for an OR connection status event.  Each is of the
-      form:
-         ServerID SP ORStatus CRLF
-
-    "entry-guards"
-      A series of lines listing the currently chosen entry guards, if any.
-      Each is of the form:
-         ServerID2 SP Status [SP ISOTime] CRLF
-
-         Status-with-time = ("unlisted") SP ISOTime
-         Status = ("up" / "never-connected" / "down" /
-                      "unusable" / "unlisted" )
-
-         ServerID2 = Nickname / 40*HEXDIG
-
-      [From 0.1.1.4-alpha to 0.1.1.10-alpha, this was called "helper-nodes".
-       Tor still supports calling it that for now, but support will be
-       removed in 0.1.3.x.]
-
-      [Older versions of Tor (before 0.1.2.x-final) generated 'down' instead
-       of unlisted/unusable.  Current Tors never generate 'down'.]
-
-      [XXXX ServerID2 differs from ServerID in not prefixing fingerprints
-       with a $.  This is an implementation error.  It would be nice to add
-       the $ back in if we can do so without breaking compatibility.]
-
-    "accounting/enabled"
-    "accounting/hibernating"
-    "accounting/bytes"
-    "accounting/bytes-left"
-    "accounting/interval-start"
-    "accounting/interval-wake"
-    "accounting/interval-end"
-      Information about accounting status.  If accounting is enabled,
-      "enabled" is 1; otherwise it is 0.  The "hibernating" field is "hard"
-      if we are accepting no data; "soft" if we're accepting no new
-      connections, and "awake" if we're not hibernating at all.  The "bytes"
-      and "bytes-left" fields contain (read-bytes SP write-bytes), for the
-      start and the rest of the interval respectively.  The 'interval-start'
-      and 'interval-end' fields are the borders of the current interval; the
-      'interval-wake' field is the time within the current interval (if any)
-      where we plan[ned] to start being active.
-
-    "config/names"
-      A series of lines listing the available configuration options. Each is
-      of the form:
-         OptionName SP OptionType [ SP Documentation ] CRLF
-         OptionName = Keyword
-         OptionType = "Integer" / "TimeInterval" / "DataSize" / "Float" /
-           "Boolean" / "Time" / "CommaList" / "Dependant" / "Virtual" /
-           "String" / "LineList"
-         Documentation = Text
-
-    "info/names"
-      A series of lines listing the available GETINFO options.  Each is of
-      one of these forms:
-         OptionName SP Documentation CRLF
-         OptionPrefix SP Documentation CRLF
-         OptionPrefix = OptionName "/*"
-
-    "events/names"
-      A space-separated list of all the events supported by this version of
-      Tor's SETEVENTS.
-
-    "features/names"
-      A space-separated list of all the events supported by this version of
-      Tor's USEFEATURE.
-
-    "ip-to-country/*"
-      Maps IP addresses to 2-letter country codes.  For example,
-      "GETINFO ip-to-country/18.0.0.1" should give "US".
-
-    "next-circuit/IP:port"
-      XXX todo.
-
-    "dir/status-vote/current/consensus" [added in Tor 0.2.1.6-alpha]
-    "dir/status/authority"
-    "dir/status/fp/<F>"
-    "dir/status/fp/<F1>+<F2>+<F3>"
-    "dir/status/all"
-    "dir/server/fp/<F>"
-    "dir/server/fp/<F1>+<F2>+<F3>"
-    "dir/server/d/<D>"
-    "dir/server/d/<D1>+<D2>+<D3>"
-    "dir/server/authority"
-    "dir/server/all"
-      A series of lines listing directory contents, provided according to the
-      specification for the URLs listed in Section 4.4 of dir-spec.txt.  Note
-      that Tor MUST NOT provide private information, such as descriptors for
-      routers not marked as general-purpose.  When asked for 'authority'
-      information for which this Tor is not authoritative, Tor replies with
-      an empty string.
-
-    "status/circuit-established"
-    "status/enough-dir-info"
-    "status/good-server-descriptor"
-    "status/accepted-server-descriptor"
-    "status/..."
-      These provide the current internal Tor values for various Tor
-      states. See Section 4.1.10 for explanations. (Only a few of the
-      status events are available as getinfo's currently. Let us know if
-      you want more exposed.)
-    "status/reachability/or"
-      0 or 1, depending on whether we've found our ORPort reachable.
-    "status/reachability/dir"
-      0 or 1, depending on whether we've found our DirPort reachable.
-    "status/reachability"
-      "OR=" ("0"/"1") SP "DIR=" ("0"/"1")
-      Combines status/reachability/*; controllers MUST ignore unrecognized
-      elements in this entry.
-    "status/bootstrap-phase"
-      Returns the most recent bootstrap phase status event
-      sent. Specifically, it returns a string starting with either
-      "NOTICE BOOTSTRAP ..." or "WARN BOOTSTRAP ...". Controllers should
-      use this getinfo when they connect or attach to Tor to learn its
-      current bootstrap state.
-    "status/version/recommended"
-      List of currently recommended versions.
-    "status/version/current"
-      Status of the current version. One of: new, old, unrecommended,
-      recommended, new in series, obsolete.
-    "status/clients-seen"
-      A summary of which countries we've seen clients from recently,
-      formatted the same as the CLIENTS_SEEN status event described in
-      Section 4.1.14. This GETINFO option is currently available only
-      for bridge relays.
-
-  Examples:
-     C: GETINFO version desc/name/moria1
-     S: 250+desc/name/moria=
-     S: [Descriptor for moria]
-     S: .
-     S: 250-version=Tor 0.1.1.0-alpha-cvs
-     S: 250 OK
-
-3.10. EXTENDCIRCUIT
-
-  Sent from the client to the server.  The format is:
-      "EXTENDCIRCUIT" SP CircuitID SP
-                      ServerSpec *("," ServerSpec)
-                      [SP "purpose=" Purpose] CRLF
-
-  This request takes one of two forms: either the CircuitID is zero, in
-  which case it is a request for the server to build a new circuit according
-  to the specified path, or the CircuitID is nonzero, in which case it is a
-  request for the server to extend an existing circuit with that ID according
-  to the specified path.
-
-  If CircuitID is 0 and "purpose=" is specified, then the circuit's
-  purpose is set. Two choices are recognized: "general" and
-  "controller". If not specified, circuits are created as "general".
-
-  If the request is successful, the server sends a reply containing a
-  message body consisting of the CircuitID of the (maybe newly created)
-  circuit. The syntax is "250" SP "EXTENDED" SP CircuitID CRLF.
-
-3.11. SETCIRCUITPURPOSE
-
-  Sent from the client to the server.  The format is:
-      "SETCIRCUITPURPOSE" SP CircuitID SP Purpose CRLF
-
-  This changes the circuit's purpose. See EXTENDCIRCUIT above for details.
-
-3.12. SETROUTERPURPOSE
-
-  Sent from the client to the server.  The format is:
-      "SETROUTERPURPOSE" SP NicknameOrKey SP Purpose CRLF
-
-  This changes the descriptor's purpose. See +POSTDESCRIPTOR below
-  for details.
-
-  NOTE: This command was disabled and made obsolete as of Tor
-  0.2.0.8-alpha. It doesn't exist anymore, and is listed here only for
-  historical interest.
-
-3.13. ATTACHSTREAM
-
-  Sent from the client to the server.  The syntax is:
-     "ATTACHSTREAM" SP StreamID SP CircuitID [SP "HOP=" HopNum] CRLF
-
-  This message informs the server that the specified stream should be
-  associated with the specified circuit.  Each stream may be associated with
-  at most one circuit, and multiple streams may share the same circuit.
-  Streams can only be attached to completed circuits (that is, circuits that
-  have sent a circuit status 'BUILT' event or are listed as built in a
-  GETINFO circuit-status request).
-
-  If the circuit ID is 0, responsibility for attaching the given stream is
-  returned to Tor.
-
-  If HOP=HopNum is specified, Tor will choose the HopNumth hop in the
-  circuit as the exit node, rather than the last node in the circuit.
-  Hops are 1-indexed; generally, it is not permitted to attach to hop 1.
-
-  Tor responds with "250 OK" if it can attach the stream, 552 if the circuit
-  or stream didn't exist, or 551 if the stream couldn't be attached for
-  another reason.
-
-  {Implementation note: Tor will close unattached streams by itself,
-  roughly two minutes after they are born. Let the developers know if
-  that turns out to be a problem.}
-
-  {Implementation note: By default, Tor automatically attaches streams to
-  circuits itself, unless the configuration variable
-  "__LeaveStreamsUnattached" is set to "1".  Attempting to attach streams
-  via TC when "__LeaveStreamsUnattached" is false may cause a race between
-  Tor and the controller, as both attempt to attach streams to circuits.}
-
-  {Implementation note: You can try to attachstream to a stream that
-  has already sent a connect or resolve request but hasn't succeeded
-  yet, in which case Tor will detach the stream from its current circuit
-  before proceeding with the new attach request.}
-
-3.14. POSTDESCRIPTOR
-
-  Sent from the client to the server. The syntax is:
-    "+POSTDESCRIPTOR" [SP "purpose=" Purpose] [SP "cache=" Cache]
-                      CRLF Descriptor CRLF "." CRLF
-
-  This message informs the server about a new descriptor. If Purpose is
-  specified, it must be either "general", "controller", or "bridge",
-  else we return a 552 error. The default is "general".
-
-  If Cache is specified, it must be either "no" or "yes", else we
-  return a 552 error. If Cache is not specified, Tor will decide for
-  itself whether it wants to cache the descriptor, and controllers
-  must not rely on its choice.
-
-  The descriptor, when parsed, must contain a number of well-specified
-  fields, including fields for its nickname and identity.
-
-  If there is an error in parsing the descriptor, the server must send a
-  "554 Invalid descriptor" reply. If the descriptor is well-formed but
-  the server chooses not to add it, it must reply with a 251 message
-  whose body explains why the server was not added. If the descriptor
-  is added, Tor replies with "250 OK".
-
-3.15. REDIRECTSTREAM
-
-  Sent from the client to the server. The syntax is:
-    "REDIRECTSTREAM" SP StreamID SP Address [SP Port] CRLF
-
-  Tells the server to change the exit address on the specified stream.  If
-  Port is specified, changes the destination port as well.  No remapping
-  is performed on the new provided address.
-
-  To be sure that the modified address will be used, this event must be sent
-  after a new stream event is received, and before attaching this stream to
-  a circuit.
-
-  Tor replies with "250 OK" on success.
-
-3.16. CLOSESTREAM
-
-  Sent from the client to the server.  The syntax is:
-
-    "CLOSESTREAM" SP StreamID SP Reason *(SP Flag) CRLF
-
-  Tells the server to close the specified stream.  The reason should be one
-  of the Tor RELAY_END reasons given in tor-spec.txt, as a decimal.  Flags is
-  not used currently; Tor servers SHOULD ignore unrecognized flags.  Tor may
-  hold the stream open for a while to flush any data that is pending.
-
-  Tor replies with "250 OK" on success, or a 512 if there aren't enough
-  arguments, or a 552 if it doesn't recognize the StreamID or reason.
-
-3.17. CLOSECIRCUIT
-
-   The syntax is:
-     CLOSECIRCUIT SP CircuitID *(SP Flag) CRLF
-     Flag = "IfUnused"
-
-  Tells the server to close the specified circuit.   If "IfUnused" is
-  provided, do not close the circuit unless it is unused.
-
-  Other flags may be defined in the future; Tor SHOULD ignore unrecognized
-  flags.
-
-  Tor replies with "250 OK" on success, or a 512 if there aren't enough
-  arguments, or a 552 if it doesn't recognize the CircuitID.
-
-3.18. QUIT
-
-  Tells the server to hang up on this controller connection. This command
-  can be used before authenticating.
-
-3.19. USEFEATURE
-
-  The syntax is:
-
-    "USEFEATURE" *(SP FeatureName) CRLF
-    FeatureName = 1*(ALPHA / DIGIT / "_" / "-")
-
-  Sometimes extensions to the controller protocol break compatibility with
-  older controllers.  In this case, whenever possible, the extensions are
-  first included in Tor disabled by default, and only enabled on a given
-  controller connection when the "USEFEATURE" command is given.  Once a
-  "USEFEATURE" command is given, it applies to all subsequent interactions on
-  the same connection; to disable an enabled feature, a new controller
-  connection must be opened.
-
-  This is a forward-compatibility mechanism; each feature will eventually
-  become a regular part of the control protocol in some future version of Tor.
-  Tor will ignore a request to use any feature that is already on by default.
-  Tor will give a "552" error if any requested feature is not recognized.
-
-  Feature names are case-insensitive.
-
-  EXTENDED_EVENTS
-
-     Same as passing 'EXTENDED' to SETEVENTS; this is the preferred way to
-     request the extended event syntax.
-
-     This will not be always-enabled until at least two stable releases
-     after 0.1.2.3-alpha, the release where it was first used for
-     anything.
-
-  VERBOSE_NAMES
-
-     Instead of ServerID as specified above, the controller should
-     identify ORs by LongName in events and GETINFO results.  This format is
-     strictly more informative: rather than including Nickname for
-     known Named routers and Fingerprint for unknown or unNamed routers, the
-     LongName format includes a Fingerprint, an indication of Named status,
-     and a Nickname (if one is known).
-
-     This will not be always-enabled until at least two stable releases
-     after 0.1.2.2-alpha, the release where it was first available.
-
-3.20. RESOLVE
-
-  The syntax is
-    "RESOLVE" *Option *Address CRLF
-    Option = "mode=reverse"
-    Address = a hostname or IPv4 address
-
-  This command launches a remote hostname lookup request for every specified
-  request (or reverse lookup if "mode=reverse" is specified).  Note that the
-  request is done in the background: to see the answers, your controller will
-  need to listen for ADDRMAP events; see 4.1.7 below.
-
-  [Added in Tor 0.2.0.3-alpha]
-
-3.21. PROTOCOLINFO
-
-  The syntax is:
-    "PROTOCOLINFO" *(SP PIVERSION) CRLF
-
-  The server reply format is:
-    "250-PROTOCOLINFO" SP PIVERSION CRLF *InfoLine "250 OK" CRLF
-
-    InfoLine = AuthLine / VersionLine / OtherLine
-
-     AuthLine = "250-AUTH" SP "METHODS=" AuthMethod *(",")AuthMethod
-                       *(SP "COOKIEFILE=" AuthCookieFile) CRLF
-     VersionLine = "250-VERSION" SP "Tor=" TorVersion [SP Arguments] CRLF
-
-     AuthMethod =
-      "NULL"           / ; No authentication is required
-      "HASHEDPASSWORD" / ; A controller must supply the original password
-      "COOKIE"         / ; A controller must supply the contents of a cookie
-
-     AuthCookieFile = QuotedString
-     TorVersion = QuotedString
-
-     OtherLine = "250-" Keyword [SP Arguments] CRLF
-
-    PIVERSION: 1*DIGIT
-
-  Tor MAY give its InfoLines in any order; controllers MUST ignore InfoLines
-  with keywords they do not recognize.  Controllers MUST ignore extraneous
-  data on any InfoLine.
-
-  PIVERSION is there in case we drastically change the syntax one day. For
-  now it should always be "1".  Controllers MAY provide a list of the
-  protocolinfo versions they support; Tor MAY select a version that the
-  controller does not support.
-
-  AuthMethod is used to specify one or more control authentication
-  methods that Tor currently accepts.
-
-  AuthCookieFile specifies the absolute path and filename of the
-  authentication cookie that Tor is expecting and is provided iff
-  the METHODS field contains the method "COOKIE".  Controllers MUST handle
-  escape sequences inside this string.
-
-  The VERSION line contains the Tor version.
-
-  [Unlike other commands besides AUTHENTICATE, PROTOCOLINFO may be used (but
-  only once!) before AUTHENTICATE.]
-
-  [PROTOCOLINFO was not supported before Tor 0.2.0.5-alpha.]
-
-4. Replies
-
-  Reply codes follow the same 3-character format as used by SMTP, with the
-  first character defining a status, the second character defining a
-  subsystem, and the third designating fine-grained information.
-
-  The TC protocol currently uses the following first characters:
-
-    2yz   Positive Completion Reply
-       The command was successful; a new request can be started.
-
-    4yz   Temporary Negative Completion reply
-       The command was unsuccessful but might be reattempted later.
-
-    5yz   Permanent Negative Completion Reply
-       The command was unsuccessful; the client should not try exactly
-       that sequence of commands again.
-
-    6yz   Asynchronous Reply
-       Sent out-of-order in response to an earlier SETEVENTS command.
-
-  The following second characters are used:
-
-    x0z   Syntax
-       Sent in response to ill-formed or nonsensical commands.
-
-    x1z   Protocol
-       Refers to operations of the Tor Control protocol.
-
-    x5z   Tor
-       Refers to actual operations of Tor system.
-
-  The following codes are defined:
-
-     250 OK
-     251 Operation was unnecessary
-         [Tor has declined to perform the operation, but no harm was done.]
-
-     451 Resource exhausted
-
-     500 Syntax error: protocol
-
-     510 Unrecognized command
-     511 Unimplemented command
-     512 Syntax error in command argument
-     513 Unrecognized command argument
-     514 Authentication required
-     515 Bad authentication
-
-     550 Unspecified Tor error
-
-     551 Internal error
-               [Something went wrong inside Tor, so that the client's
-                request couldn't be fulfilled.]
-
-     552 Unrecognized entity
-               [A configuration key, a stream ID, circuit ID, event,
-                mentioned in the command did not actually exist.]
-
-     553 Invalid configuration value
-         [The client tried to set a configuration option to an
-           incorrect, ill-formed, or impossible value.]
-
-     554 Invalid descriptor
-
-     555 Unmanaged entity
-
-     650 Asynchronous event notification
-
-  Unless specified to have specific contents, the human-readable messages
-  in error replies should not be relied upon to match those in this document.
-
-4.1. Asynchronous events
-
-  These replies can be sent after a corresponding SETEVENTS command has been
-  received.  They will not be interleaved with other Reply elements, but they
-  can appear between a command and its corresponding reply.  For example,
-  this sequence is possible:
-
-     C: SETEVENTS CIRC
-     S: 250 OK
-     C: GETCONF SOCKSPORT ORPORT
-     S: 650 CIRC 1000 EXTENDED moria1,moria2
-     S: 250-SOCKSPORT=9050
-     S: 250 ORPORT=0
-
-  But this sequence is disallowed:
-     C: SETEVENTS CIRC
-     S: 250 OK
-     C: GETCONF SOCKSPORT ORPORT
-     S: 250-SOCKSPORT=9050
-     S: 650 CIRC 1000 EXTENDED moria1,moria2
-     S: 250 ORPORT=0
-
-  Clients MUST tolerate more arguments in an asynchonous reply than
-  expected, and MUST tolerate more lines in an asynchronous reply than
-  expected.  For instance, a client that expects a CIRC message like:
-      650 CIRC 1000 EXTENDED moria1,moria2
-  must tolerate:
-      650-CIRC 1000 EXTENDED moria1,moria2 0xBEEF
-      650-EXTRAMAGIC=99
-      650 ANONYMITY=high
-
-  If clients ask for extended events, then each event line as specified below
-  will be followed by additional extensions. Additional lines will be of the
-  form
-      "650" ("-"/" ") KEYWORD ["=" ARGUMENTS] CRLF
-  Additional arguments will be of the form
-      SP KEYWORD ["=" ( QuotedString / * NonSpDquote ) ]
-  Such clients MUST tolerate lines with keywords they do not recognize.
-
-4.1.1. Circuit status changed
-
-   The syntax is:
-
-     "650" SP "CIRC" SP CircuitID SP CircStatus [SP Path]
-          [SP "REASON=" Reason [SP "REMOTE_REASON=" Reason]] CRLF
-
-      CircStatus =
-               "LAUNCHED" / ; circuit ID assigned to new circuit
-               "BUILT"    / ; all hops finished, can now accept streams
-               "EXTENDED" / ; one more hop has been completed
-               "FAILED"   / ; circuit closed (was not built)
-               "CLOSED"     ; circuit closed (was built)
-
-      Path = ServerID *("," ServerID)
-
-      Reason = "NONE" / "TORPROTOCOL" / "INTERNAL" / "REQUESTED" /
-               "HIBERNATING" / "RESOURCELIMIT" / "CONNECTFAILED" /
-               "OR_IDENTITY" / "OR_CONN_CLOSED" / "TIMEOUT" /
-               "FINISHED" / "DESTROYED" / "NOPATH" / "NOSUCHSERVICE"
-
-   The path is provided only when the circuit has been extended at least one
-   hop.
-
-   The "REASON" field is provided only for FAILED and CLOSED events, and only
-   if extended events are enabled (see 3.19).  Clients MUST accept reasons
-   not listed above.  Reasons are as given in tor-spec.txt, except for:
-
-      NOPATH          (Not enough nodes to make circuit)
-
-   The "REMOTE_REASON" field is provided only when we receive a DESTROY or
-   TRUNCATE cell, and only if extended events are enabled.  It contains the
-   actual reason given by the remote OR for closing the circuit. Clients MUST
-   accept reasons not listed above.  Reasons are as listed in tor-spec.txt.
-
-4.1.2. Stream status changed
-
-    The syntax is:
-
-      "650" SP "STREAM" SP StreamID SP StreamStatus SP CircID SP Target
-          [SP "REASON=" Reason [ SP "REMOTE_REASON=" Reason ]]
-          [SP "SOURCE=" Source] [ SP "SOURCE_ADDR=" Address ":" Port ]
-          [SP "PURPOSE=" Purpose]
-          CRLF
-
-      StreamStatus =
-               "NEW"          / ; New request to connect
-               "NEWRESOLVE"   / ; New request to resolve an address
-               "REMAP"        / ; Address re-mapped to another
-               "SENTCONNECT"  / ; Sent a connect cell along a circuit
-               "SENTRESOLVE"  / ; Sent a resolve cell along a circuit
-               "SUCCEEDED"    / ; Received a reply; stream established
-               "FAILED"       / ; Stream failed and not retriable
-               "CLOSED"       / ; Stream closed
-               "DETACHED"       ; Detached from circuit; still retriable
-
-       Target = Address ":" Port
-
-  The circuit ID designates which circuit this stream is attached to.  If
-  the stream is unattached, the circuit ID "0" is given.
-
-      Reason = "MISC" / "RESOLVEFAILED" / "CONNECTREFUSED" /
-               "EXITPOLICY" / "DESTROY" / "DONE" / "TIMEOUT" /
-               "HIBERNATING" / "INTERNAL"/ "RESOURCELIMIT" /
-               "CONNRESET" / "TORPROTOCOL" / "NOTDIRECTORY" / "END"
-
-   The "REASON" field is provided only for FAILED, CLOSED, and DETACHED
-   events, and only if extended events are enabled (see 3.19).  Clients MUST
-   accept reasons not listed above.  Reasons are as given in tor-spec.txt,
-   except for:
-
-      END          (We received a RELAY_END cell from the other side of this
-                    stream.)
-      [XXXX document more. -NM]
-
-   The "REMOTE_REASON" field is provided only when we receive a RELAY_END
-   cell, and only if extended events are enabled.  It contains the actual
-   reason given by the remote OR for closing the stream. Clients MUST accept
-   reasons not listed above.  Reasons are as listed in tor-spec.txt.
-
-   "REMAP" events include a Source if extended events are enabled:
-      Source = "CACHE" / "EXIT"
-   Clients MUST accept sources not listed above.  "CACHE" is given if
-   the Tor client decided to remap the address because of a cached
-   answer, and "EXIT" is given if the remote node we queried gave us
-   the new address as a response.
-
-   The "SOURCE_ADDR" field is included with NEW and NEWRESOLVE events if
-   extended events are enabled.  It indicates the address and port
-   that requested the connection, and can be (e.g.) used to look up the
-   requesting program.
-
-      Purpose = "DIR_FETCH" / "UPLOAD_DESC" / "DNS_REQUEST" /
-                 "USER" /  "DIRPORT_TEST"
-
-   The "PURPOSE" field is provided only for NEW and NEWRESOLVE events, and
-   only if extended events are enabled (see 3.19).  Clients MUST accept
-   purposes not listed above.
-
-4.1.3. OR Connection status changed
-
-  The syntax is:
-    "650" SP "ORCONN" SP (ServerID / Target) SP ORStatus [ SP "REASON="
-             Reason ] [ SP "NCIRCS=" NumCircuits ] CRLF
-
-    ORStatus = "NEW" / "LAUNCHED" / "CONNECTED" / "FAILED" / "CLOSED"
-
-  NEW is for incoming connections, and LAUNCHED is for outgoing
-  connections. CONNECTED means the TLS handshake has finished (in
-  either direction). FAILED means a connection is being closed that
-  hasn't finished its handshake, and CLOSED is for connections that
-  have handshaked.
-
-  A ServerID is specified unless it's a NEW connection, in which
-  case we don't know what server it is yet, so we use Address:Port.
-
-  If extended events are enabled (see 3.19), optional reason and
-  circuit counting information is provided for CLOSED and FAILED
-  events.
-
-      Reason = "MISC" / "DONE" / "CONNECTREFUSED" /
-               "IDENTITY" / "CONNECTRESET" / "TIMEOUT" / "NOROUTE" /
-               "IOERROR" / "RESOURCELIMIT"
-
-  NumCircuits counts both established and pending circuits.
-
-4.1.4. Bandwidth used in the last second
-
-  The syntax is:
-     "650" SP "BW" SP BytesRead SP BytesWritten *(SP Type "=" Num) CRLF
-     BytesRead = 1*DIGIT
-     BytesWritten = 1*DIGIT
-     Type = "DIR" / "OR" / "EXIT" / "APP" / ...
-     Num = 1*DIGIT
-
-  BytesRead and BytesWritten are the totals. [In a future Tor version,
-  we may also include a breakdown of the connection types that used
-  bandwidth this second (not implemented yet).]
-
-4.1.5. Log messages
-
-  The syntax is:
-     "650" SP Severity SP ReplyText CRLF
-  or
-     "650+" Severity CRLF Data 650 SP "OK" CRLF
-
-     Severity = "DEBUG" / "INFO" / "NOTICE" / "WARN"/ "ERR"
-
-4.1.6. New descriptors available
-
-  Syntax:
-     "650" SP "NEWDESC" 1*(SP ServerID) CRLF
-
-4.1.7. New Address mapping
-
-  Syntax:
-     "650" SP "ADDRMAP" SP Address SP NewAddress SP Expiry
-       [SP Error] SP GMTExpiry CRLF
-
-     NewAddress = Address / "<error>"
-     Expiry = DQUOTE ISOTime DQUOTE / "NEVER"
-
-     Error = "error=" ErrorCode
-     ErrorCode = XXXX
-     GMTExpiry = "EXPIRES=" DQUOTE IsoTime DQUOTE
-
-  Error and GMTExpiry are only provided if extended events are enabled.
-
-  Expiry is expressed as the local time (rather than GMT).  This is a bug,
-  left in for backward compatibility; new code should look at GMTExpiry
-  instead.
-
-  These events are generated when a new address mapping is entered in the
-  cache, or when the answer for a RESOLVE command is found.
-
-4.1.8. Descriptors uploaded to us in our role as authoritative dirserver
-
-  Syntax:
-     "650" "+" "AUTHDIR_NEWDESCS" CRLF Action CRLF Message CRLF
-       Descriptor CRLF "." CRLF "650" SP "OK" CRLF
-     Action = "ACCEPTED" / "DROPPED" / "REJECTED"
-     Message = Text
-
-4.1.9. Our descriptor changed
-
-  Syntax:
-     "650" SP "DESCCHANGED" CRLF
-
-  [First added in 0.1.2.2-alpha.]
-
-4.1.10. Status events
-
-  Status events (STATUS_GENERAL, STATUS_CLIENT, and STATUS_SERVER) are sent
-  based on occurrences in the Tor process pertaining to the general state of
-  the program.  Generally, they correspond to log messages of severity Notice
-  or higher.  They differ from log messages in that their format is a
-  specified interface.
-
-  Syntax:
-     "650" SP StatusType SP StatusSeverity SP StatusAction
-                                         [SP StatusArguments] CRLF
-
-     StatusType = "STATUS_GENERAL" / "STATUS_CLIENT" / "STATUS_SERVER"
-     StatusSeverity = "NOTICE" / "WARN" / "ERR"
-     StatusAction = 1*ALPHA
-     StatusArguments = StatusArgument *(SP StatusArgument)
-     StatusArgument = StatusKeyword '=' StatusValue
-     StatusKeyword = 1*(ALNUM / "_")
-     StatusValue = 1*(ALNUM / '_')  / QuotedString
-
-     Action is a string, and Arguments is a series of keyword=value
-     pairs on the same line.  Values may be space-terminated strings,
-     or quoted strings.
-
-     These events are always produced with EXTENDED_EVENTS and
-     VERBOSE_NAMES; see the explanations in the USEFEATURE section
-     for details.
-
-     Controllers MUST tolerate unrecognized actions, MUST tolerate
-     unrecognized arguments, MUST tolerate missing arguments, and MUST
-     tolerate arguments that arrive in any order.
-
-     Each event description below is accompanied by a recommendation for
-     controllers.  These recommendations are suggestions only; no controller
-     is required to implement them.
-
-  Compatibility note: versions of Tor before 0.2.0.22-rc incorrectly
-  generated "STATUS_SERVER" as "STATUS_SEVER".  To be compatible with those
-  versions, tools should accept both.
-
-  Actions for STATUS_GENERAL events can be as follows:
-
-     CLOCK_JUMPED
-     "TIME=NUM"
-       Tor spent enough time without CPU cycles that it has closed all
-       its circuits and will establish them anew. This typically
-       happens when a laptop goes to sleep and then wakes up again. It
-       also happens when the system is swapping so heavily that Tor is
-       starving. The "time" argument specifies the number of seconds Tor
-       thinks it was unconscious for (or alternatively, the number of
-       seconds it went back in time).
-
-       This status event is sent as NOTICE severity normally, but WARN
-       severity if Tor is acting as a server currently.
-
-       {Recommendation for controller: ignore it, since we don't really
-       know what the user should do anyway. Hm.}
-
-     DANGEROUS_VERSION
-     "CURRENT=version"
-     "REASON=NEW/OBSOLETE/UNRECOMMENDED"
-     "RECOMMENDED=\"version, version, ...\""
-       Tor has found that directory servers don't recommend its version of
-       the Tor software.  RECOMMENDED is a comma-and-space-separated string
-       of Tor versions that are recommended.  REASON is NEW if this version
-       of Tor is newer than any recommended version, OBSOLETE if
-       this version of Tor is older than any recommended version, and
-       UNRECOMMENDED if some recommended versions of Tor are newer and
-       some are older than this version. (The "OBSOLETE" reason was called
-       "OLD" from Tor 0.1.2.3-alpha up to and including 0.2.0.12-alpha.)
-
-       {Controllers may want to suggest that the user upgrade OLD or
-       UNRECOMMENDED versions.  NEW versions may be known-insecure, or may
-       simply be development versions.}
-
-     TOO_MANY_CONNECTIONS
-     "CURRENT=NUM"
-       Tor has reached its ulimit -n or whatever the native limit is on file
-       descriptors or sockets.  CURRENT is the number of sockets Tor
-       currently has open.  The user should really do something about
-       this. The "current" argument shows the number of connections currently
-       open.
-
-       {Controllers may recommend that the user increase the limit, or
-       increase it for them.  Recommendations should be phrased in an
-       OS-appropriate way and automated when possible.}
-
-     BUG
-     "REASON=STRING"
-       Tor has encountered a situation that its developers never expected,
-       and the developers would like to learn that it happened. Perhaps
-       the controller can explain this to the user and encourage her to
-       file a bug report?
-
-       {Controllers should log bugs, but shouldn't annoy the user in case a
-       bug appears frequently.}
-
-     CLOCK_SKEW
-       SKEW="+" / "-" SECONDS
-       MIN_SKEW="+" / "-" SECONDS.
-       SOURCE="DIRSERV:" IP ":" Port /
-              "NETWORKSTATUS:" IP ":" Port /
-              "OR:" IP ":" Port /
-              "CONSENSUS"
-         If "SKEW" is present, it's an estimate of how far we are from the
-         time declared in the source.  (In other words, if we're an hour in
-         the past, the value is -3600.)  "MIN_SKEW" is present, it's a lower
-         bound.  If the source is a DIRSERV, we got the current time from a
-         connection to a dirserver.  If the source is a NETWORKSTATUS, we
-         decided we're skewed because we got a v2 networkstatus from far in
-         the future.  If the source is OR, the skew comes from a NETINFO
-         cell from a connection to another relay.  If the source is
-         CONSENSUS, we decided we're skewed because we got a networkstatus
-         consensus from the future.
-
-         {Tor should send this message to controllers when it thinks the
-         skew is so high that it will interfere with proper Tor operation.
-         Controllers shouldn't blindly adjust the clock, since the more
-         accurate source of skew info (DIRSERV) is currently
-         unauthenticated.}
-
-     BAD_LIBEVENT
-     "METHOD=" libevent method
-     "VERSION=" libevent version
-     "BADNESS=" "BROKEN" / "BUGGY" / "SLOW"
-     "RECOVERED=" "NO" / "YES"
-        Tor knows about bugs in using the configured event method in this
-        version of libevent.  "BROKEN" libevents won't work at all;
-        "BUGGY" libevents might work okay; "SLOW" libevents will work
-        fine, but not quickly.  If "RECOVERED" is YES, Tor managed to
-        switch to a more reliable (but probably slower!) libevent method.
-
-        {Controllers may want to warn the user if this event occurs, though
-        generally it's the fault of whoever built the Tor binary and there's
-        not much the user can do besides upgrade libevent or upgrade the
-        binary.}
-
-     DIR_ALL_UNREACHABLE
-       Tor believes that none of the known directory servers are
-       reachable -- this is most likely because the local network is
-       down or otherwise not working, and might help to explain for the
-       user why Tor appears to be broken.
-
-       {Controllers may want to warn the user if this event occurs; further
-       action is generally not possible.}
-
-     CONSENSUS_ARRIVED
-        Tor has received and validated a new consensus networkstatus.
-        (This event can be delayed a little while after the consensus
-        is received, if Tor needs to fetch certificates.)
-
-  Actions for STATUS_CLIENT events can be as follows:
-
-     BOOTSTRAP
-     "PROGRESS=" num
-     "TAG=" Keyword
-     "SUMMARY=" String
-     ["WARNING=" String
-      "REASON=" Keyword
-      "COUNT=" num
-      "RECOMMENDATION=" Keyword
-     ]
-
-       Tor has made some progress at establishing a connection to the
-       Tor network, fetching directory information, or making its first
-       circuit; or it has encountered a problem while bootstrapping. This
-       status event is especially useful for users with slow connections
-       or with connectivity problems.
-
-       "Progress" gives a number between 0 and 100 for how far through
-       the bootstrapping process we are. "Summary" is a string that can
-       be displayed to the user to describe the *next* task that Tor
-       will tackle, i.e., the task it is working on after sending the
-       status event. "Tag" is a string that controllers can use to
-       recognize bootstrap phases, if they want to do something smarter
-       than just blindly displaying the summary string; see Section 5
-       for the current tags that Tor issues.
-
-       The StatusSeverity describes whether this is a normal bootstrap
-       phase (severity notice) or an indication of a bootstrapping
-       problem (severity warn).
-
-       For bootstrap problems, we include the same progress, tag, and
-       summary values as we would for a normal bootstrap event, but we
-       also include "warning", "reason", "count", and "recommendation"
-       key/value combos. The "count" number tells how many bootstrap
-       problems there have been so far at this phase. The "reason"
-       string lists one of the reasons allowed in the ORCONN event. The
-       "warning" argument string with any hints Tor has to offer about
-       why it's having troubles bootstrapping.
-
-       The "reason" values are long-term-stable controller-facing tags to
-       identify particular issues in a bootstrapping step.  The warning
-       strings, on the other hand, are human-readable. Controllers
-       SHOULD NOT rely on the format of any warning string. Currently
-       the possible values for "recommendation" are either "ignore" or
-       "warn" -- if ignore, the controller can accumulate the string in
-       a pile of problems to show the user if the user asks; if warn,
-       the controller should alert the user that Tor is pretty sure
-       there's a bootstrapping problem.
-
-       Currently Tor uses recommendation=ignore for the first
-       nine bootstrap problem reports for a given phase, and then
-       uses recommendation=warn for subsequent problems at that
-       phase. Hopefully this is a good balance between tolerating
-       occasional errors and reporting serious problems quickly.
-
-     ENOUGH_DIR_INFO
-       Tor now knows enough network-status documents and enough server
-       descriptors that it's going to start trying to build circuits now.
-
-       {Controllers may want to use this event to decide when to indicate
-       progress to their users, but should not interrupt the user's browsing
-       to tell them so.}
-
-     NOT_ENOUGH_DIR_INFO
-       We discarded expired statuses and router descriptors to fall
-       below the desired threshold of directory information. We won't
-       try to build any circuits until ENOUGH_DIR_INFO occurs again.
-
-       {Controllers may want to use this event to decide when to indicate
-       progress to their users, but should not interrupt the user's browsing
-       to tell them so.}
-
-     CIRCUIT_ESTABLISHED
-       Tor is able to establish circuits for client use. This event will
-       only be sent if we just built a circuit that changed our mind --
-       that is, prior to this event we didn't know whether we could
-       establish circuits.
-
-       {Suggested use: controllers can notify their users that Tor is
-       ready for use as a client once they see this status event. [Perhaps
-       controllers should also have a timeout if too much time passes and
-       this event hasn't arrived, to give tips on how to troubleshoot.
-       On the other hand, hopefully Tor will send further status events
-       if it can identify the problem.]}
-
-     CIRCUIT_NOT_ESTABLISHED
-     "REASON=" "EXTERNAL_ADDRESS" / "DIR_ALL_UNREACHABLE" / "CLOCK_JUMPED"
-       We are no longer confident that we can build circuits. The "reason"
-       keyword provides an explanation: which other status event type caused
-       our lack of confidence.
-
-       {Controllers may want to use this event to decide when to indicate
-       progress to their users, but should not interrupt the user's browsing
-       to do so.}
-       [Note: only REASON=CLOCK_JUMPED is implemented currently.]
-
-     DANGEROUS_PORT
-     "PORT=" port
-     "RESULT=" "REJECT" / "WARN"
-       A stream was initiated to a port that's commonly used for
-       vulnerable-plaintext protocols. If the Result is "reject", we
-       refused the connection; whereas if it's "warn", we allowed it.
-
-       {Controllers should warn their users when this occurs, unless they
-       happen to know that the application using Tor is in fact doing so
-       correctly (e.g., because it is part of a distributed bundle). They
-       might also want some sort of interface to let the user configure
-       their RejectPlaintextPorts and WarnPlaintextPorts config options.}
-
-     DANGEROUS_SOCKS
-     "PROTOCOL=" "SOCKS4" / "SOCKS5"
-     "ADDRESS=" IP:port
-       A connection was made to Tor's SOCKS port using one of the SOCKS
-       approaches that doesn't support hostnames -- only raw IP addresses.
-       If the client application got this address from gethostbyname(),
-       it may be leaking target addresses via DNS.
-
-       {Controllers should warn their users when this occurs, unless they
-       happen to know that the application using Tor is in fact doing so
-       correctly (e.g., because it is part of a distributed bundle).}
-
-     SOCKS_UNKNOWN_PROTOCOL
-       "DATA=string"
-       A connection was made to Tor's SOCKS port that tried to use it
-       for something other than the SOCKS protocol. Perhaps the user is
-       using Tor as an HTTP proxy?   The DATA is the first few characters
-       sent to Tor on the SOCKS port.
-
-       {Controllers may want to warn their users when this occurs: it
-       indicates a misconfigured application.}
-
-     SOCKS_BAD_HOSTNAME
-      "HOSTNAME=QuotedString"
-       Some application gave us a funny-looking hostname. Perhaps
-       it is broken? In any case it won't work with Tor and the user
-       should know.
-
-       {Controllers may want to warn their users when this occurs: it
-       usually indicates a misconfigured application.}
-
-  Actions for STATUS_SERVER can be as follows:
-
-     EXTERNAL_ADDRESS
-     "ADDRESS=IP"
-     "HOSTNAME=NAME"
-     "METHOD=CONFIGURED/DIRSERV/RESOLVED/INTERFACE/GETHOSTNAME"
-       Our best idea for our externally visible IP has changed to 'IP'.
-       If 'HOSTNAME' is present, we got the new IP by resolving 'NAME'.  If the
-       method is 'CONFIGURED', the IP was given verbatim as a configuration
-       option.  If the method is 'RESOLVED', we resolved the Address
-       configuration option to get the IP.  If the method is 'GETHOSTNAME',
-       we resolved our hostname to get the IP.  If the method is 'INTERFACE',
-       we got the address of one of our network interfaces to get the IP.  If
-       the method is 'DIRSERV', a directory server told us a guess for what
-       our IP might be.
-
-       {Controllers may want to record this info and display it to the user.}
-
-     CHECKING_REACHABILITY
-     "ORADDRESS=IP:port"
-     "DIRADDRESS=IP:port"
-       We're going to start testing the reachability of our external OR port
-       or directory port.
-
-       {This event could affect the controller's idea of server status, but
-       the controller should not interrupt the user to tell them so.}
-
-     REACHABILITY_SUCCEEDED
-     "ORADDRESS=IP:port"
-     "DIRADDRESS=IP:port"
-       We successfully verified the reachability of our external OR port or
-       directory port (depending on which of ORADDRESS or DIRADDRESS is
-       given.)
-
-       {This event could affect the controller's idea of server status, but
-       the controller should not interrupt the user to tell them so.}
-
-     GOOD_SERVER_DESCRIPTOR
-       We successfully uploaded our server descriptor to at least one
-       of the directory authorities, with no complaints.
-
-       {Originally, the goal of this event was to declare "every authority
-       has accepted the descriptor, so there will be no complaints
-       about it." But since some authorities might be offline, it's
-       harder to get certainty than we had thought. As such, this event
-       is equivalent to ACCEPTED_SERVER_DESCRIPTOR below. Controllers
-       should just look at ACCEPTED_SERVER_DESCRIPTOR and should ignore
-       this event for now.}
-
-     NAMESERVER_STATUS
-     "NS=addr"
-     "STATUS=" "UP" / "DOWN"
-     "ERR=" message
-        One of our nameservers has changed status.
-
-        {This event could affect the controller's idea of server status, but
-        the controller should not interrupt the user to tell them so.}
-
-     NAMESERVER_ALL_DOWN
-        All of our nameservers have gone down.
-
-        {This is a problem; if it happens often without the nameservers
-        coming up again, the user needs to configure more or better
-        nameservers.}
-
-     DNS_HIJACKED
-        Our DNS provider is providing an address when it should be saying
-        "NOTFOUND"; Tor will treat the address as a synonym for "NOTFOUND".
-
-        {This is an annoyance; controllers may want to tell admins that their
-        DNS provider is not to be trusted.}
-
-     DNS_USELESS
-        Our DNS provider is giving a hijacked address instead of well-known
-        websites; Tor will not try to be an exit node.
-
-        {Controllers could warn the admin if the server is running as an
-        exit server: the admin needs to configure a good DNS server.
-        Alternatively, this happens a lot in some restrictive environments
-        (hotels, universities, coffeeshops) when the user hasn't registered.}
-
-     BAD_SERVER_DESCRIPTOR
-     "DIRAUTH=addr:port"
-     "REASON=string"
-        A directory authority rejected our descriptor.  Possible reasons
-        include malformed descriptors, incorrect keys, highly skewed clocks,
-        and so on.
-
-        {Controllers should warn the admin, and try to cope if they can.}
-
-     ACCEPTED_SERVER_DESCRIPTOR
-     "DIRAUTH=addr:port"
-        A single directory authority accepted our descriptor.
-        // actually notice
-
-       {This event could affect the controller's idea of server status, but
-       the controller should not interrupt the user to tell them so.}
-
-     REACHABILITY_FAILED
-     "ORADDRESS=IP:port"
-     "DIRADDRESS=IP:port"
-       We failed to connect to our external OR port or directory port
-       successfully.
-
-       {This event could affect the controller's idea of server status.  The
-       controller should warn the admin and suggest reasonable steps to take.}
-
-4.1.11. Our set of guard nodes has changed
-
-  Syntax:
-     "650" SP "GUARD" SP Type SP Name SP Status ... CRLF
-     Type = "ENTRY"
-     Name = The (possibly verbose) nickname of the guard affected.
-     Status = "NEW" | "UP" | "DOWN" | "BAD" | "GOOD" | "DROPPED"
-
-  [explain states. XXX]
-
-4.1.12. Network status has changed
-
-  Syntax:
-     "650" "+" "NS" CRLF 1*NetworkStatus "." CRLF "650" SP "OK" CRLF
-
-  The event is used whenever our local view of a relay status changes.
-  This happens when we get a new v3 consensus (in which case the entries
-  we see are a duplicate of what we see in the NEWCONSENSUS event,
-  below), but it also happens when we decide to mark a relay as up or
-  down in our local status, for example based on connection attempts.
-
-  [First added in 0.1.2.3-alpha]
-
-4.1.13. Bandwidth used on an application stream
-
-  The syntax is:
-     "650" SP "STREAM_BW" SP StreamID SP BytesRead SP BytesWritten CRLF
-     BytesRead = 1*DIGIT
-     BytesWritten = 1*DIGIT
-
-  BytesRead and BytesWritten are the number of bytes read and written since
-  the last STREAM_BW event on this stream.  These events are generated about
-  once per second per stream; no events are generated for streams that have
-  not read or written.
-
-  These events apply only to streams entering Tor (such as on a SOCKSPort,
-  TransPort, or so on).  They are not generated for exiting streams.
-
-4.1.14. Per-country client stats
-
-  The syntax is:
-     "650" SP "CLIENTS_SEEN" SP TimeStarted SP CountrySummary CRLF
-
-  We just generated a new summary of which countries we've seen clients
-  from recently. The controller could display this for the user, e.g.
-  in their "relay" configuration window, to give them a sense that they
-  are actually being useful.
-
-  Currently only bridge relays will receive this event, but once we figure
-  out how to sufficiently aggregate and sanitize the client counts on
-  main relays, we might start sending these events in other cases too.
-
-  TimeStarted is a quoted string indicating when the reported summary
-  counts from (in GMT).
-
-  The CountrySummary keyword has as its argument a comma-separated
-  set of "countrycode=count" pairs. For example,
-  650-CLIENTS_SEEN TimeStarted="Thu Dec 25 23:50:43 EST 2008"
-  650 CountrySummary=us=16,de=8,uk=8
-[XXX Matt Edman informs me that the time format above is wrong. -RD]
-
-4.1.15. New consensus networkstatus has arrived.
-
-  The syntax is:
-     "650" "+" "NEWCONSENSUS" CRLF 1*NetworkStatus "." CRLF "650" SP
-     "OK" CRLF
-
-  A new consensus networkstatus has arrived. We include NS-style lines for
-  every relay in the consensus. NEWCONSENSUS is a separate event from the
-  NS event, because the list here represents every usable relay: so any
-  relay *not* mentioned in this list is implicitly no longer recommended.
-
-  [First added in 0.2.1.13-alpha]
-
-5. Implementation notes
-
-5.1. Authentication
-
-  If the control port is open and no authentication operation is enabled, Tor
-  trusts any local user that connects to the control port.  This is generally
-  a poor idea.
-
-  If the 'CookieAuthentication' option is true, Tor writes a "magic cookie"
-  file named "control_auth_cookie" into its data directory.  To authenticate,
-  the controller must send the contents of this file, encoded in hexadecimal.
-
-  If the 'HashedControlPassword' option is set, it must contain the salted
-  hash of a secret password.  The salted hash is computed according to the
-  S2K algorithm in RFC 2440 (OpenPGP), and prefixed with the s2k specifier.
-  This is then encoded in hexadecimal, prefixed by the indicator sequence
-  "16:".  Thus, for example, the password 'foo' could encode to:
-     16:660537E3E1CD49996044A3BF558097A981F539FEA2F9DA662B4626C1C2
-        ++++++++++++++++**^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-           salt                       hashed value
-                       indicator
-  You can generate the salt of a password by calling
-           'tor --hash-password <password>'
-  or by using the example code in the Python and Java controller libraries.
-  To authenticate under this scheme, the controller sends Tor the original
-  secret that was used to generate the password, either as a quoted string
-  or encoded in hexadecimal.
-
-5.2. Don't let the buffer get too big.
-
-  If you ask for lots of events, and 16MB of them queue up on the buffer,
-  the Tor process will close the socket.
-
-5.3. Backward compatibility with v0 control protocol.
-
-  The 'version 0' control protocol was replaced in Tor 0.1.1.x. Support
-  was removed in Tor 0.2.0.x. Every non-obsolete version of Tor now
-  supports the version 1 control protocol.
-
-  For backward compatibility with the "version 0" control protocol,
-  Tor used to check whether the third octet of the first command is zero.
-  (If it was, Tor assumed that version 0 is in use.)
-
-  This compatibility was removed in Tor 0.1.2.16 and 0.2.0.4-alpha.
-
-5.4. Tor config options for use by controllers
-
-  Tor provides a few special configuration options for use by controllers.
-  These options can be set and examined by the SETCONF and GETCONF commands,
-  but are not saved to disk by SAVECONF.
-
-  Generally, these options make Tor unusable by disabling a portion of Tor's
-  normal operations.  Unless a controller provides replacement functionality
-  to fill this gap, Tor will not correctly handle user requests.
-
-  __AllDirOptionsPrivate
-
-    If true, Tor will try to launch all directory operations through
-    anonymous connections.  (Ordinarily, Tor only tries to anonymize
-    requests related to hidden services.)  This option will slow down
-    directory access, and may stop Tor from working entirely if it does not
-    yet have enough directory information to build circuits.
-
-    (Boolean. Default: "0".)
-
-  __DisablePredictedCircuits
-
-    If true, Tor will not launch preemptive "general-purpose" circuits for
-    streams to attach to.  (It will still launch circuits for testing and
-    for hidden services.)
-
-    (Boolean. Default: "0".)
-
-  __LeaveStreamsUnattached
-
-    If true, Tor will not automatically attach new streams to circuits;
-    instead, the controller must attach them with ATTACHSTREAM.  If the
-    controller does not attach the streams, their data will never be routed.
-
-    (Boolean. Default: "0".)
-
-  __HashedControlSessionPassword
-
-    As HashedControlPassword, but is not saved to the torrc file by
-    SAVECONF.  Added in Tor 0.2.0.20-rc.
-
-  __ReloadTorrcOnSIGHUP
-
-    If this option is true (the default), we reload the torrc from disk
-    every time we get a SIGHUP (from the controller or via a signal).
-    Otherwise, we don't.  This option exists so that controllers can keep
-    their options from getting overwritten when a user sends Tor a HUP for
-    some other reason (for example, to rotate the logs).
-
-    (Boolean.  Default: "1")
-
-5.5. Phases from the Bootstrap status event.
-
-  This section describes the various bootstrap phases currently reported
-  by Tor. Controllers should not assume that the percentages and tags
-  listed here will continue to match up, or even that the tags will stay
-  in the same order. Some phases might also be skipped (not reported)
-  if the associated bootstrap step is already complete, or if the phase
-  no longer is necessary. Only "starting" and "done" are guaranteed to
-  exist in all future versions.
-
-  Current Tor versions enter these phases in order, monotonically.
-  Future Tors MAY revisit earlier stages.
-
-  Phase 0:
-  tag=starting summary="Starting"
-
-  Tor starts out in this phase.
-
-  Phase 5:
-  tag=conn_dir summary="Connecting to directory mirror"
-
-  Tor sends this event as soon as Tor has chosen a directory mirror --
-  e.g. one of the authorities if bootstrapping for the first time or
-  after a long downtime, or one of the relays listed in its cached
-  directory information otherwise.
-
-  Tor will stay at this phase until it has successfully established
-  a TCP connection with some directory mirror. Problems in this phase
-  generally happen because Tor doesn't have a network connection, or
-  because the local firewall is dropping SYN packets.
-
-  Phase 10:
-  tag=handshake_dir summary="Finishing handshake with directory mirror"
-
-  This event occurs when Tor establishes a TCP connection with a relay used
-  as a directory mirror (or its https proxy if it's using one). Tor remains
-  in this phase until the TLS handshake with the relay is finished.
-
-  Problems in this phase generally happen because Tor's firewall is
-  doing more sophisticated MITM attacks on it, or doing packet-level
-  keyword recognition of Tor's handshake.
-
-  Phase 15:
-  tag=onehop_create summary="Establishing one-hop circuit for dir info"
-
-  Once TLS is finished with a relay, Tor will send a CREATE_FAST cell
-  to establish a one-hop circuit for retrieving directory information.
-  It will remain in this phase until it receives the CREATED_FAST cell
-  back, indicating that the circuit is ready.
-
-  Phase 20:
-  tag=requesting_status summary="Asking for networkstatus consensus"
-
-  Once we've finished our one-hop circuit, we will start a new stream
-  for fetching the networkstatus consensus. We'll stay in this phase
-  until we get the 'connected' relay cell back, indicating that we've
-  established a directory connection.
-
-  Phase 25:
-  tag=loading_status summary="Loading networkstatus consensus"
-
-  Once we've established a directory connection, we will start fetching
-  the networkstatus consensus document. This could take a while; this
-  phase is a good opportunity for using the "progress" keyword to indicate
-  partial progress.
-
-  This phase could stall if the directory mirror we picked doesn't
-  have a copy of the networkstatus consensus so we have to ask another,
-  or it does give us a copy but we don't find it valid.
-
-  Phase 40:
-  tag=loading_keys summary="Loading authority key certs"
-
-  Sometimes when we've finished loading the networkstatus consensus,
-  we find that we don't have all the authority key certificates for the
-  keys that signed the consensus. At that point we put the consensus we
-  fetched on hold and fetch the keys so we can verify the signatures.
-
-  Phase 45
-  tag=requesting_descriptors summary="Asking for relay descriptors"
-
-  Once we have a valid networkstatus consensus and we've checked all
-  its signatures, we start asking for relay descriptors. We stay in this
-  phase until we have received a 'connected' relay cell in response to
-  a request for descriptors.
-
-  Phase 50:
-  tag=loading_descriptors summary="Loading relay descriptors"
-
-  We will ask for relay descriptors from several different locations,
-  so this step will probably make up the bulk of the bootstrapping,
-  especially for users with slow connections. We stay in this phase until
-  we have descriptors for at least 1/4 of the usable relays listed in
-  the networkstatus consensus. This phase is also a good opportunity to
-  use the "progress" keyword to indicate partial steps.
-
-  Phase 80:
-  tag=conn_or summary="Connecting to entry guard"
-
-  Once we have a valid consensus and enough relay descriptors, we choose
-  some entry guards and start trying to build some circuits. This step
-  is similar to the "conn_dir" phase above; the only difference is
-  the context.
-
-  If a Tor starts with enough recent cached directory information,
-  its first bootstrap status event will be for the conn_or phase.
-
-  Phase 85:
-  tag=handshake_or summary="Finishing handshake with entry guard"
-
-  This phase is similar to the "handshake_dir" phase, but it gets reached
-  if we finish a TCP connection to a Tor relay and we have already reached
-  the "conn_or" phase. We'll stay in this phase until we complete a TLS
-  handshake with a Tor relay.
-
-  Phase 90:
-  tag=circuit_create summary="Establishing circuits"
-
-  Once we've finished our TLS handshake with an entry guard, we will
-  set about trying to make some 3-hop circuits in case we need them soon.
-
-  Phase 100:
-  tag=done summary="Done"
-
-  A full 3-hop exit circuit has been established. Tor is ready to handle
-  application connections now.
-
diff --git a/doc/spec/dir-spec-v1.txt b/doc/spec/dir-spec-v1.txt
deleted file mode 100644
index 286df66..0000000
--- a/doc/spec/dir-spec-v1.txt
+++ /dev/null
@@ -1,315 +0,0 @@
-$Id$
-
-                         Tor Protocol Specification
-
-                              Roger Dingledine
-                               Nick Mathewson
-
-0. Preliminaries
-
-  THIS SPECIFICATION IS OBSOLETE.
-
-  This document specifies the Tor directory protocol as used in version
-  0.1.0.x and earlier.  See dir-spec.txt for a current version.
-
-1. Basic operation
-
-  There is a small number of directory authorities, and a larger number of
-  caches.  Client and servers know public keys for the directory authorities.
-  Tor servers periodically upload self-signed "router descriptors" to the
-  directory authorities.  Each authority publishes a self-signed "directory"
-  (containing all the router descriptors it knows, and a statement on which
-  are running) and a self-signed "running routers" document containing only
-  the statement on which routers are running.
-
-  All Tors periodically download these documents, downloading the directory
-  less frequently than they do the "running routers" document.  Clients
-  preferentially download from caches rather than authorities.
-
-1.1. Document format
-
-  Router descriptors, directories, and running-routers documents all obey the
-  following lightweight extensible information format.
-
-  The highest level object is a Document, which consists of one or more
-  Items.  Every Item begins with a KeywordLine, followed by one or more
-  Objects. A KeywordLine begins with a Keyword, optionally followed by
-  whitespace and more non-newline characters, and ends with a newline.  A
-  Keyword is a sequence of one or more characters in the set [A-Za-z0-9-].
-  An Object is a block of encoded data in pseudo-Open-PGP-style
-  armor. (cf. RFC 2440)
-
-  More formally:
-
-    Document ::= (Item | NL)+
-    Item ::= KeywordLine Object*
-    KeywordLine ::= Keyword NL | Keyword WS ArgumentsChar+ NL
-    Keyword = KeywordChar+
-    KeywordChar ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9' | '-'
-    ArgumentChar ::= any printing ASCII character except NL.
-    WS = (SP | TAB)+
-    Object ::= BeginLine Base-64-encoded-data EndLine
-    BeginLine ::= "-----BEGIN " Keyword "-----" NL
-    EndLine ::= "-----END " Keyword "-----" NL
-
-    The BeginLine and EndLine of an Object must use the same keyword.
-
-  When interpreting a Document, software MUST reject any document containing a
-  KeywordLine that starts with a keyword it doesn't recognize.
-
-  The "opt" keyword is reserved for non-critical future extensions.  All
-  implementations MUST ignore any item of the form "opt keyword ....." when
-  they would not recognize "keyword ....."; and MUST treat "opt keyword ....."
-  as synonymous with "keyword ......" when keyword is recognized.
-
-2. Router descriptor format.
-
-  Every router descriptor MUST start with a "router" Item; MUST end with a
-  "router-signature" Item and an extra NL; and MUST contain exactly one
-  instance of each of the following Items: "published" "onion-key" "link-key"
-  "signing-key" "bandwidth".  Additionally, a router descriptor MAY contain
-  any number of "accept", "reject", "fingerprint", "uptime", and "opt" Items.
-  Other than "router" and "router-signature", the items may appear in any
-  order.
-
-  The items' formats are as follows:
-   "router" nickname address ORPort SocksPort DirPort
-
-      Indicates the beginning of a router descriptor.  "address"
-      must be an IPv4 address in dotted-quad format. The last
-      three numbers indicate the TCP ports at which this OR exposes
-      functionality. ORPort is a port at which this OR accepts TLS
-      connections for the main OR protocol; SocksPort is deprecated and
-      should always be 0; and DirPort is the port at which this OR accepts
-      directory-related HTTP connections.  If any port is not supported,
-      the value 0 is given instead of a port number.
-
-   "bandwidth" bandwidth-avg bandwidth-burst bandwidth-observed
-
-      Estimated bandwidth for this router, in bytes per second.  The
-      "average" bandwidth is the volume per second that the OR is willing
-      to sustain over long periods; the "burst" bandwidth is the volume
-      that the OR is willing to sustain in very short intervals.  The
-      "observed" value is an estimate of the capacity this server can
-      handle.  The server remembers the max bandwidth sustained output
-      over any ten second period in the past day, and another sustained
-      input.  The "observed" value is the lesser of these two numbers.
-
-   "platform" string
-
-      A human-readable string describing the system on which this OR is
-      running.  This MAY include the operating system, and SHOULD include
-      the name and version of the software implementing the Tor protocol.
-
-   "published" YYYY-MM-DD HH:MM:SS
-
-      The time, in GMT, when this descriptor was generated.
-
-   "fingerprint"
-
-      A fingerprint (a HASH_LEN-byte of asn1 encoded public key, encoded
-      in hex, with a single space after every 4 characters) for this router's
-      identity key. A descriptor is considered invalid (and MUST be
-      rejected) if the fingerprint line does not match the public key.
-
-      [We didn't start parsing this line until Tor 0.1.0.6-rc; it should
-       be marked with "opt" until earlier versions of Tor are obsolete.]
-
-   "hibernating" 0|1
-
-      If the value is 1, then the Tor server was hibernating when the
-      descriptor was published, and shouldn't be used to build circuits.
-
-      [We didn't start parsing this line until Tor 0.1.0.6-rc; it should
-       be marked with "opt" until earlier versions of Tor are obsolete.]
-
-   "uptime"
-
-      The number of seconds that this OR process has been running.
-
-   "onion-key" NL a public key in PEM format
-
-      This key is used to encrypt EXTEND cells for this OR.  The key MUST
-      be accepted for at least XXXX hours after any new key is published in
-      a subsequent descriptor.
-
-   "signing-key" NL a public key in PEM format
-
-      The OR's long-term identity key.
-
-   "accept" exitpattern
-   "reject" exitpattern
-
-       These lines, in order, describe the rules that an OR follows when
-       deciding whether to allow a new stream to a given address.  The
-       'exitpattern' syntax is described below.
-
-   "router-signature" NL Signature NL
-
-       The "SIGNATURE" object contains a signature of the PKCS1-padded
-       hash of the entire router descriptor, taken from the beginning of the
-       "router" line, through the newline after the "router-signature" line.
-       The router descriptor is invalid unless the signature is performed
-       with the router's identity key.
-
-   "contact" info NL
-
-       Describes a way to contact the server's administrator, preferably
-       including an email address and a PGP key fingerprint.
-
-   "family" names NL
-
-       'Names' is a whitespace-separated list of server nicknames. If two ORs
-       list one another in their "family" entries, then OPs should treat them
-       as a single OR for the purpose of path selection.
-
-       For example, if node A's descriptor contains "family B", and node B's
-       descriptor contains "family A", then node A and node B should never
-       be used on the same circuit.
-
-   "read-history" YYYY-MM-DD HH:MM:SS (NSEC s) NUM,NUM,NUM,NUM,NUM... NL
-   "write-history" YYYY-MM-DD HH:MM:SS (NSEC s) NUM,NUM,NUM,NUM,NUM... NL
-
-       Declare how much bandwidth the OR has used recently. Usage is divided
-       into intervals of NSEC seconds.  The YYYY-MM-DD HH:MM:SS field defines
-       the end of the most recent interval.  The numbers are the number of
-       bytes used in the most recent intervals, ordered from oldest to newest.
-
-       [We didn't start parsing these lines until Tor 0.1.0.6-rc; they should
-        be marked with "opt" until earlier versions of Tor are obsolete.]
-
-2.1. Nonterminals in routerdescriptors
-
-  nickname ::= between 1 and 19 alphanumeric characters, case-insensitive.
-
-  exitpattern ::= addrspec ":" portspec
-  portspec ::= "*" | port | port "-" port
-  port ::= an integer between 1 and 65535, inclusive.
-  addrspec ::= "*" | ip4spec | ip6spec
-  ipv4spec ::= ip4 | ip4 "/" num_ip4_bits | ip4 "/" ip4mask
-  ip4 ::= an IPv4 address in dotted-quad format
-  ip4mask ::= an IPv4 mask in dotted-quad format
-  num_ip4_bits ::= an integer between 0 and 32
-  ip6spec ::= ip6 | ip6 "/" num_ip6_bits
-  ip6 ::= an IPv6 address, surrounded by square brackets.
-  num_ip6_bits ::= an integer between 0 and 128
-
-  Ports are required; if they are not included in the router
-  line, they must appear in the "ports" lines.
-
-3. Directory format
-
-  A Directory begins with a "signed-directory" item, followed by one each of
-  the following, in any order: "recommended-software", "published",
-  "router-status", "dir-signing-key".  It may include any number of "opt"
-  items.  After these items, a directory includes any number of router
-  descriptors, and a single "directory-signature" item.
-
-    "signed-directory"
-
-        Indicates the start of a directory.
-
-    "published" YYYY-MM-DD HH:MM:SS
-
-        The time at which this directory was generated and signed, in GMT.
-
-    "dir-signing-key"
-
-        The key used to sign this directory; see "signing-key" for format.
-
-    "recommended-software"  comma-separated-version-list
-
-        A list of which versions of which implementations are currently
-        believed to be secure and compatible with the network.
-
-    "running-routers" whitespace-separated-list
-
-        A description of which routers are currently believed to be up or
-        down.  Every entry consists of an optional "!", followed by either an
-        OR's nickname, or "$" followed by a hexadecimal encoding of the hash
-        of an OR's identity key.  If the "!" is included, the router is
-        believed not to be running; otherwise, it is believed to be running.
-        If a router's nickname is given, exactly one router of that nickname
-        will appear in the directory, and that router is "approved" by the
-        directory server.  If a hashed identity key is given, that OR is not
-        "approved".  [XXXX The 'running-routers' line is only provided for
-        backward compatibility.  New code should parse 'router-status'
-        instead.]
-
-    "router-status" whitespace-separated-list
-
-        A description of which routers are currently believed to be up or
-        down, and which are verified or unverified.  Contains one entry for
-        every router that the directory server knows.  Each entry is of the
-        format:
-
-              !name=$digest  [Verified router, currently not live.]
-              name=$digest   [Verified router, currently live.]
-              !$digest       [Unverified router, currently not live.]
-          or  $digest        [Unverified router, currently live.]
-
-        (where 'name' is the router's nickname and 'digest' is a hexadecimal
-        encoding of the hash of the routers' identity key).
-
-        When parsing this line, clients should only mark a router as
-        'verified' if its nickname AND digest match the one provided.
-
-    "directory-signature" nickname-of-dirserver NL Signature
-
-  The signature is computed by computing the digest of the
-  directory, from the characters "signed-directory", through the newline
-  after "directory-signature".  This digest is then padded with PKCS.1,
-  and signed with the directory server's signing key.
-
-  If software encounters an unrecognized keyword in a single router descriptor,
-  it MUST reject only that router descriptor, and continue using the
-  others.  Because this mechanism is used to add 'critical' extensions to
-  future versions of the router descriptor format, implementation should treat
-  it as a normal occurrence and not, for example, report it to the user as an
-  error.  [Versions of Tor prior to 0.1.1 did this.]
-
-  If software encounters an unrecognized keyword in the directory header,
-  it SHOULD reject the entire directory.
-
-4. Network-status descriptor
-
-  A "network-status" (a.k.a "running-routers") document is a truncated
-  directory that contains only the current status of a list of nodes, not
-  their actual descriptors.  It contains exactly one of each of the following
-  entries.
-
-     "network-status"
-
-        Must appear first.
-
-     "published" YYYY-MM-DD HH:MM:SS
-
-        (see section 3 above)
-
-     "router-status" list
-
-        (see section 3 above)
-
-     "directory-signature" NL signature
-
-        (see section 3 above)
-
-5. Behavior of a directory server
-
-  lists nodes that are connected currently
-  speaks HTTP on a socket, spits out directory on request
-
-  Directory servers listen on a certain port (the DirPort), and speak a
-  limited version of HTTP 1.0. Clients send either GET or POST commands.
-  The basic interactions are:
-    "%s %s HTTP/1.0\r\nContent-Length: %lu\r\nHost: %s\r\n\r\n",
-      command, url, content-length, host.
-    Get "/tor/" to fetch a full directory.
-    Get "/tor/dir.z" to fetch a compressed full directory.
-    Get "/tor/running-routers" to fetch a network-status descriptor.
-    Post "/tor/" to post a server descriptor, with the body of the
-      request containing the descriptor.
-
-    "host" is used to specify the address:port of the dirserver, so
-    the request can survive going through HTTP proxies.
-
diff --git a/doc/spec/dir-spec-v2.txt b/doc/spec/dir-spec-v2.txt
deleted file mode 100644
index 4873c4a..0000000
--- a/doc/spec/dir-spec-v2.txt
+++ /dev/null
@@ -1,897 +0,0 @@
-$Id$
-
-                      Tor directory protocol, version 2
-
-0. Scope and preliminaries
-
-   This directory protocol is used by Tor version 0.1.1.x and 0.1.2.x.  See
-   dir-spec-v1.txt for information on earlier versions, and dir-spec.txt
-   for information on later versions.
-
-0.1. Goals and motivation
-
-   There were several problems with the way Tor handles directory information
-   in version 0.1.0.x and earlier.  Here are the problems we try to fix with
-   this new design, already implemented in 0.1.1.x:
-      1. Directories were very large and use up a lot of bandwidth: clients
-         downloaded descriptors for all router several times an hour.
-      2. Every directory authority was a trust bottleneck: if a single
-         directory authority lied, it could make clients believe for a time an
-         arbitrarily distorted view of the Tor network.
-      3. Our current "verified server" system is kind of nonsensical.
-
-      4. Getting more directory authorities would add more points of failure
-         and worsen possible partitioning attacks.
-
-   There are two problems that remain unaddressed by this design.
-      5. Requiring every client to know about every router won't scale.
-      6. Requiring every directory cache to know every router won't scale.
-
-   We attempt to fix 1-4 here, and to build a solution that will work when we
-   figure out an answer for 5.  We haven't thought at all about what to do
-   about 6.
-
-1. Outline
-
-   There is a small set (say, around 10) of semi-trusted directory
-   authorities.  A default list of authorities is shipped with the Tor
-   software. Users can change this list, but are encouraged not to do so, in
-   order to avoid partitioning attacks.
-
-   Routers periodically upload signed "descriptors" to the directory
-   authorities describing their keys, capabilities, and other information.
-   Routers may act as directory mirrors (also called "caches"), to reduce
-   load on the directory authorities.  They announce this in their
-   descriptors.
-
-   Each directory authority periodically generates and signs a compact
-   "network status" document that lists that authority's view of the current
-   descriptors and status for known routers, but which does not include the
-   descriptors themselves.
-
-   Directory mirrors download, cache, and re-serve network-status documents
-   to clients.
-
-   Clients, directory mirrors, and directory authorities all use
-   network-status documents to find out when their list of routers is
-   out-of-date.  If it is, they download any missing router descriptors.
-   Clients download missing descriptors from mirrors; mirrors and authorities
-   download from authorities.  Descriptors are downloaded by the hash of the
-   descriptor, not by the server's identity key: this prevents servers from
-   attacking clients by giving them descriptors nobody else uses.
-
-   All directory information is uploaded and downloaded with HTTP.
-
-   Coordination among directory authorities is done client-side: clients
-   compute a vote-like algorithm among the network-status documents they
-   have, and base their decisions on the result.
-
-1.1. What's different from 0.1.0.x?
-
-   Clients used to download a signed concatenated set of router descriptors
-   (called a "directory") from directory mirrors, regardless of which
-   descriptors had changed.
-
-   Between downloading directories, clients would download "network-status"
-   documents that would list which servers were supposed to running.
-
-   Clients would always believe the most recently published network-status
-   document they were served.
-
-   Routers used to upload fresh descriptors all the time, whether their keys
-   and other information had changed or not.
-
-1.2. Document meta-format
-
-  Router descriptors, directories, and running-routers documents all obey the
-  following lightweight extensible information format.
-
-  The highest level object is a Document, which consists of one or more
-  Items.  Every Item begins with a KeywordLine, followed by one or more
-  Objects. A KeywordLine begins with a Keyword, optionally followed by
-  whitespace and more non-newline characters, and ends with a newline.  A
-  Keyword is a sequence of one or more characters in the set [A-Za-z0-9-].
-  An Object is a block of encoded data in pseudo-Open-PGP-style
-  armor. (cf. RFC 2440)
-
-  More formally:
-
-    Document ::= (Item | NL)+
-    Item ::= KeywordLine Object*
-    KeywordLine ::= Keyword NL | Keyword WS ArgumentsChar+ NL
-    Keyword = KeywordChar+
-    KeywordChar ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9' | '-'
-    ArgumentChar ::= any printing ASCII character except NL.
-    WS = (SP | TAB)+
-    Object ::= BeginLine Base-64-encoded-data EndLine
-    BeginLine ::= "-----BEGIN " Keyword "-----" NL
-    EndLine ::= "-----END " Keyword "-----" NL
-
-    The BeginLine and EndLine of an Object must use the same keyword.
-
-  When interpreting a Document, software MUST ignore any KeywordLine that
-  starts with a keyword it doesn't recognize; future implementations MUST NOT
-  require current clients to understand any KeywordLine not currently
-  described.
-
-  The "opt" keyword was used until Tor 0.1.2.5-alpha for non-critical future
-  extensions.  All implementations MUST ignore any item of the form "opt
-  keyword ....." when they would not recognize "keyword ....."; and MUST
-  treat "opt keyword ....."  as synonymous with "keyword ......" when keyword
-  is recognized.
-
-  Implementations before 0.1.2.5-alpha rejected any document with a
-  KeywordLine that started with a keyword that they didn't recognize.
-  Implementations MUST prefix items not recognized by older versions of Tor
-  with an "opt" until those versions of Tor are obsolete.
-
-  Other implementations that want to extend Tor's directory format MAY
-  introduce their own items.  The keywords for extension items SHOULD start
-  with the characters "x-" or "X-", to guarantee that they will not conflict
-  with keywords used by future versions of Tor.
-
-2. Router operation
-
-   ORs SHOULD generate a new router descriptor whenever any of the
-   following events have occurred:
-
-      - A period of time (18 hrs by default) has passed since the last
-        time a descriptor was generated.
-
-      - A descriptor field other than bandwidth or uptime has changed.
-
-      - Bandwidth has changed by at least a factor of 2 from the last time a
-        descriptor was generated, and at least a given interval of time
-        (20 mins by default) has passed since then.
-
-      - Its uptime has been reset (by restarting).
-
-   After generating a descriptor, ORs upload it to every directory
-   authority they know, by posting it to the URL
-
-      http://<hostname:port>/tor/
-
-2.1. Router descriptor format
-
-   Every router descriptor MUST start with a "router" Item; MUST end with a
-   "router-signature" Item and an extra NL; and MUST contain exactly one
-   instance of each of the following Items: "published" "onion-key"
-   "signing-key" "bandwidth". 
-
-   A router descriptor MAY have zero or one of each of the following Items,
-   but MUST NOT have more than one: "contact", "uptime", "fingerprint",
-   "hibernating", "read-history", "write-history", "eventdns", "platform",
-   "family".
-
-   Additionally, a router descriptor MAY contain any number of "accept",
-   "reject", and "opt" Items.  Other than "router" and "router-signature",
-   the items may appear in any order.
-
-   The items' formats are as follows:
-    "router" nickname address ORPort SocksPort DirPort
-
-       Indicates the beginning of a router descriptor.  "address" must be an
-       IPv4 address in dotted-quad format. The last three numbers indicate
-       the TCP ports at which this OR exposes functionality. ORPort is a port
-       at which this OR accepts TLS connections for the main OR protocol;
-       SocksPort is deprecated and should always be 0; and DirPort is the
-       port at which this OR accepts directory-related HTTP connections.  If
-       any port is not supported, the value 0 is given instead of a port
-       number.
-
-    "bandwidth" bandwidth-avg bandwidth-burst bandwidth-observed
-
-       Estimated bandwidth for this router, in bytes per second.  The
-       "average" bandwidth is the volume per second that the OR is willing to
-       sustain over long periods; the "burst" bandwidth is the volume that
-       the OR is willing to sustain in very short intervals.  The "observed"
-       value is an estimate of the capacity this server can handle.  The
-       server remembers the max bandwidth sustained output over any ten
-       second period in the past day, and another sustained input.  The
-       "observed" value is the lesser of these two numbers.
-
-    "platform" string
-
-       A human-readable string describing the system on which this OR is
-       running.  This MAY include the operating system, and SHOULD include
-       the name and version of the software implementing the Tor protocol.
-
-    "published" YYYY-MM-DD HH:MM:SS
-
-       The time, in GMT, when this descriptor was generated.
-
-    "fingerprint"
-
-       A fingerprint (a HASH_LEN-byte of asn1 encoded public key, encoded in
-       hex, with a single space after every 4 characters) for this router's
-       identity key. A descriptor is considered invalid (and MUST be
-       rejected) if the fingerprint line does not match the public key.
-
-       [We didn't start parsing this line until Tor 0.1.0.6-rc; it should
-        be marked with "opt" until earlier versions of Tor are obsolete.]
-
-    "hibernating" 0|1
-
-       If the value is 1, then the Tor server was hibernating when the
-       descriptor was published, and shouldn't be used to build circuits.
-
-       [We didn't start parsing this line until Tor 0.1.0.6-rc; it should be
-        marked with "opt" until earlier versions of Tor are obsolete.]
-
-    "uptime"
-
-       The number of seconds that this OR process has been running.
-
-    "onion-key" NL a public key in PEM format
-
-       This key is used to encrypt EXTEND cells for this OR.  The key MUST be
-       accepted for at least 1 week after any new key is published in a
-       subsequent descriptor.
-
-    "signing-key" NL a public key in PEM format
-
-       The OR's long-term identity key.
-
-    "accept" exitpattern
-    "reject" exitpattern
-
-       These lines describe the rules that an OR follows when
-       deciding whether to allow a new stream to a given address.  The
-       'exitpattern' syntax is described below.  The rules are considered in
-       order; if no rule matches, the address will be accepted.  For clarity,
-       the last such entry SHOULD be accept *:* or reject *:*.
-
-    "router-signature" NL Signature NL
-
-       The "SIGNATURE" object contains a signature of the PKCS1-padded
-       hash of the entire router descriptor, taken from the beginning of the
-       "router" line, through the newline after the "router-signature" line.
-       The router descriptor is invalid unless the signature is performed
-       with the router's identity key.
-
-    "contact" info NL
-
-        Describes a way to contact the server's administrator, preferably
-        including an email address and a PGP key fingerprint.
-
-    "family" names NL
-
-        'Names' is a space-separated list of server nicknames or
-        hexdigests. If two ORs list one another in their "family" entries,
-        then OPs should treat them as a single OR for the purpose of path
-        selection.
-
-        For example, if node A's descriptor contains "family B", and node B's
-        descriptor contains "family A", then node A and node B should never
-        be used on the same circuit.
-
-    "read-history" YYYY-MM-DD HH:MM:SS (NSEC s) NUM,NUM,NUM,NUM,NUM... NL
-    "write-history" YYYY-MM-DD HH:MM:SS (NSEC s) NUM,NUM,NUM,NUM,NUM... NL
-
-        Declare how much bandwidth the OR has used recently. Usage is divided
-        into intervals of NSEC seconds.  The YYYY-MM-DD HH:MM:SS field
-        defines the end of the most recent interval.  The numbers are the
-        number of bytes used in the most recent intervals, ordered from
-        oldest to newest.
-
-        [We didn't start parsing these lines until Tor 0.1.0.6-rc; they should
-         be marked with "opt" until earlier versions of Tor are obsolete.]
-
-    "eventdns" bool NL
-
-        Declare whether this version of Tor is using the newer enhanced
-        dns logic.  Versions of Tor without eventdns SHOULD NOT be used for
-        reverse hostname lookups.
-
-        [All versions of Tor before 0.1.2.2-alpha should be assumed to have
-         this option set to 0 if it is not present.  All Tor versions at
-         0.1.2.2-alpha or later should be assumed to have this option set to
-         1 if it is not present.  Until 0.1.2.1-alpha-dev, this option was
-         not generated, even when eventdns was in use.  Versions of Tor
-         before 0.1.2.1-alpha-dev did not parse this option, so it should be
-         marked "opt".  With 0.2.0.1-alpha, the old 'dnsworker' logic has
-         been removed, rendering this option of historical interest only.]
-
-2.2. Nonterminals in router descriptors
-
-   nickname ::= between 1 and 19 alphanumeric characters, case-insensitive.
-   hexdigest ::= a '$', followed by 20 hexadecimal characters.
-      [Represents a server by the digest of its identity key.]
-
-   exitpattern ::= addrspec ":" portspec
-   portspec ::= "*" | port | port "-" port
-   port ::= an integer between 1 and 65535, inclusive.
-      [Some implementations incorrectly generate ports with value 0.
-       Implementations SHOULD accept this, and SHOULD NOT generate it.]
-
-   addrspec ::= "*" | ip4spec | ip6spec
-   ipv4spec ::= ip4 | ip4 "/" num_ip4_bits | ip4 "/" ip4mask
-   ip4 ::= an IPv4 address in dotted-quad format
-   ip4mask ::= an IPv4 mask in dotted-quad format
-   num_ip4_bits ::= an integer between 0 and 32
-   ip6spec ::= ip6 | ip6 "/" num_ip6_bits
-   ip6 ::= an IPv6 address, surrounded by square brackets.
-   num_ip6_bits ::= an integer between 0 and 128
-
-   bool ::= "0" | "1"
-
-   Ports are required; if they are not included in the router
-   line, they must appear in the "ports" lines.
-
-3. Network status format
-
-   Directory authorities generate, sign, and compress network-status
-   documents.  Directory servers SHOULD generate a fresh network-status
-   document when the contents of such a document would be different from the
-   last one generated, and some time (at least one second, possibly longer)
-   has passed since the last one was generated.
-
-   The network status document contains a preamble, a set of router status
-   entries, and a signature, in that order.
-
-   We use the same meta-format as used for directories and router descriptors
-   in "tor-spec.txt".  Implementations MAY insert blank lines
-   for clarity between sections; these blank lines are ignored.
-   Implementations MUST NOT depend on blank lines in any particular location.
-
-   As used here, "whitespace" is a sequence of 1 or more tab or space
-   characters.
-
-   The preamble contains:
-
-      "network-status-version" -- A document format version.  For this
-         specification, the version is "2".
-      "dir-source" -- The authority's hostname, current IP address, and
-         directory port, all separated by whitespace.
-      "fingerprint" -- A base16-encoded hash of the signing key's
-         fingerprint, with no additional spaces added.
-      "contact" -- An arbitrary string describing how to contact the
-         directory server's administrator.  Administrators should include at
-         least an email address and a PGP fingerprint.
-      "dir-signing-key" -- The directory server's public signing key.
-      "client-versions" -- A comma-separated list of recommended client
-        versions.
-      "server-versions" -- A comma-separated list of recommended server
-        versions.
-      "published" -- The publication time for this network-status object.
-      "dir-options" -- A set of flags, in any order, separated by whitespace:
-          "Names" if this directory authority performs name bindings.
-          "Versions" if this directory authority recommends software versions.
-          "BadExits" if the directory authority flags nodes that it believes
-              are performing incorrectly as exit nodes.
-          "BadDirectories" if the directory authority flags nodes that it
-              believes are performing incorrectly as directory caches.
-
-   The dir-options entry is optional.  The "-versions" entries are required if
-   the "Versions" flag is present.  The other entries are required and must
-   appear exactly once. The "network-status-version" entry must appear first;
-   the others may appear in any order.  Implementations MUST ignore
-   additional arguments to the items above, and MUST ignore unrecognized
-   flags.
-
-   For each router, the router entry contains:  (This format is designed for
-   conciseness.)
-
-      "r" -- followed by the following elements, in order, separated by
-          whitespace:
-          - The OR's nickname,
-          - A hash of its identity key, encoded in base64, with trailing =
-            signs removed.
-          - A hash of its most recent descriptor, encoded in base64, with
-            trailing = signs removed.  (The hash is calculated as for
-            computing the signature of a descriptor.)
-          - The publication time of its most recent descriptor, in the form
-            YYYY-MM-DD HH:MM:SS, in GMT.
-          - An IP address
-          - An OR port
-          - A directory port (or "0" for none")
-      "s" -- A series of whitespace-separated status flags, in any order:
-          "Authority" if the router is a directory authority.
-          "BadExit" if the router is believed to be useless as an exit node
-             (because its ISP censors it, because it is behind a restrictive
-             proxy, or for some similar reason).
-          "BadDirectory" if the router is believed to be useless as a
-             directory cache (because its directory port isn't working,
-             its bandwidth is always throttled, or for some similar
-             reason).
-          "Exit" if the router is useful for building general-purpose exit
-             circuits.
-          "Fast" if the router is suitable for high-bandwidth circuits.
-          "Guard" if the router is suitable for use as an entry guard.
-          "Named" if the router's identity-nickname mapping is canonical,
-             and this authority binds names.
-          "Stable" if the router is suitable for long-lived circuits.
-          "Running" if the router is currently usable.
-          "Valid" if the router has been 'validated'.
-          "V2Dir" if the router implements this protocol.
-      "v" -- The version of the Tor protocol that this server is running.  If
-          the value begins with "Tor" SP, the rest of the string is a Tor
-          version number, and the protocol is "The Tor protocol as supported
-          by the given version of Tor."  Otherwise, if the value begins with
-          some other string, Tor has upgraded to a more sophisticated
-          protocol versioning system, and the protocol is "a version of the
-          Tor protocol more recent than any we recognize."
-
-      The "r" entry for each router must appear first and is required. The
-      "s" entry is optional (see Section 3.1 below for how the flags are
-      decided). Unrecognized flags on the "s" line and extra elements
-      on the "r" line must be ignored.  The "v" line is optional; it was not
-      supported until 0.1.2.5-alpha, and it must be preceded with an "opt"
-      until all earlier versions of Tor are obsolete.
-
-   The signature section contains:
-
-      "directory-signature" nickname-of-dirserver NL Signature
-
-      Signature is a signature of this network-status document
-      (the document up until the signature, including the line
-      "directory-signature <nick>\n"), using the directory authority's
-      signing key.
-
-   We compress the network status list with zlib before transmitting it.
-
-3.1. Establishing server status
-
-   (This section describes how directory authorities choose which status
-   flags to apply to routers, as of Tor 0.1.1.18-rc. Later directory
-   authorities MAY do things differently, so long as clients keep working
-   well.  Clients MUST NOT depend on the exact behaviors in this section.)
-
-   In the below definitions, a router is considered "active" if it is
-   running, valid, and not hibernating.
-
-   "Valid" -- a router is 'Valid' if it is running a version of Tor not
-   known to be broken, and the directory authority has not blacklisted
-   it as suspicious.
-
-   "Named" -- Directory authority administrators may decide to support name
-   binding.  If they do, then they must maintain a file of
-   nickname-to-identity-key mappings, and try to keep this file consistent
-   with other directory authorities.  If they don't, they act as clients, and
-   report bindings made by other directory authorities (name X is bound to
-   identity Y if at least one binding directory lists it, and no directory
-   binds X to some other Y'.)  A router is called 'Named' if the router
-   believes the given name should be bound to the given key.
-
-   "Running" -- A router is 'Running' if the authority managed to connect to
-   it successfully within the last 30 minutes.
-
-   "Stable" -- A router is 'Stable' if it is active, and either its
-   uptime is at least the median uptime for known active routers, or
-   its uptime is at least 30 days. Routers are never called stable if
-   they are running a version of Tor known to drop circuits stupidly.
-   (0.1.1.10-alpha through 0.1.1.16-rc are stupid this way.)
-
-   "Fast" -- A router is 'Fast' if it is active, and its bandwidth is
-   in the top 7/8ths for known active routers.
-
-   "Guard" -- A router is a possible 'Guard' if it is 'Stable' and its
-   bandwidth is above median for known active routers. If the total
-   bandwidth of active non-BadExit Exit servers is less than one third
-   of the total bandwidth of all active servers, no Exit is listed as
-   a Guard.
-
-   "Authority" -- A router is called an 'Authority' if the authority
-   generating the network-status document believes it is an authority.
-
-   "V2Dir" -- A router supports the v2 directory protocol if it has an open
-   directory port, and it is running a version of the directory protocol that
-   supports the functionality clients need.  (Currently, this is
-   0.1.1.9-alpha or later.)
-
-   Directory server administrators may label some servers or IPs as
-   blacklisted, and elect not to include them in their network-status lists.
-
-   Authorities SHOULD 'disable' any servers in excess of 3 on any single IP.
-   When there are more than 3 to choose from, authorities should first prefer
-   authorities to non-authorities, then prefer Running to non-Running, and
-   then prefer high-bandwidth to low-bandwidth.  To 'disable' a server, the
-   authority *should* advertise it without the Running or Valid flag.
-
-   Thus, the network-status list includes all non-blacklisted,
-   non-expired, non-superseded descriptors.
-
-4. Directory server operation
-
-   All directory authorities and directory mirrors ("directory servers")
-   implement this section, except as noted.
-
-4.1. Accepting uploads (authorities only)
-
-   When a router posts a signed descriptor to a directory authority, the
-   authority first checks whether it is well-formed and correctly
-   self-signed.  If it is, the authority next verifies that the nickname
-   in question is not already assigned to a router with a different
-   public key.
-   Finally, the authority MAY check that the router is not blacklisted
-   because of its key, IP, or another reason.
-
-   If the descriptor passes these tests, and the authority does not already
-   have a descriptor for a router with this public key, it accepts the
-   descriptor and remembers it.
-
-   If the authority _does_ have a descriptor with the same public key, the
-   newly uploaded descriptor is remembered if its publication time is more
-   recent than the most recent old descriptor for that router, and either:
-      - There are non-cosmetic differences between the old descriptor and the
-        new one.
-      - Enough time has passed between the descriptors' publication times.
-        (Currently, 12 hours.)
-
-   Differences between router descriptors are "non-cosmetic" if they would be
-   sufficient to force an upload as described in section 2 above.
-
-   Note that the "cosmetic difference" test only applies to uploaded
-   descriptors, not to descriptors that the authority downloads from other
-   authorities.
-
-4.2. Downloading network-status documents (authorities and caches)
-
-   All directory servers (authorities and mirrors) try to keep a fresh
-   set of network-status documents from every authority.  To do so,
-   every 5 minutes, each authority asks every other authority for its
-   most recent network-status document.  Every 15 minutes, each mirror
-   picks a random authority and asks it for the most recent network-status
-   documents for all the authorities the authority knows about (including
-   the chosen authority itself).
-
-   Directory servers and mirrors remember and serve the most recent
-   network-status document they have from each authority.  Other
-   network-status documents don't need to be stored.  If the most recent
-   network-status document is over 10 days old, it is discarded anyway.
-   Mirrors SHOULD store and serve network-status documents from authorities
-   they don't recognize, but SHOULD NOT use such documents for any other
-   purpose.  Mirrors SHOULD discard network-status documents older than 48
-   hours.
-
-4.3. Downloading and storing router descriptors (authorities and caches)
-
-   Periodically (currently, every 10 seconds), directory servers check
-   whether there are any specific descriptors (as identified by descriptor
-   hash in a network-status document) that they do not have and that they
-   are not currently trying to download.
-
-   If so, the directory server launches requests to the authorities for these
-   descriptors, such that each authority is only asked for descriptors listed
-   in its most recent network-status.  When more than one authority lists the
-   descriptor, we choose which to ask at random.
-
-   If one of these downloads fails, we do not try to download that descriptor
-   from the authority that failed to serve it again unless we receive a newer
-   network-status from that authority that lists the same descriptor.
-
-   Directory servers must potentially cache multiple descriptors for each
-   router. Servers must not discard any descriptor listed by any current
-   network-status document from any authority.  If there is enough space to
-   store additional descriptors, servers SHOULD try to hold those which
-   clients are likely to download the most.  (Currently, this is judged
-   based on the interval for which each descriptor seemed newest.)
-
-   Authorities SHOULD NOT download descriptors for routers that they would
-   immediately reject for reasons listed in 3.1.
-
-4.4. HTTP URLs
-
-   "Fingerprints" in these URLs are base-16-encoded SHA1 hashes.
-
-   The authoritative network-status published by a host should be available at:
-      http://<hostname>/tor/status/authority.z
-
-   The network-status published by a host with fingerprint
-   <F> should be available at:
-      http://<hostname>/tor/status/fp/<F>.z
-
-   The network-status documents published by hosts with fingerprints
-   <F1>,<F2>,<F3> should be available at:
-      http://<hostname>/tor/status/fp/<F1>+<F2>+<F3>.z
-
-   The most recent network-status documents from all known authorities,
-   concatenated, should be available at:
-      http://<hostname>/tor/status/all.z
-
-   The most recent descriptor for a server whose identity key has a
-   fingerprint of <F> should be available at:
-      http://<hostname>/tor/server/fp/<F>.z
-
-   The most recent descriptors for servers with identity fingerprints
-   <F1>,<F2>,<F3> should be available at:
-      http://<hostname>/tor/server/fp/<F1>+<F2>+<F3>.z
-
-   (NOTE: Implementations SHOULD NOT download descriptors by identity key
-   fingerprint. This allows a corrupted server (in collusion with a cache) to
-   provide a unique descriptor to a client, and thereby partition that client
-   from the rest of the network.)
-
-   The server descriptor with (descriptor) digest <D> (in hex) should be
-   available at:
-      http://<hostname>/tor/server/d/<D>.z
-
-   The most recent descriptors with digests <D1>,<D2>,<D3> should be
-   available at:
-      http://<hostname>/tor/server/d/<D1>+<D2>+<D3>.z
-
-   The most recent descriptor for this server should be at:
-      http://<hostname>/tor/server/authority.z
-    [Nothing in the Tor protocol uses this resource yet, but it is useful
-     for debugging purposes. Also, the official Tor implementations
-     (starting at 0.1.1.x) use this resource to test whether a server's
-     own DirPort is reachable.]
-
-   A concatenated set of the most recent descriptors for all known servers
-   should be available at:
-      http://<hostname>/tor/server/all.z
-
-   For debugging, directories SHOULD expose non-compressed objects at URLs like
-   the above, but without the final ".z".
-   Clients MUST handle compressed concatenated information in two forms:
-     - A concatenated list of zlib-compressed objects.
-     - A zlib-compressed concatenated list of objects.
-   Directory servers MAY generate either format: the former requires less
-   CPU, but the latter requires less bandwidth.
-
-   Clients SHOULD use upper case letters (A-F) when base16-encoding
-   fingerprints.  Servers MUST accept both upper and lower case fingerprints
-   in requests.
-
-5. Client operation: downloading information
-
-   Every Tor that is not a directory server (that is, those that do
-   not have a DirPort set) implements this section.
-
-5.1. Downloading network-status documents
-
-   Each client maintains an ordered list of directory authorities.
-   Insofar as possible, clients SHOULD all use the same ordered list.
-
-   For each network-status document a client has, it keeps track of its
-   publication time *and* the time when the client retrieved it.  Clients
-   consider a network-status document "live" if it was published within the
-   last 24 hours.
-
-   Clients try to have a live network-status document hours from *every*
-   authority, and try to periodically get new network-status documents from
-   each authority in rotation as follows:
-
-   If a client is missing a live network-status document for any
-   authority, it tries to fetch it from a directory cache.  On failure,
-   the client waits briefly, then tries that network-status document
-   again from another cache.  The client does not build circuits until it
-   has live network-status documents from more than half the authorities
-   it trusts, and it has descriptors for more than 1/4 of the routers
-   that it believes are running.
-
-   If the most recently _retrieved_ network-status document is over 30
-   minutes old, the client attempts to download a network-status document.
-   When choosing which documents to download, clients treat their list of
-   directory authorities as a circular ring, and begin with the authority
-   appearing immediately after the authority for their most recently
-   retrieved network-status document.  If this attempt fails (either it
-   fails to download at all, or the one it gets is not as good as the
-   one it has), the client retries at other caches several times, before
-   moving on to the next network-status document in sequence.
-
-   Clients discard all network-status documents over 24 hours old.
-
-   If enough mirrors (currently 4) claim not to have a given network status,
-   we stop trying to download that authority's network-status, until we
-   download a new network-status that makes us believe that the authority in
-   question is running.  Clients should wait a little longer after each
-   failure.
-
-   Clients SHOULD try to batch as many network-status requests as possible
-   into each HTTP GET.
-
-   (Note: clients can and should pick caches based on the network-status
-   information they have: once they have first fetched network-status info
-   from an authority, they should not need to go to the authority directly
-   again.)
-
-5.2. Downloading and storing router descriptors
-
-   Clients try to have the best descriptor for each router.  A descriptor is
-   "best" if:
-      * It is the most recently published descriptor listed for that router
-        by at least two network-status documents.
-        OR,
-      * No descriptor for that router is listed by two or more
-        network-status documents, and it is the most recently published
-        descriptor listed by any network-status document.
-
-   Periodically (currently every 10 seconds) clients check whether there are
-   any "downloadable" descriptors.  A descriptor is downloadable if:
-      - It is the "best" descriptor for some router.
-      - The descriptor was published at least 10 minutes in the past.
-        (This prevents clients from trying to fetch descriptors that the
-        mirrors have probably not yet retrieved and cached.)
-      - The client does not currently have it.
-      - The client is not currently trying to download it.
-      - The client would not discard it immediately upon receiving it.
-      - The client thinks it is running and valid (see 6.1 below).
-
-   If at least 16 known routers have downloadable descriptors, or if
-   enough time (currently 10 minutes) has passed since the last time the
-   client tried to download descriptors, it launches requests for all
-   downloadable descriptors, as described in 5.3 below.
-
-   When a descriptor download fails, the client notes it, and does not
-   consider the descriptor downloadable again until a certain amount of time
-   has passed. (Currently 0 seconds for the first failure, 60 seconds for the
-   second, 5 minutes for the third, 10 minutes for the fourth, and 1 day
-   thereafter.)  Periodically (currently once an hour) clients reset the
-   failure count.
-
-   No descriptors are downloaded until the client has downloaded more than
-   half of the network-status documents.
-
-   Clients retain the most recent descriptor they have downloaded for each
-   router so long as it is not too old (currently, 48 hours), OR so long as
-   it is recommended by at least one networkstatus AND no "better"
-   descriptor has been downloaded.  [Versions of Tor before 0.1.2.3-alpha
-   would discard descriptors simply for being published too far in the past.]
-   [The code seems to discard descriptors in all cases after they're 5
-   days old. True? -RD]
-
-5.3. Managing downloads
-
-   When a client has no live network-status documents, it downloads
-   network-status documents from a randomly chosen authority.  In all other
-   cases, the client downloads from mirrors randomly chosen from among those
-   believed to be V2 directory servers.  (This information comes from the
-   network-status documents; see 6 below.)
-
-   When downloading multiple router descriptors, the client chooses multiple
-   mirrors so that:
-     - At least 3 different mirrors are used, except when this would result
-       in more than one request for under 4 descriptors.
-     - No more than 128 descriptors are requested from a single mirror.
-     - Otherwise, as few mirrors as possible are used.
-   After choosing mirrors, the client divides the descriptors among them
-   randomly.
-
-   After receiving any response client MUST discard any network-status
-   documents and descriptors that it did not request.
-
-6. Using directory information
-
-   Everyone besides directory authorities uses the approaches in this section
-   to decide which servers to use and what their keys are likely to be.
-   (Directory authorities just believe their own opinions, as in 3.1 above.)
-
-6.1. Choosing routers for circuits.
-
-   Tor implementations only pay attention to "live" network-status documents.
-   A network status is "live" if it is the most recently downloaded network
-   status document for a given directory server, and the server is a
-   directory server trusted by the client, and the network-status document is
-   no more than 1 day old.
-
-   For time-sensitive information, Tor implementations focus on "recent"
-   network-status documents.  A network status is "recent" if it is live, and
-   if it was published in the last 60 minutes.  If there are fewer
-   than 3 such documents, the most recently published 3 are "recent."  If
-   there are fewer than 3 in all, all are "recent.")
-
-   Circuits SHOULD NOT be built until the client has enough directory
-   information: network-statuses (or failed attempts to download
-   network-statuses) for all authorities, network-statuses for at more than
-   half of the authorities, and descriptors for at least 1/4 of the servers
-   believed to be running.
-
-   A server is "listed" if it is included by more than half of the live
-   network status documents.  Clients SHOULD NOT use unlisted servers.
-
-   Clients believe the flags "Valid", "Exit", "Fast", "Guard", "Stable", and
-   "V2Dir" about a given router when they are asserted by more than half of
-   the live network-status documents.  Clients believe the flag "Running" if
-   it is listed by more than half of the recent network-status documents.
-
-   These flags are used as follows:
-
-     - Clients SHOULD NOT use non-'Valid' or non-'Running' routers unless
-       requested to do so.
-
-     - Clients SHOULD NOT use non-'Fast' routers for any purpose other than
-       very-low-bandwidth circuits (such as introduction circuits).
-
-     - Clients SHOULD NOT use non-'Stable' routers for circuits that are
-       likely to need to be open for a very long time (such as those used for
-       IRC or SSH connections).
-
-     - Clients SHOULD NOT choose non-'Guard' nodes when picking entry guard
-       nodes.
-
-     - Clients SHOULD NOT download directory information from non-'V2Dir'
-       caches.
-
-6.2. Managing naming
-
-   In order to provide human-memorable names for individual server
-   identities, some directory servers bind names to IDs.  Clients handle
-   names in two ways:
-
-   When a client encounters a name it has not mapped before:
-
-      If all the live "Naming" network-status documents the client has
-      claim that the name binds to some identity ID, and the client has at
-      least three live network-status documents, the client maps the name to
-      ID.
-
-   When a user tries to refer to a router with a name that does not have a
-   mapping under the above rules, the implementation SHOULD warn the user.
-   After giving the warning, the implementation MAY use a router that at
-   least one Naming authority maps the name to, so long as no other naming
-   authority maps that name to a different router.  If no Naming authority
-   maps the name to a router, the implementation MAY use any router that
-   advertises the name.
-
-   Not every router needs a nickname.  When a router doesn't configure a
-   nickname, it publishes with the default nickname "Unnamed".  Authorities
-   SHOULD NOT ever mark a router with this nickname as Named; client software
-   SHOULD NOT ever use a router in response to a user request for a router
-   called "Unnamed".
-
-6.3. Software versions
-
-   An implementation of Tor SHOULD warn when it has fetched (or has
-   attempted to fetch and failed four consecutive times) a network-status
-   for each authority, and it is running a software version
-   not listed on more than half of the live "Versioning" network-status
-   documents.
-
-6.4. Warning about a router's status.
-
-   If a router tries to publish its descriptor to a Naming authority
-   that has its nickname mapped to another key, the router SHOULD
-   warn the operator that it is either using the wrong key or is using
-   an already claimed nickname.
-
-   If a router has fetched (or attempted to fetch and failed four
-   consecutive times) a network-status for every authority, and at
-   least one of the authorities is "Naming", and no live "Naming"
-   authorities publish a binding for the router's nickname, the
-   router MAY remind the operator that the chosen nickname is not
-   bound to this key at the authorities, and suggest contacting the
-   authority operators.
-
-   ...
-
-6.5. Router protocol versions
-
-   A client should believe that a router supports a given feature if that
-   feature is supported by the router or protocol versions in more than half
-   of the live networkstatus's "v" entries for that router.  In other words,
-   if the "v" entries for some router are:
-       v Tor 0.0.8pre1                (from authority 1)
-       v Tor 0.1.2.11                 (from authority 2)
-       v FutureProtocolDescription 99 (from authority 3)
-   then the client should believe that the router supports any feature
-   supported by 0.1.2.11.
-
-   This is currently equivalent to believing the median declared version for
-   a router in all live networkstatuses.
-
-7. Standards compliance
-
-   All clients and servers MUST support HTTP 1.0.
-
-7.1. HTTP headers
-
-  Servers MAY set the Content-Length: header.  Servers SHOULD set
-  Content-Encoding to "deflate" or "identity".
-
-  Servers MAY include an X-Your-Address-Is: header, whose value is the
-  apparent IP address of the client connecting to them (as a dotted quad).
-  For directory connections tunneled over a BEGIN_DIR stream, servers SHOULD
-  report the IP from which the circuit carrying the BEGIN_DIR stream reached
-  them.  [Servers before version 0.1.2.5-alpha reported 127.0.0.1 for all
-  BEGIN_DIR-tunneled connections.]
-
-  Servers SHOULD disable caching of multiple network statuses or multiple
-  router descriptors.  Servers MAY enable caching of single descriptors,
-  single network statuses, the list of all router descriptors, a v1
-  directory, or a v1 running routers document.  XXX mention times.
-
-7.2. HTTP status codes
-
-  XXX We should write down what return codes dirservers send in what situations.
-
diff --git a/doc/spec/dir-spec.txt b/doc/spec/dir-spec.txt
deleted file mode 100644
index 9a2a62b..0000000
--- a/doc/spec/dir-spec.txt
+++ /dev/null
@@ -1,1898 +0,0 @@
-$Id$
-
-                      Tor directory protocol, version 3
-
-0. Scope and preliminaries
-
-   This directory protocol is used by Tor version 0.2.0.x-alpha and later.
-   See dir-spec-v1.txt for information on the protocol used up to the
-   0.1.0.x series, and dir-spec-v2.txt for information on the protocol
-   used by the 0.1.1.x and 0.1.2.x series.
-
-   Caches and authorities must still support older versions of the
-   directory protocols, until the versions of Tor that require them are
-   finally out of commission.  See Section XXXX on backward compatibility.
-
-   This document merges and supersedes the following proposals:
-
-       101  Voting on the Tor Directory System
-       103  Splitting identity key from regularly used signing key
-       104  Long and Short Router Descriptors
-
-   AS OF 14 JUNE 2007, THIS SPECIFICATION HAS NOT YET BEEN COMPLETELY
-   IMPLEMENTED, OR COMPLETELY COMPLETED.
-
-   XXX when to download certificates.
-   XXX timeline
-   XXX fill in XXXXs
-
-0.1. History
-
-   The earliest versions of Onion Routing shipped with a list of known
-   routers and their keys.  When the set of routers changed, users needed to
-   fetch a new list.
-
-   The Version 1 Directory protocol
-   --------------------------------
-
-   Early versions of Tor (0.0.2) introduced "Directory authorities": servers
-   that served signed "directory" documents containing a list of signed
-   "router descriptors", along with short summary of the status of each
-   router.  Thus, clients could get up-to-date information on the state of
-   the network automatically, and be certain that the list they were getting
-   was attested by a trusted directory authority.
-
-   Later versions (0.0.8) added directory caches, which download
-   directories from the authorities and serve them to clients.  Non-caches
-   fetch from the caches in preference to fetching from the authorities, thus
-   distributing bandwidth requirements.
-
-   Also added during the version 1 directory protocol were "router status"
-   documents: short documents that listed only the up/down status of the
-   routers on the network, rather than a complete list of all the
-   descriptors.  Clients and caches would fetch these documents far more
-   frequently than they would fetch full directories.
-
-   The Version 2 Directory Protocol
-   --------------------------------
-
-   During the Tor 0.1.1.x series, Tor revised its handling of directory
-   documents in order to address two major problems:
-
-      * Directories had grown quite large (over 1MB), and most directory
-        downloads consisted mainly of router descriptors that clients
-        already had.
-
-      * Every directory authority was a trust bottleneck: if a single
-        directory authority lied, it could make clients believe for a time
-        an arbitrarily distorted view of the Tor network.  (Clients
-        trusted the most recent signed document they downloaded.) Thus,
-        adding more authorities would make the system less secure, not
-        more.
-
-   To address these, we extended the directory protocol so that
-   authorities now published signed "network status" documents.  Each
-   network status listed, for every router in the network: a hash of its
-   identity key, a hash of its most recent descriptor, and a summary of
-   what the authority believed about its status.  Clients would download
-   the authorities' network status documents in turn, and believe
-   statements about routers iff they were attested to by more than half of
-   the authorities.
-
-   Instead of downloading all router descriptors at once, clients
-   downloaded only the descriptors that they did not have.  Descriptors
-   were indexed by their digests, in order to prevent malicious caches
-   from giving different versions of a router descriptor to different
-   clients.
-
-   Routers began working harder to upload new descriptors only when their
-   contents were substantially changed.
-
-
-0.2. Goals of the version 3 protocol
-
-   Version 3 of the Tor directory protocol tries to solve the following
-   issues:
-
-      * A great deal of bandwidth used to transmit router descriptors was
-        used by two fields that are not actually used by Tor routers
-        (namely read-history and write-history).  We save about 60% by
-        moving them into a separate document that most clients do not
-        fetch or use.
-
-      * It was possible under certain perverse circumstances for clients
-        to download an unusual set of network status documents, thus
-        partitioning themselves from clients who have a more recent and/or
-        typical set of documents.  Even under the best of circumstances,
-        clients were sensitive to the ages of the network status documents
-        they downloaded.  Therefore, instead of having the clients
-        correlate multiple network status documents, we have the
-        authorities collectively vote on a single consensus network status
-        document.
-
-      * The most sensitive data in the entire network (the identity keys
-        of the directory authorities) needed to be stored unencrypted so
-        that the authorities can sign network-status documents on the fly.
-        Now, the authorities' identity keys are stored offline, and used
-        to certify medium-term signing keys that can be rotated.
-
-0.3. Some Remaining questions
-
-   Things we could solve on a v3 timeframe:
-
-     The SHA-1 hash is showing its age.  We should do something about our
-     dependency on it.  We could probably future-proof ourselves here in
-     this revision, at least so far as documents from the authorities are
-     concerned.
-
-     Too many things about the authorities are hardcoded by IP.
-
-     Perhaps we should start accepting longer identity keys for routers
-     too.
-
-   Things to solve eventually:
-
-     Requiring every client to know about every router won't scale forever.
-
-     Requiring every directory cache to know every router won't scale
-     forever.
-
-
-1. Outline
-
-   There is a small set (say, around 5-10) of semi-trusted directory
-   authorities.  A default list of authorities is shipped with the Tor
-   software.  Users can change this list, but are encouraged not to do so,
-   in order to avoid partitioning attacks.
-
-   Every authority has a very-secret, long-term "Authority Identity Key".
-   This is stored encrypted and/or offline, and is used to sign "key
-   certificate" documents.  Every key certificate contains a medium-term
-   (3-12 months) "authority signing key", that is used by the authority to
-   sign other directory information.  (Note that the authority identity
-   key is distinct from the router identity key that the authority uses
-   in its role as an ordinary router.)
-
-   Routers periodically upload signed "routers descriptors" to the
-   directory authorities describing their keys, capabilities, and other
-   information.  Routers may also upload signed "extra info documents"
-   containing information that is not required for the Tor protocol.
-   Directory authorities serve router descriptors indexed by router
-   identity, or by hash of the descriptor.
-
-   Routers may act as directory caches to reduce load on the directory
-   authorities.  They announce this in their descriptors.
-
-   Periodically, each directory authority generates a view of
-   the current descriptors and status for known routers.  They send a
-   signed summary of this view (a "status vote") to the other
-   authorities.  The authorities compute the result of this vote, and sign
-   a "consensus status" document containing the result of the vote.
-
-   Directory caches download, cache, and re-serve consensus documents.
-
-   Clients, directory caches, and directory authorities all use consensus
-   documents to find out when their list of routers is out-of-date.
-   (Directory authorities also use vote statuses.) If it is, they download
-   any missing router descriptors.  Clients download missing descriptors
-   from caches; caches and authorities download from authorities.
-   Descriptors are downloaded by the hash of the descriptor, not by the
-   server's identity key: this prevents servers from attacking clients by
-   giving them descriptors nobody else uses.
-
-   All directory information is uploaded and downloaded with HTTP.
-
-   [Authorities also generate and caches also cache documents produced and
-   used by earlier versions of this protocol; see section XXX for notes.]
-
-1.1. What's different from version 2?
-
-   Clients used to download multiple network status documents,
-   corresponding roughly to "status votes" above.  They would compute the
-   result of the vote on the client side.
-
-   Authorities used to sign documents using the same private keys they used
-   for their roles as routers.  This forced them to keep these extremely
-   sensitive keys in memory unencrypted.
-
-   All of the information in extra-info documents used to be kept in the
-   main descriptors.
-
-1.2. Document meta-format
-
-  Router descriptors, directories, and running-routers documents all obey the
-  following lightweight extensible information format.
-
-  The highest level object is a Document, which consists of one or more
-  Items.  Every Item begins with a KeywordLine, followed by zero or more
-  Objects. A KeywordLine begins with a Keyword, optionally followed by
-  whitespace and more non-newline characters, and ends with a newline.  A
-  Keyword is a sequence of one or more characters in the set [A-Za-z0-9-].
-  An Object is a block of encoded data in pseudo-Open-PGP-style
-  armor. (cf. RFC 2440)
-
-  More formally:
-
-    NL = The ascii LF character (hex value 0x0a).
-    Document ::= (Item | NL)+
-    Item ::= KeywordLine Object*
-    KeywordLine ::= Keyword NL | Keyword WS ArgumentChar+ NL
-    Keyword = KeywordChar+
-    KeywordChar ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9' | '-'
-    ArgumentChar ::= any printing ASCII character except NL.
-    WS = (SP | TAB)+
-    Object ::= BeginLine Base-64-encoded-data EndLine
-    BeginLine ::= "-----BEGIN " Keyword "-----" NL
-    EndLine ::= "-----END " Keyword "-----" NL
-
-    The BeginLine and EndLine of an Object must use the same keyword.
-
-  When interpreting a Document, software MUST ignore any KeywordLine that
-  starts with a keyword it doesn't recognize; future implementations MUST NOT
-  require current clients to understand any KeywordLine not currently
-  described.
-
-  The "opt" keyword was used until Tor 0.1.2.5-alpha for non-critical future
-  extensions.  All implementations MUST ignore any item of the form "opt
-  keyword ....." when they would not recognize "keyword ....."; and MUST
-  treat "opt keyword ....."  as synonymous with "keyword ......" when keyword
-  is recognized.
-
-  Implementations before 0.1.2.5-alpha rejected any document with a
-  KeywordLine that started with a keyword that they didn't recognize.
-  When generating documents that need to be read by older versions of Tor,
-  implementations MUST prefix items not recognized by older versions of
-  Tor with an "opt" until those versions of Tor are obsolete.  [Note that
-  key certificates, status vote documents, extra info documents, and
-  status consensus documents will never be read by older versions of Tor.]
-
-  Other implementations that want to extend Tor's directory format MAY
-  introduce their own items.  The keywords for extension items SHOULD start
-  with the characters "x-" or "X-", to guarantee that they will not conflict
-  with keywords used by future versions of Tor.
-
-  In our document descriptions below, we tag Items with a multiplicity in
-  brackets.  Possible tags are:
-
-    "At start, exactly once": These items MUST occur in every instance of
-      the document type, and MUST appear exactly once, and MUST be the
-      first item in their documents.
-
-    "Exactly once": These items MUST occur exactly one time in every
-      instance of the document type.
-
-    "At end, exactly once": These items MUST occur in every instance of
-      the document type, and MUST appear exactly once, and MUST be the
-      last item in their documents.
-
-    "At most once": These items MAY occur zero or one times in any
-      instance of the document type, but MUST NOT occur more than once.
-
-    "Any number": These items MAY occur zero, one, or more times in any
-      instance of the document type.
-
-    "Once or more": These items MUST occur at least once in any instance
-      of the document type, and MAY occur more.
-
-1.3. Signing documents
-
-   Every signable document below is signed in a similar manner, using a
-   given "Initial Item", a final "Signature Item", a digest algorithm, and
-   a signing key.
-
-   The Initial Item must be the first item in the document.
-
-   The Signature Item has the following format:
-
-     <signature item keyword> [arguments] NL SIGNATURE NL
-
-   The "SIGNATURE" Object contains a signature (using the signing key) of
-   the PKCS1-padded digest of the entire document, taken from the
-   beginning of the Initial item, through the newline after the Signature
-   Item's keyword and its arguments.
-
-   Unless otherwise, the digest algorithm is SHA-1.
-
-   All documents are invalid unless signed with the correct signing key.
-
-   The "Digest" of a document, unless stated otherwise, is its digest *as
-   signed by this signature scheme*.
-
-1.4. Voting timeline
-
-   Every consensus document has a "valid-after" (VA) time, a "fresh-until"
-   (FU) time and a "valid-until" (VU) time.  VA MUST precede FU, which MUST
-   in turn precede VU.  Times are chosen so that every consensus will be
-   "fresh" until the next consensus becomes valid, and "valid" for a while
-   after.  At least 3 consensuses should be valid at any given time.
-
-   The timeline for a given consensus is as follows:
-
-   VA-DistSeconds-VoteSeconds: The authorities exchange votes.
-
-   VA-DistSeconds-VoteSeconds/2: The authorities try to download any
-   votes they don't have.
-
-   VA-DistSeconds: The authorities calculate the consensus and exchange
-   signatures.
-
-   VA-DistSeconds/2: The authorities try to download any signatures
-   they don't have.
-
-   VA: All authorities have a multiply signed consensus.
-
-   VA ... FU: Caches download the consensus.  (Note that since caches have
-        no way of telling what VA and FU are until they have downloaded
-        the consensus, they assume that the present consensus's VA is
-        equal to the previous one's FU, and that its FU is one interval after
-        that.)
-
-   FU: The consensus is no longer the freshest consensus.
-
-   FU ... (the current consensus's VU): Clients download the consensus.
-        (See note above: clients guess that the next consensus's FU will be
-        two intervals after the current VA.)
-
-   VU: The consensus is no longer valid.
-
-   VoteSeconds and DistSeconds MUST each be at least 20 seconds; FU-VA and
-   VU-FU MUST each be at least 5 minutes.
-
-2. Router operation and formats
-
-   ORs SHOULD generate a new router descriptor and a new extra-info
-   document whenever any of the following events have occurred:
-
-      - A period of time (18 hrs by default) has passed since the last
-        time a descriptor was generated.
-
-      - A descriptor field other than bandwidth or uptime has changed.
-
-      - Bandwidth has changed by a factor of 2 from the last time a
-        descriptor was generated, and at least a given interval of time
-        (20 mins by default) has passed since then.
-
-      - Its uptime has been reset (by restarting).
-
-      [XXX this list is incomplete; see router_differences_are_cosmetic()
-       in routerlist.c for others]
-
-   ORs SHOULD NOT publish a new router descriptor or extra-info document
-   if none of the above events have occurred and not much time has passed
-   (12 hours by default).
-
-   After generating a descriptor, ORs upload them to every directory
-   authority they know, by posting them (in order) to the URL
-
-      http://<hostname:port>/tor/
-
-2.1. Router descriptor format
-
-   Router descriptors consist of the following items.  For backward
-   compatibility, there should be an extra NL at the end of each router
-   descriptor.
-
-   In lines that take multiple arguments, extra arguments SHOULD be
-   accepted and ignored.  Many of the nonterminals below are defined in
-   section 2.3.
-
-     "router" nickname address ORPort SOCKSPort DirPort NL
-
-       [At start, exactly once.]
-
-       Indicates the beginning of a router descriptor.  "nickname" must be a
-       valid router nickname as specified in 2.3.  "address" must be an IPv4
-       address in dotted-quad format.  The last three numbers indicate the
-       TCP ports at which this OR exposes functionality. ORPort is a port at
-       which this OR accepts TLS connections for the main OR protocol;
-       SOCKSPort is deprecated and should always be 0; and DirPort is the
-       port at which this OR accepts directory-related HTTP connections.  If
-       any port is not supported, the value 0 is given instead of a port
-       number.  (At least one of DirPort and ORPort SHOULD be set;
-       authorities MAY reject any descriptor with both DirPort and ORPort of
-       0.)
-
-    "bandwidth" bandwidth-avg bandwidth-burst bandwidth-observed NL
-
-       [Exactly once]
-
-       Estimated bandwidth for this router, in bytes per second.  The
-       "average" bandwidth is the volume per second that the OR is willing to
-       sustain over long periods; the "burst" bandwidth is the volume that
-       the OR is willing to sustain in very short intervals.  The "observed"
-       value is an estimate of the capacity this server can handle.  The
-       server remembers the max bandwidth sustained output over any ten
-       second period in the past day, and another sustained input.  The
-       "observed" value is the lesser of these two numbers.
-
-    "platform" string NL
-
-       [At most once]
-
-       A human-readable string describing the system on which this OR is
-       running.  This MAY include the operating system, and SHOULD include
-       the name and version of the software implementing the Tor protocol.
-
-    "published" YYYY-MM-DD HH:MM:SS NL
-
-       [Exactly once]
-
-       The time, in GMT, when this descriptor (and its corresponding
-       extra-info document if any)  was generated.
-
-    "fingerprint" fingerprint NL
-
-       [At most once]
-
-       A fingerprint (a HASH_LEN-byte of asn1 encoded public key, encoded in
-       hex, with a single space after every 4 characters) for this router's
-       identity key. A descriptor is considered invalid (and MUST be
-       rejected) if the fingerprint line does not match the public key.
-
-       [We didn't start parsing this line until Tor 0.1.0.6-rc; it should
-        be marked with "opt" until earlier versions of Tor are obsolete.]
-
-    "hibernating" bool NL
-
-       [At most once]
-
-       If the value is 1, then the Tor server was hibernating when the
-       descriptor was published, and shouldn't be used to build circuits.
-
-       [We didn't start parsing this line until Tor 0.1.0.6-rc; it should be
-        marked with "opt" until earlier versions of Tor are obsolete.]
-
-    "uptime" number NL
-
-       [At most once]
-
-       The number of seconds that this OR process has been running.
-
-    "onion-key" NL a public key in PEM format
-
-       [Exactly once]
-
-       This key is used to encrypt EXTEND cells for this OR.  The key MUST be
-       accepted for at least 1 week after any new key is published in a
-       subsequent descriptor. It MUST be 1024 bits.
-
-    "signing-key" NL a public key in PEM format
-
-       [Exactly once]
-
-       The OR's long-term identity key.  It MUST be 1024 bits.
-
-    "accept" exitpattern NL
-    "reject" exitpattern NL
-
-       [Any number]
-
-       These lines describe an "exit policy": the rules that an OR follows
-       when deciding whether to allow a new stream to a given address.  The
-       'exitpattern' syntax is described below.  There MUST be at least one
-       such entry.  The rules are considered in order; if no rule matches,
-       the address will be accepted.  For clarity, the last such entry SHOULD
-       be accept *:* or reject *:*.
-
-    "router-signature" NL Signature NL
-
-       [At end, exactly once]
-
-       The "SIGNATURE" object contains a signature of the PKCS1-padded
-       hash of the entire router descriptor, taken from the beginning of the
-       "router" line, through the newline after the "router-signature" line.
-       The router descriptor is invalid unless the signature is performed
-       with the router's identity key.
-
-    "contact" info NL
-
-       [At most once]
-
-       Describes a way to contact the server's administrator, preferably
-       including an email address and a PGP key fingerprint.
-
-    "family" names NL
-
-        [At most once]
-
-        'Names' is a space-separated list of server nicknames or
-        hexdigests. If two ORs list one another in their "family" entries,
-        then OPs should treat them as a single OR for the purpose of path
-        selection.
-
-        For example, if node A's descriptor contains "family B", and node B's
-        descriptor contains "family A", then node A and node B should never
-        be used on the same circuit.
-
-    "read-history" YYYY-MM-DD HH:MM:SS (NSEC s) NUM,NUM,NUM,NUM,NUM... NL
-        [At most once]
-    "write-history" YYYY-MM-DD HH:MM:SS (NSEC s) NUM,NUM,NUM,NUM,NUM... NL
-        [At most once]
-
-        Declare how much bandwidth the OR has used recently. Usage is divided
-        into intervals of NSEC seconds.  The YYYY-MM-DD HH:MM:SS field
-        defines the end of the most recent interval.  The numbers are the
-        number of bytes used in the most recent intervals, ordered from
-        oldest to newest.
-
-        [We didn't start parsing these lines until Tor 0.1.0.6-rc; they should
-         be marked with "opt" until earlier versions of Tor are obsolete.]
-
-        [See also migration notes in section 2.2.1.]
-
-    "eventdns" bool NL
-
-        [At most once]
-
-        Declare whether this version of Tor is using the newer enhanced
-        dns logic.  Versions of Tor with this field set to false SHOULD NOT
-        be used for reverse hostname lookups.
-
-        [All versions of Tor before 0.1.2.2-alpha should be assumed to have
-         this option set to 0 if it is not present.  All Tor versions at
-         0.1.2.2-alpha or later should be assumed to have this option set to
-         1 if it is not present.  Until 0.1.2.1-alpha-dev, this option was
-         not generated, even when the new DNS code was in use.  Versions of Tor
-         before 0.1.2.1-alpha-dev did not parse this option, so it should be
-         marked "opt".  The dnsworker logic has been removed, so this option
-         should not be used by new server code.  However, it can still be
-         used, and should still be recognized by new code until Tor 0.1.2.x
-         is obsolete.]
-
-   "caches-extra-info" NL
-
-       [At most once.]
-
-       Present only if this router is a directory cache that provides
-       extra-info documents.
-
-       [Versions before 0.2.0.1-alpha don't recognize this, and versions
-        before 0.1.2.5-alpha will reject descriptors containing it unless
-        it is prefixed with "opt"; it should be so prefixed until these
-        versions are obsolete.]
-
-   "extra-info-digest" digest NL
-
-       [At most once]
-
-       "Digest" is a hex-encoded digest (using upper-case characters) of the
-       router's extra-info document, as signed in the router's extra-info
-       (that is, not including the signature).  (If this field is absent, the
-       router is not uploading a corresponding extra-info document.)
-
-       [Versions before 0.2.0.1-alpha don't recognize this, and versions
-        before 0.1.2.5-alpha will reject descriptors containing it unless
-        it is prefixed with "opt"; it should be so prefixed until these
-        versions are obsolete.]
-
-   "hidden-service-dir" *(SP VersionNum) NL
-
-       [At most once.]
-
-       Present only if this router stores and serves hidden service
-       descriptors. If any VersionNum(s) are specified, this router
-       supports those descriptor versions. If none are specified, it
-       defaults to version 2 descriptors.
-
-       [Versions of Tor before 0.1.2.5-alpha rejected router descriptors
-        with unrecognized items; the protocols line should be preceded with
-        an "opt" until these Tors are obsolete.]
-
-   "protocols" SP "Link" SP LINK-VERSION-LIST SP "Circuit" SP
-          CIRCUIT-VERSION-LIST NL
-
-       [At most once.]
-
-       Both lists are space-separated sequences of numbers, to indicate which
-       protocols the server supports.  As of 30 Mar 2008, specified
-       protocols are "Link 1 2 Circuit 1".  See section 4.1 of tor-spec.txt
-       for more information about link protocol versions.
-
-       [Versions of Tor before 0.1.2.5-alpha rejected router descriptors
-        with unrecognized items; the protocols line should be preceded with
-        an "opt" until these Tors are obsolete.]
-
-   "allow-single-hop-exits"
-
-       [At most one.]
-
-       Present only if the router allows single-hop circuits to make exit
-       connections.  Most Tor servers do not support this: this is
-       included for specialized controllers designed to support perspective
-       access and such.
-
-
-2.2. Extra-info documents
-
-   Extra-info documents consist of the following items:
-
-    "extra-info" Nickname Fingerprint NL
-        [At start, exactly once.]
-
-        Identifies what router this is an extra info descriptor for.
-        Fingerprint is encoded in hex (using upper-case letters), with
-        no spaces.
-
-    "published"
-
-       [Exactly once.]
-
-       The time, in GMT, when this document (and its corresponding router
-       descriptor if any) was generated.  It MUST match the published time
-       in the corresponding router descriptor.
-
-    "read-history" YYYY-MM-DD HH:MM:SS (NSEC s) NUM,NUM,NUM,NUM,NUM... NL
-        [At most once.]
-    "write-history" YYYY-MM-DD HH:MM:SS (NSEC s) NUM,NUM,NUM,NUM,NUM... NL
-        [At most once.]
-
-        As documented in 2.1 above.  See migration notes in section 2.2.1.
-
-    "geoip-start" YYYY-MM-DD HH:MM:SS NL
-    "geoip-client-origins" CC=N,CC=N,... NL
-
-        Only generated by bridge routers (see blocking.pdf), and only
-        when they have been configured with a geoip database.
-        Non-bridges SHOULD NOT generate these fields.  Contains a list
-        of mappings from two-letter country codes (CC) to the number
-        of clients that have connected to that bridge from that
-        country (approximate, and rounded up to the nearest multiple of 8
-        in order to hamper traffic analysis).  A country is included
-        only if it has at least one address.  The time in
-        "geoip-start" is the time at which we began collecting geoip
-        statistics.
-
-    "router-signature" NL Signature NL
-        [At end, exactly once.]
-
-        A document signature as documented in section 1.3, using the
-        initial item "extra-info" and the final item "router-signature",
-        signed with the router's identity key.
-
-2.2.1. Moving history fields to extra-info documents.
-
-   Tools that want to use the read-history and write-history values SHOULD
-   download extra-info documents as well as router descriptors.  Such
-   tools SHOULD accept history values from both sources; if they appear in
-   both documents, the values in the extra-info documents are authoritative.
-
-   New versions of Tor no longer generate router descriptors
-   containing read-history or write-history.  Tools should continue to
-   accept read-history and write-history values in router descriptors
-   produced by older versions of Tor until all Tor versions earlier
-   than 0.2.0.x are obsolete.
-
-2.3. Nonterminals in router descriptors
-
-   nickname ::= between 1 and 19 alphanumeric characters ([A-Za-z0-9]),
-      case-insensitive.
-   hexdigest ::= a '$', followed by 40 hexadecimal characters
-      ([A-Fa-f0-9]). [Represents a server by the digest of its identity
-      key.]
-
-   exitpattern ::= addrspec ":" portspec
-   portspec ::= "*" | port | port "-" port
-   port ::= an integer between 1 and 65535, inclusive.
-
-      [Some implementations incorrectly generate ports with value 0.
-       Implementations SHOULD accept this, and SHOULD NOT generate it.
-       Connections to port 0 are never permitted.]
-
-   addrspec ::= "*" | ip4spec | ip6spec
-   ipv4spec ::= ip4 | ip4 "/" num_ip4_bits | ip4 "/" ip4mask
-   ip4 ::= an IPv4 address in dotted-quad format
-   ip4mask ::= an IPv4 mask in dotted-quad format
-   num_ip4_bits ::= an integer between 0 and 32
-   ip6spec ::= ip6 | ip6 "/" num_ip6_bits
-   ip6 ::= an IPv6 address, surrounded by square brackets.
-   num_ip6_bits ::= an integer between 0 and 128
-
-   bool ::= "0" | "1"
-
-3. Formats produced by directory authorities.
-
-   Every authority has two keys used in this protocol: a signing key, and
-   an authority identity key.  (Authorities also have a router identity
-   key used in their role as a router and by earlier versions of the
-   directory protocol.)  The identity key is used from time to time to
-   sign new key certificates using new signing keys; it is very sensitive.
-   The signing key is used to sign key certificates and status documents.
-
-   There are three kinds of documents generated by directory authorities:
-
-     Key certificates
-     Status votes
-     Status consensuses
-
-   Each is discussed below.
-
-3.1. Key certificates
-
-   Key certificates consist of the following items:
-
-    "dir-key-certificate-version" version NL
-
-        [At start, exactly once.]
-
-        Determines the version of the key certificate.  MUST be "3" for
-        the protocol described in this document.  Implementations MUST
-        reject formats they don't understand.
-
-    "dir-address" IPPort NL
-        [At most once]
-
-        An IP:Port for this authority's directory port.
-
-    "fingerprint" fingerprint NL
-
-        [Exactly once.]
-
-        Hexadecimal encoding without spaces based on the authority's
-        identity key.
-
-    "dir-identity-key" NL a public key in PEM format
-
-        [Exactly once.]
-
-        The long-term authority identity key for this authority.  This key
-        SHOULD be at least 2048 bits long; it MUST NOT be shorter than
-        1024 bits.
-
-    "dir-key-published" YYYY-MM-DD HH:MM:SS NL
-
-        [Exactly once.]
-
-        The time (in GMT) when this document and corresponding key were
-        last generated.
-
-    "dir-key-expires" YYYY-MM-DD HH:MM:SS NL
-
-        [Exactly once.]
-
-        A time (in GMT) after which this key is no longer valid.
-
-    "dir-signing-key" NL a key in PEM format
-
-        [Exactly once.]
-
-        The directory server's public signing key.  This key MUST be at
-        least 1024 bits, and MAY be longer.
-
-    "dir-key-crosscert" NL CrossSignature NL
-
-        [At most once.]
-
-        NOTE: Authorities MUST include this field in all newly generated
-        certificates.  A future version of this specification will make
-        the field required.
-
-        CrossSignature is a signature, made using the certificate's signing
-        key, of the digest of the PKCS1-padded hash of the certificate's
-        identity key.  For backward compatibility with broken versions of the
-        parser, we wrap the base64-encoded signature in -----BEGIN ID
-        SIGNATURE---- and -----END ID SIGNATURE----- tags.  Implementations
-        MUST allow the "ID " portion to be omitted, however.
-
-        When encountering a certificate with a dir-key-crosscert entry,
-        implementations MUST verify that the signature is a correct signature
-        of the hash of the identity key using the signing key.
-
-    "dir-key-certification" NL Signature NL
-
-        [At end, exactly once.]
-
-        A document signature as documented in section 1.3, using the
-        initial item "dir-key-certificate-version" and the final item
-        "dir-key-certification", signed with the authority identity key.
-
-   Authorities MUST generate a new signing key and corresponding
-   certificate before the key expires.
-
-3.2. Vote and consensus status documents
-
-   Votes and consensuses are more strictly formatted then other documents
-   in this specification, since different authorities must be able to
-   generate exactly the same consensus given the same set of votes.
-
-   The procedure for deciding when to generate vote and consensus status
-   documents are described in section XXX below.
-
-   Status documents contain a preamble, an authority section, a list of
-   router status entries, and one more footers signature, in that order.
-
-   Unlike other formats described above, a SP in these documents must be a
-   single space character (hex 20).
-
-   Some items appear only in votes, and some items appear only in
-   consensuses.  Unless specified, items occur in both.
-
-   The preamble contains the following items.  They MUST occur in the
-   order given here:
-
-    "network-status-version" SP version NL.
-
-        [At start, exactly once.]
-
-        A document format version.  For this specification, the version is
-        "3".
-
-    "vote-status" SP type NL
-
-        [Exactly once.]
-
-        The status MUST be "vote" or "consensus", depending on the type of
-        the document.
-
-    "consensus-methods" SP IntegerList NL
-
-        [Exactly once for votes; does not occur in consensuses.]
-
-        A space-separated list of supported methods for generating
-        consensuses from votes.  See section 3.4.1 for details.  Method "1"
-        MUST be included.
-
-    "consensus-method" SP Integer NL
-
-        [Exactly once for consensuses; does not occur in votes.]
-
-        See section 3.4.1 for details.
-
-        (Only included when the vote is generated with consensus-method 2 or
-        later.)
-
-    "published" SP YYYY-MM-DD SP HH:MM:SS NL
-
-        [Exactly once for votes; does not occur in consensuses.]
-
-        The publication time for this status document (if a vote).
-
-    "valid-after" SP YYYY-MM-DD SP HH:MM:SS NL
-
-        [Exactly once.]
-
-        The start of the Interval for this vote.  Before this time, the
-        consensus document produced from this vote should not be used.
-        See 1.4 for voting timeline information.
-
-    "fresh-until" SP YYYY-MM-DD SP HH:MM:SS NL
-
-        [Exactly once.]
-
-        The time at which the next consensus should be produced; before this
-        time, there is no point in downloading another consensus, since there
-        won't be a new one.  See 1.4 for voting timeline information.
-
-    "valid-until" SP YYYY-MM-DD SP HH:MM:SS NL
-
-        [Exactly once.]
-
-        The end of the Interval for this vote.  After this time, the
-        consensus produced by this vote should not be used.  See 1.4 for
-        voting timeline information.
-
-    "voting-delay" SP VoteSeconds SP DistSeconds NL
-
-        [Exactly once.]
-
-        VoteSeconds is the number of seconds that we will allow to collect
-        votes from all authorities; DistSeconds is the number of seconds
-        we'll allow to collect signatures from all authorities. See 1.4 for
-        voting timeline information.
-
-    "client-versions" SP VersionList NL
-
-        [At most once.]
-
-        A comma-separated list of recommended client versions, in
-        ascending order.  If absent, no opinion is held about client
-        versions.
-
-    "server-versions" SP VersionList NL
-
-        [At most once.]
-
-        A comma-separated list of recommended server versions, in
-        ascending order.  If absent, no opinion is held about server
-        versions.
-
-    "known-flags" SP FlagList NL
-
-        [Exactly once.]
-
-        A space-separated list of all of the flags that this document
-        might contain.  A flag is "known" either because the authority
-        knows about them and might set them (if in a vote), or because
-        enough votes were counted for the consensus for an authoritative
-        opinion to have been formed about their status.
-
-
-   The authority section of a vote contains the following items, followed
-   in turn by the authority's current key certificate:
-
-    "dir-source" SP nickname SP identity SP address SP IP SP dirport SP
-       orport NL
-
-        [Exactly once, at start]
-
-        Describes this authority.  The nickname is a convenient identifier
-        for the authority.  The identity is an uppercase hex fingerprint of
-        the authority's current (v3 authority) identity key.  The address is
-        the server's hostname.  The IP is the server's current IP address,
-        and dirport is its current directory port. XXXXorport
-
-    "contact" SP string NL
-
-        [At most once.]
-
-        An arbitrary string describing how to contact the directory
-        server's administrator.  Administrators should include at least an
-        email address and a PGP fingerprint.
-
-    "legacy-key" SP FINGERPRINT NL
-
-        [At most once]
-
-        Lists a fingerprint for an obsolete _identity_ key still used
-        by this authority to keep older clients working.  This option
-        is used to keep key around for a little while in case the
-        authorities need to migrate many identity keys at once.
-        (Generally, this would only happen because of a security
-        vulnerability that affected multiple authorities, like the
-        Debian OpenSSL RNG bug of May 2008.)
-
-   The authority section of a consensus contains groups the following items,
-   in the order given, with one group for each authority that contributed to
-   the consensus, with groups sorted by authority identity digest:
-
-    "dir-source" SP nickname SP identity SP address SP IP SP dirport SP
-       orport NL
-
-        [Exactly once, at start]
-
-        As in the authority section of a vote.
-
-    "contact" SP string NL
-
-        [At most once.]
-
-        As in the authority section of a vote.
-
-    "vote-digest" SP digest NL
-
-        [Exactly once.]
-
-        A digest of the vote from the authority that contributed to this
-        consensus, as signed (that is, not including the signature).
-        (Hex, upper-case.)
-
-   Each router status entry contains the following items.  Router status
-   entries are sorted in ascending order by identity digest.
-
-    "r" SP nickname SP identity SP digest SP publication SP IP SP ORPort
-        SP DirPort NL
-
-        [At start, exactly once.]
-
-        "Nickname" is the OR's nickname.  "Identity" is a hash of its
-        identity key, encoded in base64, with trailing equals sign(s)
-        removed.  "Digest" is a hash of its most recent descriptor as
-        signed (that is, not including the signature), encoded in base64.
-        "Publication" is the
-        publication time of its most recent descriptor, in the form
-        YYYY-MM-DD HH:MM:SS, in GMT.  "IP" is its current IP address;
-        ORPort is its current OR port, "DirPort" is it's current directory
-        port, or "0" for "none".
-
-    "s" SP Flags NL
-
-        [At most once.]
-
-        A series of space-separated status flags, in alphabetical order.
-        Currently documented flags are:
-
-          "Authority" if the router is a directory authority.
-          "BadExit" if the router is believed to be useless as an exit node
-             (because its ISP censors it, because it is behind a restrictive
-             proxy, or for some similar reason).
-          "BadDirectory" if the router is believed to be useless as a
-             directory cache (because its directory port isn't working,
-             its bandwidth is always throttled, or for some similar
-             reason).
-          "Exit" if the router is more useful for building
-             general-purpose exit circuits than for relay circuits.  The
-             path building algorithm uses this flag; see path-spec.txt.
-          "Fast" if the router is suitable for high-bandwidth circuits.
-          "Guard" if the router is suitable for use as an entry guard.
-          "HSDir" if the router is considered a v2 hidden service directory.
-          "Named" if the router's identity-nickname mapping is canonical,
-             and this authority binds names.
-          "Stable" if the router is suitable for long-lived circuits.
-          "Running" if the router is currently usable.
-          "Unnamed" if another router has bound the name used by this
-             router, and this authority binds names.
-          "Valid" if the router has been 'validated'.
-          "V2Dir" if the router implements the v2 directory protocol.
-          "V3Dir" if the router implements this protocol.
-
-    "v" SP version NL
-
-        [At most once.]
-
-        The version of the Tor protocol that this server is running.  If
-        the value begins with "Tor" SP, the rest of the string is a Tor
-        version number, and the protocol is "The Tor protocol as supported
-        by the given version of Tor."  Otherwise, if the value begins with
-        some other string, Tor has upgraded to a more sophisticated
-        protocol versioning system, and the protocol is "a version of the
-        Tor protocol more recent than any we recognize."
-
-        Directory authorities SHOULD omit version strings they receive from
-        descriptors if they would cause "v" lines to be over 128 characters
-        long.
-
-    "w" SP "Bandwidth=" INT NL
-
-        [At most once.]
-
-        An estimate of the bandwidth of this server, in an arbitrary
-        unit (currently kilobytes per second).  Used to weight router
-        selection.  Other weighting keywords may be added later.
-        Clients MUST ignore keywords they do not recognize.
-
-    "p" SP ("accept" / "reject") SP PortList NL
-
-        [At most once.]
-
-        PortList = PortOrRange
-        PortList = PortList "," PortOrRange
-        PortOrRange = INT "-" INT / INT
-
-        A list of those ports that this router supports (if 'accept')
-        or does not support (if 'reject') for exit to "most
-        addresses".
-
-   The signature section contains the following item, which appears
-   Exactly Once for a vote, and At Least Once for a consensus.
-
-    "directory-signature" SP identity SP signing-key-digest NL Signature
-
-        This is a signature of the status document, with the initial item
-        "network-status-version", and the signature item
-        "directory-signature", using the signing key.  (In this case, we take
-        the hash through the _space_ after directory-signature, not the
-        newline: this ensures that all authorities sign the same thing.)
-        "identity" is the hex-encoded digest of the authority identity key of
-        the signing authority, and "signing-key-digest" is the hex-encoded
-        digest of the current authority signing key of the signing authority.
-
-3.3. Deciding how to vote.
-
-   (This section describes how directory authorities choose which status
-   flags to apply to routers, as of Tor 0.2.0.0-alpha-dev. Later directory
-   authorities MAY do things differently, so long as clients keep working
-   well.  Clients MUST NOT depend on the exact behaviors in this section.)
-
-   In the below definitions, a router is considered "active" if it is
-   running, valid, and not hibernating.
-
-   "Valid" -- a router is 'Valid' if it is running a version of Tor not
-   known to be broken, and the directory authority has not blacklisted
-   it as suspicious.
-
-   "Named" -- Directory authority administrators may decide to support name
-   binding.  If they do, then they must maintain a file of
-   nickname-to-identity-key mappings, and try to keep this file consistent
-   with other directory authorities.  If they don't, they act as clients, and
-   report bindings made by other directory authorities (name X is bound to
-   identity Y if at least one binding directory lists it, and no directory
-   binds X to some other Y'.)  A router is called 'Named' if the router
-   believes the given name should be bound to the given key.
-
-        Two strategies exist on the current network for deciding on
-        values for the Named flag.  In the original version, server
-        operators were asked to send nickname-identity pairs to a
-        mailing list of Naming directory authorities operators.  The
-        operators were then supposed to add the pairs to their
-        mapping files; in practice, they didn't get to this often.
-
-        Newer Naming authorities run a script that registers routers
-        in their mapping files once the routers have been online at
-        least two weeks, no other router has that nickname, and no
-        other router has wanted the nickname for a month.  If a router
-        has not been online for six months, the router is removed.
-
-   "Unnamed" -- Directory authorities that support naming should vote for a
-   router to be 'Unnamed' if its given nickname is mapped to a different
-   identity.
-
-   "Running" -- A router is 'Running' if the authority managed to connect to
-   it successfully within the last 30 minutes.
-
-   "Stable" -- A router is 'Stable' if it is active, and either its Weighted
-   MTBF is at least the median for known active routers or its Weighted MTBF
-   corresponds to at least 7 days. Routers are never called Stable if they are
-   running a version of Tor known to drop circuits stupidly.  (0.1.1.10-alpha
-   through 0.1.1.16-rc are stupid this way.)
-
-        To calculate weighted MTBF, compute the weighted mean of the lengths
-        of all intervals when the router was observed to be up, weighting
-        intervals by $\alpha^n$, where $n$ is the amount of time that has
-        passed since the interval ended, and $\alpha$ is chosen so that
-        measurements over approximately one month old no longer influence the
-        weighted MTBF much.
-
-        [XXXX what happens when we have less than 4 days of MTBF info.]
-
-   "Exit" -- A router is called an 'Exit' iff it allows exits to at
-    least two of the ports 80, 443, and 6667 and allows exits to at
-    least one /8 address space.
-
-   "Fast" -- A router is 'Fast' if it is active, and its bandwidth is
-   either in the top 7/8ths for known active routers or at least 100KB/s.
-
-   "Guard" -- A router is a possible 'Guard' if its Weighted Fractional
-   Uptime is at least the median for "familiar" active routers, and if
-   its bandwidth is at least median or at least 250KB/s.
-   If the total bandwidth of active non-BadExit Exit servers is less
-   than one third of the total bandwidth of all active servers, no Exit is
-   listed as a Guard.
-
-        To calculate weighted fractional uptime, compute the fraction
-        of time that the router is up in any given day, weighting so that
-        downtime and uptime in the past counts less.
-
-        A node is 'familiar' if 1/8 of all active nodes have appeared more
-        recently than it, OR it has been around for a few weeks.
-
-   "Authority" -- A router is called an 'Authority' if the authority
-   generating the network-status document believes it is an authority.
-
-   "V2Dir" -- A router supports the v2 directory protocol if it has an open
-   directory port, and it is running a version of the directory protocol that
-   supports the functionality clients need.  (Currently, this is
-   0.1.1.9-alpha or later.)
-
-   "V3Dir" -- A router supports the v3 directory protocol if it has an open
-   directory port, and it is running a version of the directory protocol that
-   supports the functionality clients need.  (Currently, this is
-   0.2.0.?????-alpha or later.)
-
-   "HSDir" -- A router is a v2 hidden service directory if it stores and
-   serves v2 hidden service descriptors and the authority managed to connect
-   to it successfully within the last 24 hours.
-
-   Directory server administrators may label some servers or IPs as
-   blacklisted, and elect not to include them in their network-status lists.
-
-   Authorities SHOULD 'disable' any servers in excess of 3 on any single IP.
-   When there are more than 3 to choose from, authorities should first prefer
-   authorities to non-authorities, then prefer Running to non-Running, and
-   then prefer high-bandwidth to low-bandwidth.  To 'disable' a server, the
-   authority *should* advertise it without the Running or Valid flag.
-
-   Thus, the network-status vote includes all non-blacklisted,
-   non-expired, non-superseded descriptors.
-
-   The bandwidth in a "w" line should be taken as the best estimate
-   of the router's actual capacity that the authority has.  For now,
-   this should be the lesser of the observed bandwidth and bandwidth
-   rate limit from the router descriptor.  It is given in kilobytes
-   per second, and capped at some arbitrary value (currently 10 MB/s).
-
-   The ports listed in a "p" line should be taken as those ports for
-   which the router's exit policy permits 'most' addresses, ignoring any
-   accept not for all addresses, ignoring all rejects for private
-   netblocks.  "Most" addresses are permitted if no more than 2^25
-   IPv4 addresses (two /8 networks) were blocked.  The list is encoded
-   as described in 3.4.2.
-
-3.4. Computing a consensus from a set of votes
-
-   Given a set of votes, authorities compute the contents of the consensus
-   document as follows:
-
-     The "valid-after", "valid-until", and "fresh-until" times are taken as
-     the median of the respective values from all the votes.
-
-     The times in the "voting-delay" line are taken as the median of the
-     VoteSeconds and DistSeconds times in the votes.
-
-     Known-flags is the union of all flags known by any voter.
-
-    "client-versions" and "server-versions" are sorted in ascending
-     order; A version is recommended in the consensus if it is recommended
-     by more than half of the voting authorities that included a
-     client-versions or server-versions lines in their votes.
-
-     The authority item groups (dir-source, contact, fingerprint,
-     vote-digest) are taken from the votes of the voting
-     authorities. These groups are sorted by the digests of the
-     authorities identity keys, in ascending order.  If the consensus
-     method is 3 or later, a dir-source line must be included for
-     every vote with legacy-key entry, using the legacy-key's
-     fingerprint, the voter's ordinary nickname with the string
-     "-legacy" appended, and all other fields as from the original
-     vote's dir-source line.
-
-     A router status entry:
-        * is included in the result if some router status entry with the same
-          identity is included by more than half of the authorities (total
-          authorities, not just those whose votes we have).
-
-        * For any given identity, we include at most one router status entry.
-
-        * A router entry has a flag set if that is included by more than half
-          of the authorities who care about that flag.
-
-        * Two router entries are "the same" if they have the same
-          <descriptor digest, published time, nickname, IP, ports> tuple.
-          We choose the tuple for a given router as whichever tuple appears
-          for that router in the most votes.  We break ties first in favor of
-          the more recently published, then in favor of smaller server
-          descriptor digest.
-
-        * The Named flag appears if it is included for this routerstatus by
-          _any_ authority, and if all authorities that list it list the same
-          nickname. However, if consensus-method 2 or later is in use, and
-          any authority calls this identity/nickname pair Unnamed, then
-          this routerstatus does not get the Named flag.
-
-        * If consensus-method 2 or later is in use, the Unnamed flag is
-          set for a routerstatus if any authorities have voted for a different
-          identities to be Named with that nickname, or if any authority
-          lists that nickname/ID pair as Unnamed.
-
-          (With consensus-method 1, Unnamed is set like any other flag.)
-
-        * The version is given as whichever version is listed by the most
-          voters, with ties decided in favor of more recent versions.
-
-        * If consensus-method 4 or later is in use, then routers that
-          do not have the Running flag are not listed at all.
-
-        * If consensus-method 5 or later is in use, then the "w" line
-          is generated using a low-median of the bandwidth values from
-          the votes that included "w" lines for this router.
-
-        * If consensus-method 5 or later is in use, then the "p" line
-          is taken from the votes that have the same policy summary
-          for the descriptor we are listing.  (They should all be the
-          same.  If they are not, we pick the most commonly listed
-          one, breaking ties in favor of the lexicographically larger
-          vote.)  The port list is encoded as specified in 3.4.2.
-
-     The signatures at the end of a consensus document are sorted in
-     ascending order by identity digest.
-
-   All ties in computing medians are broken in favor of the smaller or
-   earlier item.
-
-3.4.1. Forward compatibility
-
-   Future versions of Tor will need to include new information in the
-   consensus documents, but it is important that all authorities (or at least
-   half) generate and sign the same signed consensus.
-
-   To achieve this, authorities list in their votes their supported methods
-   for generating consensuses from votes.  Later methods will be assigned
-   higher numbers.  Currently recognized methods:
-     "1" -- The first implemented version.
-     "2" -- Added support for the Unnamed flag.
-     "3" -- Added legacy ID key support to aid in authority ID key rollovers
-     "4" -- No longer list routers that are not running in the consensus
-     "5" -- adds support for "w" and "p" lines.
-
-   Before generating a consensus, an authority must decide which consensus
-   method to use.  To do this, it looks for the highest version number
-   supported by more than 2/3 of the authorities voting.  If it supports this
-   method, then it uses it.  Otherwise, it falls back to method 1.
-
-   (The consensuses generated by new methods must be parsable by
-   implementations that only understand the old methods, and must not cause
-   those implementations to compromise their anonymity.  This is a means for
-   making changes in the contents of consensus; not for making
-   backward-incompatible changes in their format.)
-
-3.4.2. Encoding port lists
-
-  Whether the summary shows the list of accepted ports or the list of
-  rejected ports depends on which list is shorter (has a shorter string
-  representation).  In case of ties we choose the list of accepted
-  ports.  As an exception to this rule an allow-all policy is
-  represented as "accept 1-65535" instead of "reject " and a reject-all
-  policy is similarly given as "reject 1-65535".
-
-  Summary items are compressed, that is instead of "80-88,89-100" there
-  only is a single item of "80-100", similarly instead of "20,21" a
-  summary will say "20-21".
-
-  Port lists are sorted in ascending order.
-
-  The maximum allowed length of a policy summary (including the "accept "
-  or "reject ") is 1000 characters.  If a summary exceeds that length we
-  use an accept-style summary and list as much of the port list as is
-  possible within these 1000 bytes.  [XXXX be more specific.]
-
-3.5. Detached signatures
-
-   Assuming full connectivity, every authority should compute and sign the
-   same consensus directory in each period.  Therefore, it isn't necessary to
-   download the consensus computed by each authority; instead, the
-   authorities only push/fetch each others' signatures.  A "detached
-   signature" document contains items as follows:
-
-    "consensus-digest" SP Digest NL
-
-        [At start, at most once.]
-
-        The digest of the consensus being signed.
-
-    "valid-after" SP YYYY-MM-DD SP HH:MM:SS NL
-    "fresh-until" SP YYYY-MM-DD SP HH:MM:SS NL
-    "valid-until" SP YYYY-MM-DD SP HH:MM:SS NL
-
-        [As in the consensus]
-
-    "directory-signature"
-
-        [As in the consensus; the signature object is the same as in the
-        consensus document.]
-
-
-4. Directory server operation
-
-   All directory authorities and directory caches ("directory servers")
-   implement this section, except as noted.
-
-4.1. Accepting uploads (authorities only)
-
-   When a router posts a signed descriptor to a directory authority, the
-   authority first checks whether it is well-formed and correctly
-   self-signed.  If it is, the authority next verifies that the nickname
-   in question is not already assigned to a router with a different
-   public key.
-   Finally, the authority MAY check that the router is not blacklisted
-   because of its key, IP, or another reason.
-
-   If the descriptor passes these tests, and the authority does not already
-   have a descriptor for a router with this public key, it accepts the
-   descriptor and remembers it.
-
-   If the authority _does_ have a descriptor with the same public key, the
-   newly uploaded descriptor is remembered if its publication time is more
-   recent than the most recent old descriptor for that router, and either:
-      - There are non-cosmetic differences between the old descriptor and the
-        new one.
-      - Enough time has passed between the descriptors' publication times.
-        (Currently, 12 hours.)
-
-   Differences between router descriptors are "non-cosmetic" if they would be
-   sufficient to force an upload as described in section 2 above.
-
-   Note that the "cosmetic difference" test only applies to uploaded
-   descriptors, not to descriptors that the authority downloads from other
-   authorities.
-
-   When a router posts a signed extra-info document to a directory authority,
-   the authority again checks it for well-formedness and correct signature,
-   and checks that its matches the extra-info-digest in some router
-   descriptor that it believes is currently useful.  If so, it accepts it and
-   stores it and serves it as requested.  If not, it drops it.
-
-4.2. Voting (authorities only)
-
-   Authorities divide time into Intervals.  Authority administrators SHOULD
-   try to all pick the same interval length, and SHOULD pick intervals that
-   are commonly used divisions of time (e.g., 5 minutes, 15 minutes, 30
-   minutes, 60 minutes, 90 minutes).  Voting intervals SHOULD be chosen to
-   divide evenly into a 24-hour day.
-
-   Authorities SHOULD act according to interval and delays in the
-   latest consensus.  Lacking a latest consensus, they SHOULD default to a
-   30-minute Interval, a 5 minute VotingDelay, and a 5 minute DistDelay.
-
-   Authorities MUST take pains to ensure that their clocks remain accurate
-   within a few seconds.  (Running NTP is usually sufficient.)
-
-   The first voting period of each day begins at 00:00 (midnight) GMT.  If
-   the last period of the day would be truncated by one-half or more, it is
-   merged with the second-to-last period.
-
-   An authority SHOULD publish its vote immediately at the start of each voting
-   period (minus VoteSeconds+DistSeconds).  It does this by making it
-   available at
-     http://<hostname>/tor/status-vote/next/authority.z
-   and sending it in an HTTP POST request to each other authority at the URL
-     http://<hostname>/tor/post/vote
-
-   If, at the start of the voting period, minus DistSeconds, an authority
-   does not have a current statement from another authority, the first
-   authority downloads the other's statement.
-
-   Once an authority has a vote from another authority, it makes it available
-   at
-      http://<hostname>/tor/status-vote/next/<fp>.z
-   where <fp> is the fingerprint of the other authority's identity key.
-   And at
-      http://<hostname>/tor/status-vote/next/d/<d>.z
-   where <d> is the digest of the vote document.
-
-   The consensus status, along with as many signatures as the server
-   currently knows, should be available at
-      http://<hostname>/tor/status-vote/next/consensus.z
-   All of the detached signatures it knows for consensus status should be
-   available at:
-      http://<hostname>/tor/status-vote/next/consensus-signatures.z
-
-   Once there are enough signatures, or once the voting period starts,
-   these documents are available at
-      http://<hostname>/tor/status-vote/current/consensus.z
-   and
-      http://<hostname>/tor/status-vote/current/consensus-signatures.z
-   [XXX current/consensus-signatures is not currently implemented, as it
-    is not used in the voting protocol.]
-
-   The other vote documents are analogously made available under
-     http://<hostname>/tor/status-vote/current/authority.z
-     http://<hostname>/tor/status-vote/current/<fp>.z
-     http://<hostname>/tor/status-vote/current/d/<d>.z
-   once the consensus is complete.
-
-   Once an authority has computed and signed a consensus network status, it
-   should send its detached signature to each other authority in an HTTP POST
-   request to the URL:
-      http://<hostname>/tor/post/consensus-signature
-
-   [XXX Note why we support push-and-then-pull.]
-
-   [XXX possible future features include support for downloading old
-    consensuses.]
-
-4.3. Downloading consensus status documents (caches only)
-
-   All directory servers (authorities and caches) try to keep a recent
-   network-status consensus document to serve to clients.  A cache ALWAYS
-   downloads a network-status consensus if any of the following are true:
-     - The cache has no consensus document.
-     - The cache's consensus document is no longer valid.
-   Otherwise, the cache downloads a new consensus document at a randomly
-   chosen time in the first half-interval after its current consensus
-   stops being fresh.  (This time is chosen at random to avoid swarming
-   the authorities at the start of each period.  The interval size is
-   inferred from the difference between the valid-after time and the
-   fresh-until time on the consensus.)
-
-   [For example, if a cache has a consensus that became valid at 1:00,
-    and is fresh until 2:00, that cache will fetch a new consensus at
-    a random time between 2:00 and 2:30.]
-
-4.4. Downloading and storing router descriptors (authorities and caches)
-
-   Periodically (currently, every 10 seconds), directory servers check
-   whether there are any specific descriptors that they do not have and that
-   they are not currently trying to download.  Caches identify these
-   descriptors by hash in the recent network-status consensus documents;
-   authorities identify them by hash in vote (if publication date is more
-   recent than the descriptor we currently have).
-
- [XXXX need a way to fetch descriptors ahead of the vote?  v2 status docs can
- do that for now.]
-
-   If so, the directory server launches requests to the authorities for these
-   descriptors, such that each authority is only asked for descriptors listed
-   in its most recent vote (if the requester is an authority) or in the
-   consensus (if the requester is a cache).  If we're an authority, and more
-   than one authority lists the descriptor, we choose which to ask at random.
-
-   If one of these downloads fails, we do not try to download that descriptor
-   from the authority that failed to serve it again unless we receive a newer
-   network-status (consensus or vote) from that authority that lists the same
-   descriptor.
-
-   Directory servers must potentially cache multiple descriptors for each
-   router. Servers must not discard any descriptor listed by any recent
-   consensus.  If there is enough space to store additional descriptors,
-   servers SHOULD try to hold those which clients are likely to download the
-   most.  (Currently, this is judged based on the interval for which each
-   descriptor seemed newest.)
-[XXXX define recent]
-
-   Authorities SHOULD NOT download descriptors for routers that they would
-   immediately reject for reasons listed in 3.1.
-
-4.5. Downloading and storing extra-info documents
-
-   All authorities, and any cache that chooses to cache extra-info documents,
-   and any client that uses extra-info documents, should implement this
-   section.
-
-   Note that generally, clients don't need extra-info documents.
-
-   Periodically, the Tor instance checks whether it is missing any extra-info
-   documents: in other words, if it has any router descriptors with an
-   extra-info-digest field that does not match any of the extra-info
-   documents currently held.  If so, it downloads whatever extra-info
-   documents are missing.  Caches download from authorities; non-caches try
-   to download from caches.  We follow the same splitting and back-off rules
-   as in 4.4 (if a cache) or 5.3 (if a client).
-
-4.6. General-use HTTP URLs
-
-   "Fingerprints" in these URLs are base-16-encoded SHA1 hashes.
-
-   The most recent v3 consensus should be available at:
-      http://<hostname>/tor/status-vote/current/consensus.z
-
-   Starting with Tor version 0.2.1.1-alpha is also available at:
-      http://<hostname>/tor/status-vote/current/consensus/<F1>+<F2>+<F3>.z
-
-   Where F1, F2, etc. are authority identity fingerprints the client trusts.
-   Servers will only return a consensus if more than half of the requested
-   authorities have signed the document, otherwise a 404 error will be sent
-   back.  The fingerprints can be shortened to a length of any multiple of
-   two, using only the leftmost part of the encoded fingerprint.  Tor uses
-   3 bytes (6 hex characters) of the fingerprint.
-
-   Clients SHOULD sort the fingerprints in ascending order.  Server MUST
-   accept any order.
-
-   Clients SHOULD use this format when requesting consensus documents from
-   directory authority servers and from caches running a version of Tor
-   that is known to support this URL format.
-
-   A concatenated set of all the current key certificates should be available
-   at:
-      http://<hostname>/tor/keys/all.z
-
-   The key certificate for this server (if it is an authority) should be
-   available at:
-      http://<hostname>/tor/keys/authority.z
-
-   The key certificate for an authority whose authority identity fingerprint
-   is <F> should be available at:
-      http://<hostname>/tor/keys/fp/<F>.z
-
-   The key certificate whose signing key fingerprint is <F> should be
-   available at:
-      http://<hostname>/tor/keys/sk/<F>.z
-
-   The key certificate whose identity key fingerprint is <F> and whose signing
-   key fingerprint is <S> should be available at:
-
-      http://<hostname>/tor/keys/fp-sk/<F>-<S>.z
-
-   (As usual, clients may request multiple certificates using:
-       http://<hostname>/tor/keys/fp-sk/<F1>-<S1>+<F2>-<S2>.z  )
-   [The above fp-sk format was not supported before Tor 0.2.1.9-alpha.]
-
-   The most recent descriptor for a server whose identity key has a
-   fingerprint of <F> should be available at:
-      http://<hostname>/tor/server/fp/<F>.z
-
-   The most recent descriptors for servers with identity fingerprints
-   <F1>,<F2>,<F3> should be available at:
-      http://<hostname>/tor/server/fp/<F1>+<F2>+<F3>.z
-
-   (NOTE: Implementations SHOULD NOT download descriptors by identity key
-   fingerprint. This allows a corrupted server (in collusion with a cache) to
-   provide a unique descriptor to a client, and thereby partition that client
-   from the rest of the network.)
-
-   The server descriptor with (descriptor) digest <D> (in hex) should be
-   available at:
-      http://<hostname>/tor/server/d/<D>.z
-
-   The most recent descriptors with digests <D1>,<D2>,<D3> should be
-   available at:
-      http://<hostname>/tor/server/d/<D1>+<D2>+<D3>.z
-
-   The most recent descriptor for this server should be at:
-      http://<hostname>/tor/server/authority.z
-    [Nothing in the Tor protocol uses this resource yet, but it is useful
-     for debugging purposes. Also, the official Tor implementations
-     (starting at 0.1.1.x) use this resource to test whether a server's
-     own DirPort is reachable.]
-
-   A concatenated set of the most recent descriptors for all known servers
-   should be available at:
-      http://<hostname>/tor/server/all.z
-
-   Extra-info documents are available at the URLS
-      http://<hostname>/tor/extra/d/...
-      http://<hostname>/tor/extra/fp/...
-      http://<hostname>/tor/extra/all[.z]
-      http://<hostname>/tor/extra/authority[.z]
-         (As for /tor/server/ URLs: supports fetching extra-info
-         documents by their digest, by the fingerprint of their servers,
-         or all at once. When serving by fingerprint, we serve the
-         extra-info that corresponds to the descriptor we would serve by
-         that fingerprint. Only directory authorities of version
-         0.2.0.1-alpha or later are guaranteed to support the first
-         three classes of URLs.  Caches may support them, and MUST
-         support them if they have advertised "caches-extra-info".)
-
-   For debugging, directories SHOULD expose non-compressed objects at URLs like
-   the above, but without the final ".z".
-   Clients MUST handle compressed concatenated information in two forms:
-     - A concatenated list of zlib-compressed objects.
-     - A zlib-compressed concatenated list of objects.
-   Directory servers MAY generate either format: the former requires less
-   CPU, but the latter requires less bandwidth.
-
-   Clients SHOULD use upper case letters (A-F) when base16-encoding
-   fingerprints.  Servers MUST accept both upper and lower case fingerprints
-   in requests.
-
-5. Client operation: downloading information
-
-   Every Tor that is not a directory server (that is, those that do
-   not have a DirPort set) implements this section.
-
-5.1. Downloading network-status documents
-
-   Each client maintains a list of directory authorities.  Insofar as
-   possible, clients SHOULD all use the same list.
-
-   Clients try to have a live consensus network-status document at all times.
-   A network-status document is "live" if the time in its valid-until field
-   has not passed.
-
-   If a client is missing a live network-status document, it tries to fetch
-   it from a directory cache (or from an authority if it knows no caches).
-   On failure, the client waits briefly, then tries that network-status
-   document again from another cache.  The client does not build circuits
-   until it has a live network-status consensus document, and it has
-   descriptors for more than 1/4 of the routers that it believes are running.
-
-   (Note: clients can and should pick caches based on the network-status
-   information they have: once they have first fetched network-status info
-   from an authority, they should not need to go to the authority directly
-   again.)
-
-   To avoid swarming the caches whenever a consensus expires, the
-   clients download new consensuses at a randomly chosen time after the
-   caches are expected to have a fresh consensus, but before their
-   consensus will expire.  (This time is chosen uniformly at random from
-   the interval between the time 3/4 into the first interval after the
-   consensus is no longer fresh, and 7/8 of the time remaining after
-   that before the consensus is invalid.)
-
-   [For example, if a cache has a consensus that became valid at 1:00,
-    and is fresh until 2:00, and expires at 4:00, that cache will fetch
-    a new consensus at a random time between 2:45 and 3:50, since 3/4
-    of the one-hour interval is 45 minutes, and 7/8 of the remaining 75
-    minutes is 65 minutes.]
-
-5.2. Downloading and storing router descriptors
-
-   Clients try to have the best descriptor for each router.  A descriptor is
-   "best" if:
-      * It is listed in the consensus network-status document.
-
-   Periodically (currently every 10 seconds) clients check whether there are
-   any "downloadable" descriptors.  A descriptor is downloadable if:
-      - It is the "best" descriptor for some router.
-      - The descriptor was published at least 10 minutes in the past.
-        (This prevents clients from trying to fetch descriptors that the
-        mirrors have probably not yet retrieved and cached.)
-      - The client does not currently have it.
-      - The client is not currently trying to download it.
-      - The client would not discard it immediately upon receiving it.
-      - The client thinks it is running and valid (see 6.1 below).
-
-   If at least 16 known routers have downloadable descriptors, or if
-   enough time (currently 10 minutes) has passed since the last time the
-   client tried to download descriptors, it launches requests for all
-   downloadable descriptors, as described in 5.3 below.
-
-   When a descriptor download fails, the client notes it, and does not
-   consider the descriptor downloadable again until a certain amount of time
-   has passed. (Currently 0 seconds for the first failure, 60 seconds for the
-   second, 5 minutes for the third, 10 minutes for the fourth, and 1 day
-   thereafter.)  Periodically (currently once an hour) clients reset the
-   failure count.
-
-   Clients retain the most recent descriptor they have downloaded for each
-   router so long as it is not too old (currently, 48 hours), OR so long as
-   no better descriptor has been downloaded for the same router.
-
-   [Versions of Tor before 0.1.2.3-alpha would discard descriptors simply for
-   being published too far in the past.]  [The code seems to discard
-   descriptors in all cases after they're 5 days old. True? -RD]
-
-5.3. Managing downloads
-
-   When a client has no consensus network-status document, it downloads it
-   from a randomly chosen authority.  In all other cases, the client
-   downloads from caches randomly chosen from among those believed to be V2
-   directory servers.  (This information comes from the network-status
-   documents; see 6 below.)
-
-   When downloading multiple router descriptors, the client chooses multiple
-   mirrors so that:
-     - At least 3 different mirrors are used, except when this would result
-       in more than one request for under 4 descriptors.
-     - No more than 128 descriptors are requested from a single mirror.
-     - Otherwise, as few mirrors as possible are used.
-   After choosing mirrors, the client divides the descriptors among them
-   randomly.
-
-   After receiving any response client MUST discard any network-status
-   documents and descriptors that it did not request.
-
-6. Using directory information
-
-   Everyone besides directory authorities uses the approaches in this section
-   to decide which servers to use and what their keys are likely to be.
-   (Directory authorities just believe their own opinions, as in 3.1 above.)
-
-6.1. Choosing routers for circuits.
-
-   Circuits SHOULD NOT be built until the client has enough directory
-   information: a live consensus network status [XXXX fallback?]  and
-   descriptors for at least 1/4 of the servers believed to be running.
-
-   A server is "listed" if it is included by the consensus network-status
-   document.  Clients SHOULD NOT use unlisted servers.
-
-   These flags are used as follows:
-
-     - Clients SHOULD NOT use non-'Valid' or non-'Running' routers unless
-       requested to do so.
-
-     - Clients SHOULD NOT use non-'Fast' routers for any purpose other than
-       very-low-bandwidth circuits (such as introduction circuits).
-
-     - Clients SHOULD NOT use non-'Stable' routers for circuits that are
-       likely to need to be open for a very long time (such as those used for
-       IRC or SSH connections).
-
-     - Clients SHOULD NOT choose non-'Guard' nodes when picking entry guard
-       nodes.
-
-     - Clients SHOULD NOT download directory information from non-'V2Dir'
-       caches.
-
-   See the "path-spec.txt" document for more details.
-
-6.2. Managing naming
-
-   In order to provide human-memorable names for individual server
-   identities, some directory servers bind names to IDs.  Clients handle
-   names in two ways:
-
-   When a client encounters a name it has not mapped before:
-
-      If the consensus lists any router with that name as "Named", or if
-      consensus-method 2 or later is in use and the consensus lists any
-      router with that name as having the "Unnamed" flag, then the name is
-      bound.  (It's bound to the ID listed in the entry with the Named,
-      or to an unknown ID if no name is found.)
-
-   When the user refers to a bound name, the implementation SHOULD provide
-   only the router with ID bound to that name, and no other router, even
-   if the router with the right ID can't be found.
-
-   When a user tries to refer to a non-bound name, the implementation SHOULD
-   warn the user. After warning the user, the implementation MAY use any
-   router that advertises the name.
-
-   Not every router needs a nickname.  When a router doesn't configure a
-   nickname, it publishes with the default nickname "Unnamed".  Authorities
-   SHOULD NOT ever mark a router with this nickname as Named; client software
-   SHOULD NOT ever use a router in response to a user request for a router
-   called "Unnamed".
-
-6.3. Software versions
-
-   An implementation of Tor SHOULD warn when it has fetched a consensus
-   network-status, and it is running a software version not listed.
-
-6.4. Warning about a router's status.
-
-   If a router tries to publish its descriptor to a Naming authority
-   that has its nickname mapped to another key, the router SHOULD
-   warn the operator that it is either using the wrong key or is using
-   an already claimed nickname.
-
-   If a router has fetched a consensus document,, and the
-   authorities do not publish a binding for the router's nickname, the
-   router MAY remind the operator that the chosen nickname is not
-   bound to this key at the authorities, and suggest contacting the
-   authority operators.
-
-   ...
-
-6.5. Router protocol versions
-
-   A client should believe that a router supports a given feature if that
-   feature is supported by the router or protocol versions in more than half
-   of the live networkstatuses' "v" entries for that router.  In other words,
-   if the "v" entries for some router are:
-       v Tor 0.0.8pre1                (from authority 1)
-       v Tor 0.1.2.11                 (from authority 2)
-       v FutureProtocolDescription 99 (from authority 3)
-   then the client should believe that the router supports any feature
-   supported by 0.1.2.11.
-
-   This is currently equivalent to believing the median declared version for
-   a router in all live networkstatuses.
-
-7. Standards compliance
-
-   All clients and servers MUST support HTTP 1.0.  Clients and servers MAY
-   support later versions of HTTP as well.
-
-7.1. HTTP headers
-
-  Servers MAY set the Content-Length: header.  Servers SHOULD set
-  Content-Encoding to "deflate" or "identity".
-
-  Servers MAY include an X-Your-Address-Is: header, whose value is the
-  apparent IP address of the client connecting to them (as a dotted quad).
-  For directory connections tunneled over a BEGIN_DIR stream, servers SHOULD
-  report the IP from which the circuit carrying the BEGIN_DIR stream reached
-  them.  [Servers before version 0.1.2.5-alpha reported 127.0.0.1 for all
-  BEGIN_DIR-tunneled connections.]
-
-  Servers SHOULD disable caching of multiple network statuses or multiple
-  router descriptors.  Servers MAY enable caching of single descriptors,
-  single network statuses, the list of all router descriptors, a v1
-  directory, or a v1 running routers document.  XXX mention times.
-
-7.2. HTTP status codes
-
-  Tor delivers the following status codes.  Some were chosen without much
-  thought; other code SHOULD NOT rely on specific status codes yet.
-
-  200 -- the operation completed successfully
-      -- the user requested statuses or serverdescs, and none of the ones we
-         requested were found (0.2.0.4-alpha and earlier).
-
-  304 -- the client specified an if-modified-since time, and none of the
-         requested resources have changed since that time.
-
-  400 -- the request is malformed, or
-      -- the URL is for a malformed variation of one of the URLs we support,
-          or
-      -- the client tried to post to a non-authority, or
-      -- the authority rejected a malformed posted document, or
-
-  404 -- the requested document was not found.
-      -- the user requested statuses or serverdescs, and none of the ones
-         requested were found (0.2.0.5-alpha and later).
-
-  503 -- we are declining the request in order to save bandwidth
-      -- user requested some items that we ordinarily generate or store,
-         but we do not have any available.
-
-9. Backward compatibility and migration plans
-
-  Until Tor versions before 0.1.1.x are completely obsolete, directory
-  authorities should generate, and mirrors should download and cache, v1
-  directories and running-routers lists, and allow old clients to download
-  them.  These documents and the rules for retrieving, serving, and caching
-  them are described in dir-spec-v1.txt.
-
-  Until Tor versions before 0.2.0.x are completely obsolete, directory
-  authorities should generate, mirrors should download and cache, v2
-  network-status documents, and allow old clients to download them.
-  Additionally, all directory servers and caches should download, store, and
-  serve any router descriptor that is required because of v2 network-status
-  documents. These documents and the rules for retrieving, serving, and
-  caching them are described in dir-spec-v1.txt.
-
-A. Consensus-negotiation timeline.
-
-
-   Period begins: this is the Published time.
-     Everybody sends votes
-   Reconciliation: everybody tries to fetch missing votes.
-     consensus may exist at this point.
-   End of voting period:
-     everyone swaps signatures.
-   Now it's okay for caches to download
-     Now it's okay for clients to download.
-
-   Valid-after/valid-until switchover
-
diff --git a/doc/spec/path-spec.txt b/doc/spec/path-spec.txt
deleted file mode 100644
index dceb21d..0000000
--- a/doc/spec/path-spec.txt
+++ /dev/null
@@ -1,423 +0,0 @@
-$Id$
-
-                           Tor Path Specification
-
-                              Roger Dingledine
-                               Nick Mathewson
-
-Note: This is an attempt to specify Tor as currently implemented.  Future
-versions of Tor will implement improved algorithms.
-
-This document tries to cover how Tor chooses to build circuits and assign
-streams to circuits.  Other implementations MAY take other approaches, but
-implementors should be aware of the anonymity and load-balancing implications
-of their choices.
-
-                    THIS SPEC ISN'T DONE YET.
-
-1. General operation
-
-   Tor begins building circuits as soon as it has enough directory
-   information to do so (see section 5 of dir-spec.txt).  Some circuits are
-   built preemptively because we expect to need them later (for user
-   traffic), and some are built because of immediate need (for user traffic
-   that no current circuit can handle, for testing the network or our
-   reachability, and so on).
-
-   When a client application creates a new stream (by opening a SOCKS
-   connection or launching a resolve request), we attach it to an appropriate
-   open circuit if one exists, or wait if an appropriate circuit is
-   in-progress. We launch a new circuit only
-   if no current circuit can handle the request.  We rotate circuits over
-   time to avoid some profiling attacks.
-
-   To build a circuit, we choose all the nodes we want to use, and then
-   construct the circuit.  Sometimes, when we want a circuit that ends at a
-   given hop, and we have an appropriate unused circuit, we "cannibalize" the
-   existing circuit and extend it to the new terminus.
-
-   These processes are described in more detail below.
-
-   This document describes Tor's automatic path selection logic only; path
-   selection can be overridden by a controller (with the EXTENDCIRCUIT and
-   ATTACHSTREAM commands).  Paths constructed through these means may
-   violate some constraints given below.
-
-1.1. Terminology
-
-   A "path" is an ordered sequence of nodes, not yet built as a circuit.
-
-   A "clean" circuit is one that has not yet been used for any traffic.
-
-   A "fast" or "stable" or "valid" node is one that has the 'Fast' or
-   'Stable' or 'Valid' flag
-   set respectively, based on our current directory information.  A "fast"
-   or "stable" circuit is one consisting only of "fast" or "stable" nodes.
-
-   In an "exit" circuit, the final node is chosen based on waiting stream
-   requests if any, and in any case it avoids nodes with exit policy of
-   "reject *:*". An "internal" circuit, on the other hand, is one where
-   the final node is chosen just like a middle node (ignoring its exit
-   policy).
-
-   A "request" is a client-side stream or DNS resolve that needs to be
-   served by a circuit.
-
-   A "pending" circuit is one that we have started to build, but which has
-   not yet completed.
-
-   A circuit or path "supports" a request if it is okay to use the
-   circuit/path to fulfill the request, according to the rules given below.
-   A circuit or path "might support" a request if some aspect of the request
-   is unknown (usually its target IP), but we believe the path probably
-   supports the request according to the rules given below.
-
-2. Building circuits
-
-2.1. When we build
-
-2.1.1. Clients build circuits preemptively
-
-   When running as a client, Tor tries to maintain at least a certain
-   number of clean circuits, so that new streams can be handled
-   quickly.  To increase the likelihood of success, Tor tries to
-   predict what circuits will be useful by choosing from among nodes
-   that support the ports we have used in the recent past (by default
-   one hour). Specifically, on startup Tor tries to maintain one clean
-   fast exit circuit that allows connections to port 80, and at least
-   two fast clean stable internal circuits in case we get a resolve
-   request or hidden service request (at least three if we _run_ a
-   hidden service).
-
-   After that, Tor will adapt the circuits that it preemptively builds
-   based on the requests it sees from the user: it tries to have two fast
-   clean exit circuits available for every port seen within the past hour
-   (each circuit can be adequate for many predicted ports -- it doesn't
-   need two separate circuits for each port), and it tries to have the
-   above internal circuits available if we've seen resolves or hidden
-   service activity within the past hour. If there are 12 or more clean
-   circuits open, it doesn't open more even if it has more predictions.
-
-   Only stable circuits can "cover" a port that is listed in the
-   LongLivedPorts config option. Similarly, hidden service requests
-   to ports listed in LongLivedPorts make us create stable internal
-   circuits.
-
-   Note that if there are no requests from the user for an hour, Tor
-   will predict no use and build no preemptive circuits.
-
-   The Tor client SHOULD NOT store its list of predicted requests to a
-   persistent medium.
-
-2.1.2. Clients build circuits on demand
-
-   Additionally, when a client request exists that no circuit (built or
-   pending) might support, we create a new circuit to support the request.
-   For exit connections, we pick an exit node that will handle the
-   most pending requests (choosing arbitrarily among ties), launch a
-   circuit to end there, and repeat until every unattached request
-   might be supported by a pending or built circuit. For internal
-   circuits, we pick an arbitrary acceptable path, repeating as needed.
-
-   In some cases we can reuse an already established circuit if it's
-   clean; see Section 2.3 (cannibalizing circuits) for details.
-
-2.1.3. Servers build circuits for testing reachability and bandwidth
-
-   Tor servers test reachability of their ORPort once they have
-   successfully built a circuit (on start and whenever their IP address
-   changes). They build an ordinary fast internal circuit with themselves
-   as the last hop. As soon as any testing circuit succeeds, the Tor
-   server decides it's reachable and is willing to publish a descriptor.
-
-   We launch multiple testing circuits (one at a time), until we
-   have NUM_PARALLEL_TESTING_CIRC (4) such circuits open. Then we
-   do a "bandwidth test" by sending a certain number of relay drop
-   cells down each circuit: BandwidthRate * 10 / CELL_NETWORK_SIZE
-   total cells divided across the four circuits, but never more than
-   CIRCWINDOW_START (1000) cells total. This exercises both outgoing and
-   incoming bandwidth, and helps to jumpstart the observed bandwidth
-   (see dir-spec.txt).
-
-   Tor servers also test reachability of their DirPort once they have
-   established a circuit, but they use an ordinary exit circuit for
-   this purpose.
-
-2.1.4. Hidden-service circuits
-
-   See section 4 below.
-
-2.1.5. Rate limiting of failed circuits
-
-   If we fail to build a circuit N times in a X second period (see Section
-   2.3 for how this works), we stop building circuits until the X seconds
-   have elapsed.
-   XXXX
-
-2.1.6. When to tear down circuits
-
-   XXXX
-
-2.2. Path selection and constraints
-
-   We choose the path for each new circuit before we build it.  We choose the
-   exit node first, followed by the other nodes in the circuit.  All paths
-   we generate obey the following constraints:
-     - We do not choose the same router twice for the same path.
-     - We do not choose any router in the same family as another in the same
-       path.
-     - We do not choose more than one router in a given /16 subnet
-       (unless EnforceDistinctSubnets is 0).
-     - We don't choose any non-running or non-valid router unless we have
-       been configured to do so. By default, we are configured to allow
-       non-valid routers in "middle" and "rendezvous" positions.
-     - If we're using Guard nodes, the first node must be a Guard (see 5
-       below)
-     - XXXX Choosing the length
-
-   For circuits that do not need to be "fast", when choosing among
-   multiple candidates for a path element, we choose randomly.
-
-   For "fast" circuits, we pick a given router as an exit with probability
-   proportional to its advertised bandwidth [the smaller of the 'rate' and
-   'observed' arguments to the "bandwidth" element in its descriptor].  If a
-   router's advertised bandwidth is greater than MAX_BELIEVABLE_BANDWIDTH
-   (currently 10 MB/s), we clip to that value.
-
-   For non-exit positions on "fast" circuits, we pick routers as above, but
-   we weight the clipped advertised bandwidth of Exit-flagged nodes depending
-   on the fraction of bandwidth available from non-Exit nodes.  Call the
-   total clipped advertised bandwidth for Exit nodes under consideration E,
-   and the total clipped advertised bandwidth for all nodes under
-   consideration T.  If E<T/3, we do not consider Exit-flagged nodes.
-   Otherwise, we weight their bandwidth with the factor (E-T/3)/E. This 
-   ensures that bandwidth is evenly distributed over nodes in 3-hop paths.
-
-   Similarly, guard nodes are weighted by the factor (G-T/3)/G, and not
-   considered for non-guard positions if this value is less than 0.
-
-   Additionally, we may be building circuits with one or more requests in
-   mind.  Each kind of request puts certain constraints on paths:
-
-     - All service-side introduction circuits and all rendezvous paths
-       should be Stable.
-     - All connection requests for connections that we think will need to
-       stay open a long time require Stable circuits.  Currently, Tor decides
-       this by examining the request's target port, and comparing it to a
-       list of "long-lived" ports. (Default: 21, 22, 706, 1863, 5050,
-       5190, 5222, 5223, 6667, 6697, 8300.)
-     - DNS resolves require an exit node whose exit policy is not equivalent
-       to "reject *:*".
-     - Reverse DNS resolves require a version of Tor with advertised eventdns
-       support (available in Tor 0.1.2.1-alpha-dev and later).
-     - All connection requests require an exit node whose exit policy
-       supports their target address and port (if known), or which "might
-       support it" (if the address isn't known).  See 2.2.1.
-     - Rules for Fast? XXXXX
-
-2.2.1. Choosing an exit
-
-   If we know what IP address we want to connect to or resolve, we can
-   trivially tell whether a given router will support it by simulating
-   its declared exit policy.
-
-   Because we often connect to addresses of the form hostname:port, we do not
-   always know the target IP address when we select an exit node.  In these
-   cases, we need to pick an exit node that "might support" connections to a
-   given address port with an unknown address.  An exit node "might support"
-   such a connection if any clause that accepts any connections to that port
-   precedes all clauses (if any) that reject all connections to that port.
-
-   Unless requested to do so by the user, we never choose an exit server
-   flagged as "BadExit" by more than half of the authorities who advertise
-   themselves as listing bad exits.
-
-2.2.2. User configuration
-
-   Users can alter the default behavior for path selection with configuration
-   options.
-
-   - If "ExitNodes" is provided, then every request requires an exit node on
-     the ExitNodes list.  (If a request is supported by no nodes on that list,
-     and StrictExitNodes is false, then Tor treats that request as if
-     ExitNodes were not provided.)
-
-   - "EntryNodes" and "StrictEntryNodes" behave analogously.
-
-   - If a user tries to connect to or resolve a hostname of the form
-     <target>.<servername>.exit, the request is rewritten to a request for
-     <target>, and the request is only supported by the exit whose nickname
-     or fingerprint is <servername>.
-
-2.3. Cannibalizing circuits
-
-   If we need a circuit and have a clean one already established, in
-   some cases we can adapt the clean circuit for our new
-   purpose. Specifically,
-
-   For hidden service interactions, we can "cannibalize" a clean internal
-   circuit if one is available, so we don't need to build those circuits
-   from scratch on demand.
-
-   We can also cannibalize clean circuits when the client asks to exit
-   at a given node -- either via the ".exit" notation or because the
-   destination is running at the same location as an exit node.
-
-
-2.4. Handling failure
-
-   If an attempt to extend a circuit fails (either because the first create
-   failed or a subsequent extend failed) then the circuit is torn down and is
-   no longer pending.  (XXXX really?)  Requests that might have been
-   supported by the pending circuit thus become unsupported, and a new
-   circuit needs to be constructed.
-
-   If a stream "begin" attempt fails with an EXITPOLICY error, we
-   decide that the exit node's exit policy is not correctly advertised,
-   so we treat the exit node as if it were a non-exit until we retrieve
-   a fresh descriptor for it.
-
-   XXXX
-
-3. Attaching streams to circuits
-
-   When a circuit that might support a request is built, Tor tries to attach
-   the request's stream to the circuit and sends a BEGIN, BEGIN_DIR,
-   or RESOLVE relay
-   cell as appropriate.  If the request completes unsuccessfully, Tor
-   considers the reason given in the CLOSE relay cell. [XXX yes, and?]
-
-
-   After a request has remained unattached for SocksTimeout (2 minutes
-   by default), Tor abandons the attempt and signals an error to the
-   client as appropriate (e.g., by closing the SOCKS connection).
-
-   XXX Timeouts and when Tor auto-retries.
-    * What stream-end-reasons are appropriate for retrying.
-
-   If no reply to BEGIN/RESOLVE, then the stream will timeout and fail.
-
-4. Hidden-service related circuits
-
-  XXX Tracking expected hidden service use (client-side and hidserv-side)
-
-5. Guard nodes
-
-  We use Guard nodes (also called "helper nodes" in the literature) to
-  prevent certain profiling attacks.  Here's the risk: if we choose entry and
-  exit nodes at random, and an attacker controls C out of N servers
-  (ignoring advertised bandwidth), then the
-  attacker will control the entry and exit node of any given circuit with
-  probability (C/N)^2.  But as we make many different circuits over time,
-  then the probability that the attacker will see a sample of about (C/N)^2
-  of our traffic goes to 1.  Since statistical sampling works, the attacker
-  can be sure of learning a profile of our behavior.
-
-  If, on the other hand, we picked an entry node and held it fixed, we would
-  have probability C/N of choosing a bad entry and being profiled, and
-  probability (N-C)/N of choosing a good entry and not being profiled.
-
-  When guard nodes are enabled, Tor maintains an ordered list of entry nodes
-  as our chosen guards, and stores this list persistently to disk.  If a Guard
-  node becomes unusable, rather than replacing it, Tor adds new guards to the
-  end of the list.  When choosing the first hop of a circuit, Tor
-  chooses at
-  random from among the first NumEntryGuards (default 3) usable guards on the
-  list.  If there are not at least 2 usable guards on the list, Tor adds
-  routers until there are, or until there are no more usable routers to add.
-
-  A guard is unusable if any of the following hold:
-    - it is not marked as a Guard by the networkstatuses,
-    - it is not marked Valid (and the user hasn't set AllowInvalid entry)
-    - it is not marked Running
-    - Tor couldn't reach it the last time it tried to connect
-
-  A guard is unusable for a particular circuit if any of the rules for path
-  selection in 2.2 are not met.  In particular, if the circuit is "fast"
-  and the guard is not Fast, or if the circuit is "stable" and the guard is
-  not Stable, or if the guard has already been chosen as the exit node in
-  that circuit, Tor can't use it as a guard node for that circuit.
-
-  If the guard is excluded because of its status in the networkstatuses for
-  over 30 days, Tor removes it from the list entirely, preserving order.
-
-  If Tor fails to connect to an otherwise usable guard, it retries
-  periodically: every hour for six hours, every 4 hours for 3 days, every
-  18 hours for a week, and every 36 hours thereafter.  Additionally, Tor
-  retries unreachable guards the first time it adds a new guard to the list,
-  since it is possible that the old guards were only marked as unreachable
-  because the network was unreachable or down.
-
-  Tor does not add a guard persistently to the list until the first time we
-  have connected to it successfully.
-
-6. Router descriptor purposes
-
-  There are currently three "purposes" supported for router descriptors:
-  general, controller, and bridge. Most descriptors are of type general
-  -- these are the ones listed in the consensus, and the ones fetched
-  and used in normal cases.
-
-  Controller-purpose descriptors are those delivered by the controller
-  and labelled as such: they will be kept around (and expire like
-  normal descriptors), and they can be used by the controller in its
-  CIRCUITEXTEND commands. Otherwise they are ignored by Tor when it
-  chooses paths.
-
-  Bridge-purpose descriptors are for routers that are used as bridges. See
-  doc/design-paper/blocking.pdf for more design explanation, or proposal
-  125 for specific details. Currently bridge descriptors are used in place
-  of normal entry guards, for Tor clients that have UseBridges enabled.
-
-
-X. Old notes
-
-X.1. Do we actually do this?
-
-How to deal with network down.
-  - While all helpers are down/unreachable and there are no established
-    or on-the-way testing circuits, launch a testing circuit. (Do this
-    periodically in the same way we try to establish normal circuits
-    when things are working normally.)
-    (Testing circuits are a special type of circuit, that streams won't
-    attach to by accident.)
-  - When a testing circuit succeeds, mark all helpers up and hold
-    the testing circuit open.
-  - If a connection to a helper succeeds, close all testing circuits.
-    Else mark that helper down and try another.
-  - If the last helper is marked down and we already have a testing
-    circuit established, then add the first hop of that testing circuit
-    to the end of our helper node list, close that testing circuit,
-    and go back to square one. (Actually, rather than closing the
-    testing circuit, can we get away with converting it to a normal
-    circuit and beginning to use it immediately?)
-
-  [Do we actually do any of the above?  If so, let's spec it.  If not, let's
-  remove it. -NM]
-
-X.2. A thing we could do to deal with reachability.
-
-And as a bonus, it leads to an answer to Nick's attack ("If I pick
-my helper nodes all on 18.0.0.0:*, then I move, you'll know where I
-bootstrapped") -- the answer is to pick your original three helper nodes
-without regard for reachability. Then the above algorithm will add some
-more that are reachable for you, and if you move somewhere, it's more
-likely (though not certain) that some of the originals will become useful.
-Is that smart or just complex?
-
-X.3. Some stuff that worries me about entry guards. 2006 Jun, Nickm.
-
-  It is unlikely for two users to have the same set of entry guards.
-  Observing a user is sufficient to learn its entry guards.  So, as we move
-  around, entry guards make us linkable.  If we want to change guards when
-  our location (IP? subnet?) changes, we have two bad options.  We could
-    - Drop the old guards.  But if we go back to our old location,
-      we'll not use our old guards.  For a laptop that sometimes gets used
-      from work and sometimes from home, this is pretty fatal.
-    - Remember the old guards as associated with the old location, and use
-      them again if we ever go back to the old location.  This would be
-      nasty, since it would force us to record where we've been.
-
-  [Do we do any of this now? If not, this should move into 099-misc or
-  098-todo. -NM]
-
diff --git a/doc/spec/proposals/000-index.txt b/doc/spec/proposals/000-index.txt
deleted file mode 100644
index d751576..0000000
--- a/doc/spec/proposals/000-index.txt
+++ /dev/null
@@ -1,161 +0,0 @@
-Filename: 000-index.txt
-Title: Index of Tor Proposals
-Version: $Revision$
-Last-Modified: $Date$
-Author: Nick Mathewson
-Created: 26-Jan-2007
-Status: Meta
-
-Overview:
-
-   This document provides an index to Tor proposals.
-
-   This is an informational document.
-
-   Everything in this document below the line of '=' signs is automatically
-   generated by reindex.py; do not edit by hand.
-
-============================================================
-Proposals by number:
-
-000  Index of Tor Proposals [META]
-001  The Tor Proposal Process [META]
-098  Proposals that should be written [META]
-099  Miscellaneous proposals [META]
-100  Tor Unreliable Datagram Extension Proposal [DEAD]
-101  Voting on the Tor Directory System [CLOSED]
-102  Dropping "opt" from the directory format [CLOSED]
-103  Splitting identity key from regularly used signing key [CLOSED]
-104  Long and Short Router Descriptors [CLOSED]
-105  Version negotiation for the Tor protocol [CLOSED]
-106  Checking fewer things during TLS handshakes [CLOSED]
-107  Uptime Sanity Checking [CLOSED]
-108  Base "Stable" Flag on Mean Time Between Failures [CLOSED]
-109  No more than one server per IP address [CLOSED]
-110  Avoiding infinite length circuits [ACCEPTED]
-111  Prioritizing local traffic over relayed traffic [CLOSED]
-112  Bring Back Pathlen Coin Weight [SUPERSEDED]
-113  Simplifying directory authority administration [SUPERSEDED]
-114  Distributed Storage for Tor Hidden Service Descriptors [CLOSED]
-115  Two Hop Paths [DEAD]
-116  Two hop paths from entry guards [DEAD]
-117  IPv6 exits [ACCEPTED]
-118  Advertising multiple ORPorts at once [ACCEPTED]
-119  New PROTOCOLINFO command for controllers [CLOSED]
-120  Shutdown descriptors when Tor servers stop [DEAD]
-121  Hidden Service Authentication [FINISHED]
-122  Network status entries need a new Unnamed flag [CLOSED]
-123  Naming authorities automatically create bindings [CLOSED]
-124  Blocking resistant TLS certificate usage [SUPERSEDED]
-125  Behavior for bridge users, bridge relays, and bridge authorities [CLOSED]
-126  Getting GeoIP data and publishing usage summaries [CLOSED]
-127  Relaying dirport requests to Tor download site / website [DRAFT]
-128  Families of private bridges [DEAD]
-129  Block Insecure Protocols by Default [CLOSED]
-130  Version 2 Tor connection protocol [CLOSED]
-131  Help users to verify they are using Tor [NEEDS-REVISION]
-132  A Tor Web Service For Verifying Correct Browser Configuration [DRAFT]
-133  Incorporate Unreachable ORs into the Tor Network [DRAFT]
-134  More robust consensus voting with diverse authority sets [ACCEPTED]
-135  Simplify Configuration of Private Tor Networks [CLOSED]
-136  Mass authority migration with legacy keys [CLOSED]
-137  Keep controllers informed as Tor bootstraps [CLOSED]
-138  Remove routers that are not Running from consensus documents [CLOSED]
-139  Download consensus documents only when it will be trusted [CLOSED]
-140  Provide diffs between consensuses [ACCEPTED]
-141  Download server descriptors on demand [DRAFT]
-142  Combine Introduction and Rendezvous Points [DEAD]
-143  Improvements of Distributed Storage for Tor Hidden Service Descriptors [OPEN]
-144  Increase the diversity of circuits by detecting nodes belonging the same provider [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 [ACCEPTED]
-148  Stream end reasons from the client side should be uniform [CLOSED]
-149  Using data from NETINFO cells [OPEN]
-150  Exclude Exit Nodes from a circuit [CLOSED]
-151  Improving Tor Path Selection [DRAFT]
-152  Optionally allow exit from single-hop circuits [CLOSED]
-153  Automatic software update protocol [SUPERSEDED]
-154  Automatic Software Update Protocol [SUPERSEDED]
-155  Four Improvements of Hidden Service Performance [FINISHED]
-156  Tracking blocked ports on the client side [OPEN]
-157  Make certificate downloads specific [ACCEPTED]
-158  Clients download consensus + microdescriptors [OPEN]
-159  Exit Scanning [OPEN]
-
-
-Proposals by status:
-
- DRAFT:
-   127  Relaying dirport requests to Tor download site / website
-   132  A Tor Web Service For Verifying Correct Browser Configuration
-   133  Incorporate Unreachable ORs into the Tor Network
-   141  Download server descriptors on demand
-   144  Increase the diversity of circuits by detecting nodes belonging the same provider
-   151  Improving Tor Path Selection
- NEEDS-REVISION:
-   131  Help users to verify they are using Tor
- OPEN:
-   143  Improvements of Distributed Storage for Tor Hidden Service Descriptors [for 0.2.1.x]
-   145  Separate "suitable as a guard" from "suitable as a new guard" [for 0.2.1.x]
-   146  Add new flag to reflect long-term stability [for 0.2.1.x]
-   149  Using data from NETINFO cells [for 0.2.1.x]
-   156  Tracking blocked ports on the client side [for 0.2.?]
-   158  Clients download consensus + microdescriptors
-   159  Exit Scanning
- ACCEPTED:
-   110  Avoiding infinite length circuits [for 0.2.1.x] [in 0.2.1.3-alpha]
-   117  IPv6 exits [for 0.2.1.x]
-   118  Advertising multiple ORPorts at once [for 0.2.1.x]
-   134  More robust consensus voting with diverse authority sets [for 0.2.2.x]
-   140  Provide diffs between consensuses [for 0.2.2.x]
-   147  Eliminate the need for v2 directories in generating v3 directories [for 0.2.1.x]
-   157  Make certificate downloads specific [for 0.2.1.x]
- META:
-   000  Index of Tor Proposals
-   001  The Tor Proposal Process
-   098  Proposals that should be written
-   099  Miscellaneous proposals
- FINISHED:
-   121  Hidden Service Authentication [in 0.2.1.x]
-   155  Four Improvements of Hidden Service Performance [in 0.2.1.x]
- CLOSED:
-   101  Voting on the Tor Directory System [in 0.2.0.x]
-   102  Dropping "opt" from the directory format [in 0.2.0.x]
-   103  Splitting identity key from regularly used signing key [in 0.2.0.x]
-   104  Long and Short Router Descriptors [in 0.2.0.x]
-   105  Version negotiation for the Tor protocol [in 0.2.0.x]
-   106  Checking fewer things during TLS handshakes [in 0.2.0.x]
-   107  Uptime Sanity Checking [in 0.2.0.x]
-   108  Base "Stable" Flag on Mean Time Between Failures [in 0.2.0.x]
-   109  No more than one server per IP address [in 0.2.0.x]
-   111  Prioritizing local traffic over relayed traffic [in 0.2.0.x]
-   114  Distributed Storage for Tor Hidden Service Descriptors [in 0.2.0.x]
-   119  New PROTOCOLINFO command for controllers [in 0.2.0.x]
-   122  Network status entries need a new Unnamed flag [in 0.2.0.x]
-   123  Naming authorities automatically create bindings [in 0.2.0.x]
-   125  Behavior for bridge users, bridge relays, and bridge authorities [in 0.2.0.x]
-   126  Getting GeoIP data and publishing usage summaries [in 0.2.0.x]
-   129  Block Insecure Protocols by Default [in 0.2.0.x]
-   130  Version 2 Tor connection protocol [in 0.2.0.x]
-   135  Simplify Configuration of Private Tor Networks [for 0.2.1.x] [in 0.2.1.2-alpha]
-   136  Mass authority migration with legacy keys [in 0.2.0.x]
-   137  Keep controllers informed as Tor bootstraps [in 0.2.1.x]
-   138  Remove routers that are not Running from consensus documents [in 0.2.1.2-alpha]
-   139  Download consensus documents only when it will be trusted [in 0.2.1.x]
-   148  Stream end reasons from the client side should be uniform [in 0.2.1.9-alpha]
-   150  Exclude Exit Nodes from a circuit [in 0.2.1.3-alpha]
-   152  Optionally allow exit from single-hop circuits [in 0.2.1.6-alpha]
- SUPERSEDED:
-   112  Bring Back Pathlen Coin Weight
-   113  Simplifying directory authority administration
-   124  Blocking resistant TLS certificate usage
-   153  Automatic software update protocol
-   154  Automatic Software Update Protocol
- DEAD:
-   100  Tor Unreliable Datagram Extension Proposal
-   115  Two Hop Paths
-   116  Two hop paths from entry guards
-   120  Shutdown descriptors when Tor servers stop
-   128  Families of private bridges
-   142  Combine Introduction and Rendezvous Points
diff --git a/doc/spec/proposals/001-process.txt b/doc/spec/proposals/001-process.txt
deleted file mode 100644
index 3a767b5..0000000
--- a/doc/spec/proposals/001-process.txt
+++ /dev/null
@@ -1,187 +0,0 @@
-Filename: 001-process.txt
-Title: The Tor Proposal Process
-Version: $Revision$
-Last-Modified: $Date$
-Author: Nick Mathewson
-Created: 30-Jan-2007
-Status: Meta
-
-Overview:
-
-   This document describes how to change the Tor specifications, how Tor
-   proposals work, and the relationship between Tor proposals and the
-   specifications.
-
-   This is an informational document.
-
-Motivation:
-
-   Previously, our process for updating the Tor specifications was maximally
-   informal: we'd patch the specification (sometimes forking first, and
-   sometimes not), then discuss the patches, reach consensus, and implement
-   the changes.
-
-   This had a few problems.
-
-   First, even at its most efficient, the old process would often have the
-   spec out of sync with the code.  The worst cases were those where
-   implementation was deferred: the spec and code could stay out of sync for
-   versions at a time.
-
-   Second, it was hard to participate in discussion, since you had to know
-   which portions of the spec were a proposal, and which were already
-   implemented.
-
-   Third, it littered the specifications with too many inline comments.
-     [This was a real problem -NM]
-       [Especially when it went to multiple levels! -NM]
-         [XXXX especially when they weren't signed and talked about that
-          thing that you can't remember after a year]
-
-How to change the specs now:
-
-   First, somebody writes a proposal document.  It should describe the change
-   that should be made in detail, and give some idea of how to implement it.
-   Once it's fleshed out enough, it becomes a proposal.
-
-   Like an RFC, every proposal gets a number.  Unlike RFCs, proposals can
-   change over time and keep the same number, until they are finally
-   accepted or rejected.  The history for each proposal
-   will be stored in the Tor Subversion repository.
-
-   Once a proposal is in the repository, we should discuss and improve it
-   until we've reached consensus that it's a good idea, and that it's
-   detailed enough to implement.  When this happens, we implement the
-   proposal and incorporate it into the specifications.  Thus, the specs
-   remain the canonical documentation for the Tor protocol: no proposal is
-   ever the canonical documentation for an implemented feature.
-
-   (This process is pretty similar to the Python Enhancement Process, with
-   the major exception that Tor proposals get re-integrated into the specs
-   after implementation, whereas PEPs _become_ the new spec.)
-
-   {It's still okay to make small changes directly to the spec if the code
-   can be
-   written more or less immediately, or cosmetic changes if no code change is
-   required.  This document reflects the current developers' _intent_, not
-   a permanent promise to always use this process in the future: we reserve
-   the right to get really excited and run off and implement something in a
-   caffeine-or-m&m-fueled all-night hacking session.}
-
-How new proposals get added:
-
-  Once an idea has been proposed on the development list, a properly formatted
-  (see below) draft exists, and rough consensus within the active development
-  community exists that this idea warrants consideration, the proposal editor
-  will officially add the proposal.
-
-  To get your proposal in, send it to or-dev.
-
-  The current proposal editor is Nick Mathewson.
-
-What should go in a proposal:
-
-   Every proposal should have a header containing these fields:
-     Filename, Title, Version, Last-Modified, Author, Created, Status.
-   The Version and Last-Modified fields should use the SVN Revision and Date
-   tags respectively.
-
-   These fields are optional but recommended:
-     Target, Implemented-In.
-   The Target field should describe which version the proposal is hoped to be
-   implemented in (if it's Open or Accepted).  The Implemented-In field
-   should describe which version the proposal was implemented in (if it's
-   Finished or Closed).
-
-   The body of the proposal should start with an Overview section explaining
-   what the proposal's about, what it does, and about what state it's in.
-
-   After the Overview, the proposal becomes more free-form.  Depending on its
-   the length and complexity, the proposal can break into sections as
-   appropriate, or follow a short discursive format.  Every proposal should
-   contain at least the following information before it is "ACCEPTED",
-   though the information does not need to be in sections with these names.
-
-      Motivation: What problem is the proposal trying to solve?  Why does
-        this problem matter?  If several approaches are possible, why take this
-        one?
-
-      Design: A high-level view of what the new or modified features are, how
-        the new or modified features work, how they interoperate with each
-        other, and how they interact with the rest of Tor.  This is the main
-        body of the proposal.  Some proposals will start out with only a
-        Motivation and a Design, and wait for a specification until the
-        Design seems approximately right.
-
-      Security implications: What effects the proposed changes might have on
-        anonymity, how well understood these effects are, and so on.
-
-      Specification: A detailed description of what needs to be added to the
-        Tor specifications in order to implement the proposal.  This should
-        be in about as much detail as the specifications will eventually
-        contain: it should be possible for independent programmers to write
-        mutually compatible implementations of the proposal based on its
-        specifications.
-
-      Compatibility: Will versions of Tor that follow the proposal be
-        compatible with versions that do not?  If so, how will compatibility
-        be achieved?  Generally, we try to not drop compatibility if at
-        all possible; we haven't made a "flag day" change since May 2004,
-        and we don't want to do another one.
-
-      Implementation: If the proposal will be tricky to implement in Tor's
-        current architecture, the document can contain some discussion of how
-        to go about making it work.
-
-      Performance and scalability notes: If the feature will have an effect
-        on performance (in RAM, CPU, bandwidth) or scalability, there should
-        be some analysis on how significant this effect will be, so that we
-        can avoid really expensive performance regressions, and so we can
-        avoid wasting time on insignificant gains.
-
-Proposal status:
-
-   Open: A proposal under discussion.
-
-   Accepted: The proposal is complete, and we intend to implement it.
-      After this point, substantive changes to the proposal should be
-      avoided, and regarded as a sign of the process having failed
-      somewhere.
-
-   Finished: The proposal has been accepted and implemented.  After this
-      point, the proposal should not be changed.
-
-   Closed: The proposal has been accepted, implemented, and merged into the
-      main specification documents.  The proposal should not be changed after
-      this point.
-
-   Rejected: We're not going to implement the feature as described here,
-      though we might do some other version.  See comments in the document
-      for details.  The proposal should not be changed after this point;
-      to bring up some other version of the idea, write a new proposal.
-
-   Draft: This isn't a complete proposal yet; there are definite missing
-      pieces.  Please don't add any new proposals with this status; put them
-      in the "ideas" sub-directory instead.
-
-   Needs-Revision: The idea for the proposal is a good one, but the proposal
-      as it stands has serious problems that keep it from being accepted.
-      See comments in the document for details.
-
-   Dead: The proposal hasn't been touched in a long time, and it doesn't look
-      like anybody is going to complete it soon.  It can become "Open" again
-      if it gets a new proponent.
-
-   Needs-Research: There are research problems that need to be solved before
-      it's clear whether the proposal is a good idea.
-
-   Meta: This is not a proposal, but a document about proposals.
-
-
-   The editor maintains the correct status of proposals, based on rough
-   consensus and his own discretion.
-
-Proposal numbering:
-
-   Numbers 000-099 are reserved for special and meta-proposals.  100 and up
-   are used for actual proposals.  Numbers aren't recycled.
diff --git a/doc/spec/proposals/098-todo.txt b/doc/spec/proposals/098-todo.txt
deleted file mode 100644
index e891ea8..0000000
--- a/doc/spec/proposals/098-todo.txt
+++ /dev/null
@@ -1,109 +0,0 @@
-Filename: 098-todo.txt
-Title: Proposals that should be written
-Version: $Revision$
-Last-Modified: $Date$
-Author: Nick Mathewson, Roger Dingledine
-Created: 26-Jan-2007
-Status: Meta
-
-Overview:
-
-   This document lists ideas that various people have had for improving the
-   Tor protocol.  These should be implemented and specified if they're
-   trivial, or written up as proposals if they're not.
-
-   This is an active document, to be edited as proposals are written and as
-   we come up with new ideas for proposals.  We should take stuff out as it
-   seems irrelevant.
-
-
-For some later protocol version.
-
-  - It would be great to get smarter about identity and linkability.
-    It's not crazy to say, "Never use the same circuit for my SSH
-    connections and my web browsing."  How far can/should we take this?
-    See ideas/xxx-separate-streams-by-port.txt for a start.
-
-  - Fix onionskin handshake scheme to be more mainstream, less nutty.
-    Can we just do
-        E(HMAC(g^x), g^x) rather than just E(g^x) ?
-    No, that has the same flaws as before. We should send
-        E(g^x, C) with random C and expect g^y, HMAC_C(K=g^xy).
-    Better ask Ian; probably Stephen too.
-
-  - Length on CREATE and friends
-
-  - Versioning on circuits and create cells, so we have a clear path
-    to improve the circuit protocol.
-
-  - SHA1 is showing its age.  We should get a design for upgrading our
-    hash once the AHS competition is done, or even sooner.
-
-  - Not being able to upgrade ciphersuites or increase key lengths is
-    lame.
-  - Paul has some ideas about circuit creation; read his PET paper once it's
-    out.
-
-Any time:
-
-  - Some ideas for revising the directory protocol:
-    - Extend the "r" line in network-status to give a set of buckets (say,
-      comma-separated) for that router.
-      - Buckets are deterministic based on IP address.
-      - Then clients can choose a bucket (or set of buckets) to
-        download and use.
-    - We need a way for the authorities to declare that nodes are in a
-      family.  Also, it kinda sucks that family declarations use O(N^2) space
-      in the descriptors.
-  - REASON_CONNECTFAILED should include an IP.
-  - Spec should incorporate some prose from tor-design to be more readable.
-  - Spec when we should rotate which keys
-  - Spec how to publish descriptors less often
-  - Describe pros and cons of non-deterministic path lengths
-
-  - We should use a variable-length path length by default -- 3 +/- some
-    distribution. Need to think harder about allowing values less than 3,
-    and there's a tradeoff between having a wide variance and performance.
-
-  - Clients currently use certs during TLS.  Is this wise?  It does make it
-    easier for servers to tell which NATted client is which. We could use a
-    seprate set of certs for each guard, I suppose, but generating so many
-    certs could get expensive.  Omitting them entirely would make OP->OR
-    easier to tell from OR->OR.
-
-Things that should change...
-
-B.1. ... but which will require backward-incompatible change
-
-  - Circuit IDs should be longer.
-  . IPv6 everywhere.
-  - Maybe, keys should be longer.
-    - Maybe, key-length should be adjustable.  How to do this without
-      making anonymity suck?
-  - Drop backward compatibility.
-  - We should use a 128-bit subgroup of our DH prime.
-  - Handshake should use HMAC.
-  - Multiple cell lengths.
-  - Ability to split circuits across paths (If this is useful.)
-  - SENDME windows should be dynamic.
-
-  - Directory
-     - Stop ever mentioning socks ports
-
-B.1. ... and that will require no changes
-
-   - Advertised outbound IP?
-   - Migrate streams across circuits.
-   - Fix bug 469 by limiting the number of simultaneous connections per IP.
-
-B.2. ... and that we have no idea how to do.
-
-   - UDP (as transport)
-   - UDP (as content)
-   - Use a better AES mode that has built-in integrity checking,
-     doesn't grow with the number of hops, is not patented, and
-     is implemented and maintained by smart people.
-
-Let onion keys be not just RSA but maybe DH too, for Paul's reply onion
-design.
-
diff --git a/doc/spec/proposals/099-misc.txt b/doc/spec/proposals/099-misc.txt
deleted file mode 100644
index ba13ea2..0000000
--- a/doc/spec/proposals/099-misc.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Filename: 099-misc.txt
-Title: Miscellaneous proposals
-Version: $Revision$
-Last-Modified: $Date$
-Author: Various
-Created: 26-Jan-2007
-Status: Meta
-
-Overview:
-
-   This document is for small proposal ideas that are about one paragraph in
-   length.  From here, ideas can be rejected outright, expanded into full
-   proposals, or specified and implemented as-is.
-
-Proposals
-
-1. Directory compression.
-
-  Gzip would be easier to work with than zlib; bzip2 would result in smaller
-  data lengths.  [Concretely, we're looking at about 10-15% space savings at
-  the expense of 3-5x longer compression time for using bzip2.]  Doing
-  on-the-fly gzip requires zlib 1.2 or later; doing bzip2 requires bzlib.
-  Pre-compressing status documents in multiple formats would force us to use
-  more memory to hold them.
-
-  Status: Open
-
-  -- Nick Mathewson
-
-
diff --git a/doc/spec/proposals/100-tor-spec-udp.txt b/doc/spec/proposals/100-tor-spec-udp.txt
deleted file mode 100644
index 8224682..0000000
--- a/doc/spec/proposals/100-tor-spec-udp.txt
+++ /dev/null
@@ -1,424 +0,0 @@
-Filename: 100-tor-spec-udp.txt
-Title: Tor Unreliable Datagram Extension Proposal
-Version: $Revision$
-Last-Modified: $Date$
-Author: Marc Liberatore
-Created: 23 Feb 2006
-Status: Dead
-
-Overview:
-
-   This is a modified version of the Tor specification written by Marc
-   Liberatore to add UDP support to Tor.  For each TLS link, it adds a
-   corresponding DTLS link: control messages and TCP data flow over TLS, and
-   UDP data flows over DTLS.
-
-   This proposal is not likely to be accepted as-is; see comments at the end
-   of the document.
-
-
-Contents
-
-0. Introduction
-
-  Tor is a distributed overlay network designed to anonymize low-latency
-  TCP-based applications.  The current tor specification supports only
-  TCP-based traffic.  This limitation prevents the use of tor to anonymize
-  other important applications, notably voice over IP software.  This document
-  is a proposal to extend the tor specification to support UDP traffic.
-
-  The basic design philosophy of this extension is to add support for
-  tunneling unreliable datagrams through tor with as few modifications to the
-  protocol as possible.  As currently specified, tor cannot directly support
-  such tunneling, as connections between nodes are built using transport layer
-  security (TLS) atop TCP.  The latency incurred by TCP is likely unacceptable
-  to the operation of most UDP-based application level protocols.
-
-  Thus, we propose the addition of links between nodes using datagram
-  transport layer security (DTLS).  These links allow packets to traverse a
-  route through tor quickly, but their unreliable nature requires minor
-  changes to the tor protocol.  This proposal outlines the necessary
-  additions and changes to the tor specification to support UDP traffic.
-
-  We note that a separate set of DTLS links between nodes creates a second
-  overlay, distinct from the that composed of TLS links.  This separation and
-  resulting decrease in each anonymity set's size will make certain attacks
-  easier.  However, it is our belief that VoIP support in tor will
-  dramatically increase its appeal, and correspondingly, the size of its user
-  base, number of deployed nodes, and total traffic relayed.  These increases
-  should help offset the loss of anonymity that two distinct networks imply.
-
-1. Overview of Tor-UDP and its complications
-
-  As described above, this proposal extends the Tor specification to support
-  UDP with as few changes as possible.  Tor's overlay network is managed
-  through TLS based connections; we will re-use this control plane to set up
-  and tear down circuits that relay UDP traffic.  These circuits be built atop
-  DTLS, in a fashion analogous to how Tor currently sends TCP traffic over
-  TLS.
-
-  The unreliability of DTLS circuits creates problems for Tor at two levels:
-
-      1. Tor's encryption of the relay layer does not allow independent
-      decryption of individual records. If record N is not received, then
-      record N+1 will not decrypt correctly, as the counter for AES/CTR is
-      maintained implicitly.
-
-      2. Tor's end-to-end integrity checking works under the assumption that
-      all RELAY cells are delivered.  This assumption is invalid when cells
-      are sent over DTLS.
-
-  The fix for the first problem is straightforward: add an explicit sequence
-  number to each cell.  To fix the second problem, we introduce a
-  system of nonces and hashes to RELAY packets.
-
-  In the following sections, we mirror the layout of the Tor Protocol
-  Specification, presenting the necessary modifications to the Tor protocol as
-  a series of deltas.
-
-2. Connections
-
-  Tor-UDP uses DTLS for encryption of some links.  All DTLS links must have
-  corresponding TLS links, as all control messages are sent over TLS.  All
-  implementations MUST support the DTLS ciphersuite "[TODO]".
-
-  DTLS connections are formed using the same protocol as TLS connections.
-  This occurs upon request, following a CREATE_UDP or CREATE_FAST_UDP cell,
-  as detailed in section 4.6.
-
-  Once a paired TLS/DTLS connection is established, the two sides send cells
-  to one another.  All but two types of cells are sent over TLS links.  RELAY
-  cells containing the commands RELAY_UDP_DATA and RELAY_UDP_DROP, specified
-  below, are sent over DTLS links.  [Should all cells still be 512 bytes long?
-  Perhaps upon completion of a preliminary implementation, we should do a
-  performance evaluation for some class of UDP traffic, such as VoIP. - ML]
-  Cells may be sent embedded in TLS or DTLS records of any size or divided
-  across such records.  The framing of these records MUST NOT leak any more
-  information than the above differentiation on the basis of cell type.  [I am
-  uncomfortable with this leakage, but don't see any simple, elegant way
-  around it. -ML]
-
-  As with TLS connections, DTLS connections are not permanent.
-
-3. Cell format
-
-  Each cell contains the following fields:
-
-        CircID                                [2 bytes]
-        Command                               [1 byte]
-        Sequence Number                       [2 bytes]
-        Payload (padded with 0 bytes)         [507 bytes]
-                                         [Total size: 512 bytes]
-
-  The 'Command' field holds one of the following values:
-       0 -- PADDING         (Padding)                     (See Sec 6.2)
-       1 -- CREATE          (Create a circuit)            (See Sec 4)
-       2 -- CREATED         (Acknowledge create)          (See Sec 4)
-       3 -- RELAY           (End-to-end data)             (See Sec 5)
-       4 -- DESTROY         (Stop using a circuit)        (See Sec 4)
-       5 -- CREATE_FAST     (Create a circuit, no PK)     (See Sec 4)
-       6 -- CREATED_FAST    (Circuit created, no PK)      (See Sec 4)
-       7 -- CREATE_UDP      (Create a UDP circuit)        (See Sec 4)
-       8 -- CREATED_UDP     (Acknowledge UDP create)      (See Sec 4)
-       9 -- CREATE_FAST_UDP (Create a UDP circuit, no PK) (See Sec 4)
-      10 -- CREATED_FAST_UDP(UDP circuit created, no PK)  (See Sec 4)
-
-  The sequence number allows for AES/CTR decryption of RELAY cells
-  independently of one another; this functionality is required to support
-  cells sent over DTLS.  The sequence number is described in more detail in
-  section 4.5.
-
-  [Should the sequence number only appear in RELAY packets?  The overhead is
-  small, and I'm hesitant to force more code paths on the implementor. -ML]
-  [There's already a separate relay header that has other material in it,
-  so it wouldn't be the end of the world to move it there if it's
-  appropriate. -RD]
-
-  [Having separate commands for UDP circuits seems necessary, unless we can
-  assume a flag day event for a large number of tor nodes. -ML]
-
-4. Circuit management
-
-4.2. Setting circuit keys
-
-  Keys are set up for UDP circuits in the same fashion as for TCP circuits.
-  Each UDP circuit shares keys with its corresponding TCP circuit.
-
-  [If the keys are used for both TCP and UDP connections, how does it
-  work to mix sequence-number-less cells with sequenced-numbered cells --
-  how do you know you have the encryption order right? -RD]
-
-4.3. Creating circuits
-
-  UDP circuits are created as TCP circuits, using the *_UDP cells as
-  appropriate.
-
-4.4. Tearing down circuits
-
-  UDP circuits are torn down as TCP circuits, using the *_UDP cells as
-  appropriate.
-
-4.5. Routing relay cells
-
-  When an OR receives a RELAY cell, it checks the cell's circID and
-  determines whether it has a corresponding circuit along that
-  connection.  If not, the OR drops the RELAY cell.
-
-  Otherwise, if the OR is not at the OP edge of the circuit (that is,
-  either an 'exit node' or a non-edge node), it de/encrypts the payload
-  with AES/CTR, as follows:
-       'Forward' relay cell (same direction as CREATE):
-           Use Kf as key; decrypt, using sequence number to synchronize
-           ciphertext and keystream.
-       'Back' relay cell (opposite direction from CREATE):
-           Use Kb as key; encrypt, using sequence number to synchronize
-           ciphertext and keystream.
-  Note that in counter mode, decrypt and encrypt are the same operation.
-  [Since the sequence number is only 2 bytes, what do you do when it
-  rolls over? -RD]
-
-  Each stream encrypted by a Kf or Kb has a corresponding unique state,
-  captured by a sequence number; the originator of each such stream chooses
-  the initial sequence number randomly, and increments it only with RELAY
-  cells.  [This counts cells; unlike, say, TCP, tor uses fixed-size cells, so
-  there's no need for counting bytes directly.  Right? - ML]
-  [I believe this is true. You'll find out for sure when you try to
-  build it. ;) -RD]
-
-  The OR then decides whether it recognizes the relay cell, by
-  inspecting the payload as described in section 5.1 below.  If the OR
-  recognizes the cell, it processes the contents of the relay cell.
-  Otherwise, it passes the decrypted relay cell along the circuit if
-  the circuit continues.  If the OR at the end of the circuit
-  encounters an unrecognized relay cell, an error has occurred: the OR
-  sends a DESTROY cell to tear down the circuit.
-
-  When a relay cell arrives at an OP, the OP decrypts the payload
-  with AES/CTR as follows:
-        OP receives data cell:
-           For I=N...1,
-               Decrypt with Kb_I, using the sequence number as above.  If the
-               payload is recognized (see section 5.1), then stop and process
-               the payload.
-
-  For more information, see section 5 below.
-
-4.6. CREATE_UDP and CREATED_UDP cells
-
-  Users set up UDP circuits incrementally.  The procedure is similar to that
-  for TCP circuits, as described in section 4.1.  In addition to the TLS
-  connection to the first node, the OP also attempts to open a DTLS
-  connection.  If this succeeds, the OP sends a CREATE_UDP cell, with a
-  payload in the same format as a CREATE cell.  To extend a UDP circuit past
-  the first hop, the OP sends an EXTEND_UDP relay cell (see section 5) which
-  instructs the last node in the circuit to send a CREATE_UDP cell to extend
-  the circuit.
-
-  The relay payload for an EXTEND_UDP relay cell consists of:
-         Address                       [4 bytes]
-         TCP port                      [2 bytes]
-         UDP port                      [2 bytes]
-         Onion skin                    [186 bytes]
-         Identity fingerprint          [20 bytes]
-
-  The address field and ports denote the IPV4 address and ports of the next OR
-  in the circuit.
-
-  The payload for a CREATED_UDP cell or the relay payload for an
-  RELAY_EXTENDED_UDP cell is identical to that of the corresponding CREATED or
-  RELAY_EXTENDED cell.  Both circuits are established using the same key.
-
-  Note that the existence of a UDP circuit implies the
-  existence of a corresponding TCP circuit, sharing keys, sequence numbers,
-  and any other relevant state.
-
-4.6.1 CREATE_FAST_UDP/CREATED_FAST_UDP cells
-
-  As above, the OP must successfully connect using DTLS before attempting to
-  send a CREATE_FAST_UDP cell.  Otherwise, the procedure is the same as in
-  section 4.1.1.
-
-5. Application connections and stream management
-
-5.1. Relay cells
-
-  Within a circuit, the OP and the exit node use the contents of RELAY cells
-  to tunnel end-to-end commands, TCP connections ("Streams"), and UDP packets
-  across circuits.  End-to-end commands and UDP packets can be initiated by
-  either edge; streams are initiated by the OP.
-
-  The payload of each unencrypted RELAY cell consists of:
-        Relay command           [1 byte]
-        'Recognized'            [2 bytes]
-        StreamID                [2 bytes]
-        Digest                  [4 bytes]
-        Length                  [2 bytes]
-        Data                    [498 bytes]
-
-  The relay commands are:
-        1 -- RELAY_BEGIN        [forward]
-        2 -- RELAY_DATA         [forward or backward]
-        3 -- RELAY_END          [forward or backward]
-        4 -- RELAY_CONNECTED    [backward]
-        5 -- RELAY_SENDME       [forward or backward]
-        6 -- RELAY_EXTEND       [forward]
-        7 -- RELAY_EXTENDED     [backward]
-        8 -- RELAY_TRUNCATE     [forward]
-        9 -- RELAY_TRUNCATED    [backward]
-       10 -- RELAY_DROP         [forward or backward]
-       11 -- RELAY_RESOLVE      [forward]
-       12 -- RELAY_RESOLVED     [backward]
-       13 -- RELAY_BEGIN_UDP    [forward]
-       14 -- RELAY_DATA_UDP     [forward or backward]
-       15 -- RELAY_EXTEND_UDP   [forward]
-       16 -- RELAY_EXTENDED_UDP [backward]
-       17 -- RELAY_DROP_UDP     [forward or backward]
-
-  Commands labelled as "forward" must only be sent by the originator
-  of the circuit. Commands labelled as "backward" must only be sent by
-  other nodes in the circuit back to the originator. Commands marked
-  as either can be sent either by the originator or other nodes.
-
-  The 'recognized' field in any unencrypted relay payload is always set to
-  zero. 
-
-  The 'digest' field can have two meanings.  For all cells sent over TLS
-  connections (that is, all commands and all non-UDP RELAY data), it is
-  computed as the first four bytes of the running SHA-1 digest of all the
-  bytes that have been sent reliably and have been destined for this hop of
-  the circuit or originated from this hop of the circuit, seeded from Df or Db
-  respectively (obtained in section 4.2 above), and including this RELAY
-  cell's entire payload (taken with the digest field set to zero).  Cells sent
-  over DTLS connections do not affect this running digest.  Each cell sent
-  over DTLS (that is, RELAY_DATA_UDP and RELAY_DROP_UDP) has the digest field
-  set to the SHA-1 digest of the current RELAY cells' entire payload, with the
-  digest field set to zero.  Coupled with a randomly-chosen streamID, this
-  provides per-cell integrity checking on UDP cells.
-  [If you drop malformed UDP relay cells but don't close the circuit,
-  then this 8 bytes of digest is not as strong as what we get in the
-  TCP-circuit side. Is this a problem? -RD]
-
-  When the 'recognized' field of a RELAY cell is zero, and the digest
-  is correct, the cell is considered "recognized" for the purposes of
-  decryption (see section 4.5 above).
-
-  (The digest does not include any bytes from relay cells that do
-  not start or end at this hop of the circuit. That is, it does not
-  include forwarded data. Therefore if 'recognized' is zero but the
-  digest does not match, the running digest at that node should
-  not be updated, and the cell should be forwarded on.)
-
-  All RELAY cells pertaining to the same tunneled TCP stream have the
-  same streamID.  Such streamIDs are chosen arbitrarily by the OP.  RELAY
-  cells that affect the entire circuit rather than a particular
-  stream use a StreamID of zero.
-
-  All RELAY cells pertaining to the same UDP tunnel have the same streamID.
-  This streamID is chosen randomly by the OP, but cannot be zero.
-
-  The 'Length' field of a relay cell contains the number of bytes in
-  the relay payload which contain real payload data. The remainder of
-  the payload is padded with NUL bytes.
-
-  If the RELAY cell is recognized but the relay command is not
-  understood, the cell must be dropped and ignored. Its contents
-  still count with respect to the digests, though. [Before
-  0.1.1.10, Tor closed circuits when it received an unknown relay
-  command. Perhaps this will be more forward-compatible. -RD]
-
-5.2.1.  Opening UDP tunnels and transferring data
-
-  To open a new anonymized UDP connection, the OP chooses an open
-  circuit to an exit that may be able to connect to the destination
-  address, selects a random streamID not yet used on that circuit,
-  and constructs a RELAY_BEGIN_UDP cell with a payload encoding the address
-  and port of the destination host.  The payload format is:
-
-        ADDRESS | ':' | PORT | [00]
-
-  where  ADDRESS can be a DNS hostname, or an IPv4 address in
-  dotted-quad format, or an IPv6 address surrounded by square brackets;
-  and where PORT is encoded in decimal.
-
-  [What is the [00] for? -NM]
-  [It's so the payload is easy to parse out with string funcs -RD]
-
-  Upon receiving this cell, the exit node resolves the address as necessary.
-  If the address cannot be resolved, the exit node replies with a RELAY_END
-  cell.  (See 5.4 below.)  Otherwise, the exit node replies with a
-  RELAY_CONNECTED cell, whose payload is in one of the following formats:
-      The IPv4 address to which the connection was made [4 octets]
-      A number of seconds (TTL) for which the address may be cached [4 octets]
-   or
-      Four zero-valued octets [4 octets]
-      An address type (6)     [1 octet]
-      The IPv6 address to which the connection was made [16 octets]
-      A number of seconds (TTL) for which the address may be cached [4 octets]
-  [XXXX Versions of Tor before 0.1.1.6 ignore and do not generate the TTL
-  field.  No version of Tor currently generates the IPv6 format.]
-
-  The OP waits for a RELAY_CONNECTED cell before sending any data.
-  Once a connection has been established, the OP and exit node
-  package UDP data in RELAY_DATA_UDP cells, and upon receiving such
-  cells, echo their contents to the corresponding socket.
-  RELAY_DATA_UDP cells sent to unrecognized streams are dropped.
-
-  Relay RELAY_DROP_UDP cells are long-range dummies; upon receiving such
-  a cell, the OR or OP must drop it.
-
-5.3. Closing streams
-
-  UDP tunnels are closed in a fashion corresponding to TCP connections.
-
-6. Flow Control
-
-  UDP streams are not subject to flow control.
-
-7.2. Router descriptor format.
-
-The items' formats are as follows:
-   "router" nickname address ORPort SocksPort DirPort UDPPort
-
-      Indicates the beginning of a router descriptor.  "address" must be
-      an IPv4 address in dotted-quad format. The last three numbers
-      indicate the TCP ports at which this OR exposes
-      functionality. ORPort is a port at which this OR accepts TLS
-      connections for the main OR protocol; SocksPort is deprecated and
-      should always be 0; DirPort is the port at which this OR accepts
-      directory-related HTTP connections; and UDPPort is a port at which
-      this OR accepts DTLS connections for UDP data.  If any port is not
-      supported, the value 0 is given instead of a port number.
-
-Other sections:
-
-What changes need to happen to each node's exit policy to support this? -RD
-
-Switching to UDP means managing the queues of incoming packets better,
-so we don't miss packets. How does this interact with doing large public
-key operations (handshakes) in the same thread? -RD
-
-========================================================================
-COMMENTS
-========================================================================
-
-[16 May 2006]
-
-I don't favor this approach; it makes packet traffic partitioned from
-stream traffic end-to-end.  The architecture I'd like to see is:
-
-  A *All* Tor-to-Tor traffic is UDP/DTLS, unless we need to fall back on
-    TCP/TLS for firewall penetration or something.  (This also gives us an
-    upgrade path for routing through legacy servers.)
-
-  B Stream traffic is handled with end-to-end per-stream acks/naks and
-    retries.  On failure, the data is retransmitted in a new RELAY_DATA cell;
-    a cell isn't retransmitted.
-
-We'll need to do A anyway, to fix our behavior on packet-loss.  Once we've
-done so, B is more or less inevitable, and we can support end-to-end UDP
-traffic "for free".
-
-(Also, there are some details that this draft spec doesn't address.  For
-example, what happens when a UDP packet doesn't fit in a single cell?)
-
--NM
diff --git a/doc/spec/proposals/101-dir-voting.txt b/doc/spec/proposals/101-dir-voting.txt
deleted file mode 100644
index be900a6..0000000
--- a/doc/spec/proposals/101-dir-voting.txt
+++ /dev/null
@@ -1,285 +0,0 @@
-Filename: 101-dir-voting.txt
-Title: Voting on the Tor Directory System
-Version: $Revision$
-Last-Modified: $Date$
-Author: Nick Mathewson
-Created: Nov 2006
-Status: Closed
-Implemented-In: 0.2.0.x
-
-Overview
-
-  This document describes a consensus voting scheme for Tor directories;
-  instead of publishing different network statuses, directories would vote on
-  and publish a single "consensus" network status document.
-
-  This is an open proposal.
-
-Proposal:
-
-0. Scope and preliminaries
-
-  This document describes a consensus voting scheme for Tor directories.
-  Once it's accepted, it should be merged with dir-spec.txt.  Some
-  preliminaries for authority and caching support should be done during
-  the 0.1.2.x series; the main deployment should come during the 0.2.0.x
-  series.
-
-0.1. Goals and motivation: voting.
-
-  The current directory system relies on clients downloading separate
-  network status statements from the caches signed by each directory.
-  Clients download a new statement every 30 minutes or so, choosing to
-  replace the oldest statement they currently have.
-
-  This creates a partitioning problem: different clients have different
-  "most recent" networkstatus sources, and different versions of each
-  (since authorities change their statements often).
-
-  It also creates a scaling problem: most of the downloaded networkstatus
-  are probably quite similar, and the redundancy grows as we add more
-  authorities.
-
-  So if we have clients only download a single multiply signed consensus
-  network status statement, we can:
-       - Save bandwidth.
-       - Reduce client partitioning
-       - Reduce client-side and cache-side storage
-       - Simplify client-side voting code (by moving voting away from the
-         client)
-
-  We should try to do this without:
-       - Assuming that client-side or cache-side clocks are more correct
-         than we assume now.
-       - Assuming that authority clocks are perfectly correct.
-       - Degrading badly if a few authorities die or are offline for a bit.
-
-  We do not have to perform well if:
-      - No clique of more than half the authorities can agree about who
-        the authorities are.
-
-1. The idea.
-
-  Instead of publishing a network status whenever something changes,
-  each authority instead publishes a fresh network status only once per
-  "period" (say, 60 minutes).  Authorities either upload this network
-  status (or "vote") to every other authority, or download every other
-  authority's "vote" (see 3.1 below for discussion on push vs pull).
-
-  After an authority has (or has become convinced that it won't be able to
-  get) every other authority's vote, it deterministically computes a
-  consensus networkstatus, and signs it.  Authorities download (or are
-  uploaded; see 3.1) one another's signatures, and form a multiply signed
-  consensus.  This multiply-signed consensus is what caches cache and what
-  clients download.
-
-  If an authority is down, authorities vote based on what they *can*
-  download/get uploaded.
-
-  If an authority is "a little" down and only some authorities can reach
-  it, authorities try to get its info from other authorities.
-
-  If an authority computes the vote wrong, its signature isn't included on
-  the consensus.
-
-  Clients use a consensus if it is "trusted": signed by more than half the
-  authorities they recognize. If clients can't find any such consensus,
-  they use the most recent trusted consensus they have. If they don't
-  have any trusted consensus, they warn the user and refuse to operate
-  (and if DirServers is not the default, beg the user to adapt the list
-  of authorities).
-
-2. Details.
-
-2.0. Versioning
-
-  All documents generated here have version "3" given in their
-  network-status-version entries.
-
-2.1. Vote specifications
-
-  Votes in v3 are similar to v2 network status documents.  We add these
-  fields to the preamble:
-
-     "vote-status" -- the word "vote".
-
-     "valid-until" -- the time when this authority expects to publish its
-        next vote.
-
-     "known-flags" -- a space-separated list of flags that will sometimes
-        be included on "s" lines later in the vote.
-
-     "dir-source" -- as before, except the "hostname" part MUST be the
-        authority's nickname, which MUST be unique among authorities, and
-        MUST match the nickname in the "directory-signature" entry.
-
-  Authorities SHOULD cache their most recently generated votes so they
-  can persist them across restarts.  Authorities SHOULD NOT generate
-  another document until valid-until has passed.
-
-  Router entries in the vote MUST be sorted in ascending order by router
-  identity digest.  The flags in "s" lines MUST appear in alphabetical
-  order.
-
-  Votes SHOULD be synchronized to half-hour publication intervals (one
-  hour? XXX say more; be more precise.)
-
-  XXXX some way to request older networkstatus docs?
-
-2.2. Consensus directory specifications
-
-  Consensuses are like v3 votes, except for the following fields:
-
-     "vote-status" -- the word "consensus".
-
-     "published" is the latest of all the published times on the votes.
-
-     "valid-until" is the earliest of all the valid-until times on the
-       votes.
-
-     "dir-source" and "fingerprint" and "dir-signing-key" and "contact"
-       are included for each authority that contributed to the vote.
-
-     "vote-digest" for each authority that contributed to the vote,
-       calculated as for the digest in the signature on the vote. [XXX
-       re-English this sentence]
-
-     "client-versions" and "server-versions" are sorted in ascending
-       order based on version-spec.txt.
-
-     "dir-options" and "known-flags" are not included.
-[XXX really? why not list the ones that are used in the consensus?
-For example, right now BadExit is in use, but no servers would be
-labelled BadExit, and it's still worth knowing that it was considered
-by the authorities. -RD]
-
-  The fields MUST occur in the following order:
-     "network-status-version"
-     "vote-status"
-     "published"
-     "valid-until"
-     For each authority, sorted in ascending order of nickname, case-
-     insensitively:
-         "dir-source", "fingerprint", "contact", "dir-signing-key",
-         "vote-digest".
-     "client-versions"
-     "server-versions"
-
-  The signatures at the end of the document appear as multiple instances
-  of directory-signature, sorted in ascending order by nickname,
-  case-insensitively.
-
-  A router entry should be included in the result if it is included by more
-  than half of the authorities (total authorities, not just those whose votes
-  we have).  A router entry has a flag set if it is included by more than
-  half of the authorities who care about that flag.  [XXXX this creates an
-  incentive for attackers to DOS authorities whose votes they don't like.
-  Can we remember what flags people set the last time we saw them? -NM]
-  [Which 'we' are we talking here? The end-users never learn which
-  authority sets which flags. So you're thinking the authorities
-  should record the last vote they saw from each authority and if it's
-  within a week or so, count all the flags that it advertised as 'no'
-  votes? Plausible. -RD]
-
-  The signature hash covers from the "network-status-version" line through
-  the characters "directory-signature" in the first "directory-signature"
-  line.
-
-  Consensus directories SHOULD be rejected if they are not signed by more
-  than half of the known authorities.
-
-2.2.1. Detached signatures
-
-  Assuming full connectivity, every authority should compute and sign the
-  same consensus directory in each period.  Therefore, it isn't necessary to
-  download the consensus computed by each authority; instead, the authorities
-  only push/fetch each others' signatures.  A "detached signature" document
-  contains a single "consensus-digest" entry and one or more
-  directory-signature entries. [XXXX specify more.]
-
-2.3. URLs and timelines
-
-2.3.1. URLs and timeline used for agreement
-
-  An authority SHOULD publish its vote immediately at the start of each voting
-  period.  It does this by making it available at
-     http://<hostname>/tor/status-vote/current/authority.z
-  and sending it in an HTTP POST request to each other authority at the URL
-     http://<hostname>/tor/post/vote
-
-  If, N minutes after the voting period has begun, an authority does not have
-  a current statement from another authority, the first authority retrieves
-  the other's statement.
-
-  Once an authority has a vote from another authority, it makes it available
-  at
-      http://<hostname>/tor/status-vote/current/<fp>.z
-  where <fp> is the fingerprint of the other authority's identity key.
-
-  The consensus network status, along with as many signatures as the server
-  currently knows, should be available at
-      http://<hostname>/tor/status-vote/current/consensus.z
-  All of the detached signatures it knows for consensus status should be
-  available at:
-      http://<hostname>/tor/status-vote/current/consensus-signatures.z
-
-  Once an authority has computed and signed a consensus network status, it
-  should send its detached signature to each other authority in an HTTP POST
-  request to the URL:
-      http://<hostname>/tor/post/consensus-signature
-
-
-  [XXXX Store votes to disk.]
-
-2.3.2. Serving a consensus directory
-
-  Once the authority is done getting signatures on the consensus directory,
-  it should serve it from:
-      http://<hostname>/tor/status/consensus.z
-
-  Caches SHOULD download consensus directories from an authority and serve
-  them from the same URL.
-
-2.3.3. Timeline and synchronization
-
-  [XXXX]
-
-2.4. Distributing routerdescs between authorities
-
-  Consensus will be more meaningful if authorities take steps to make sure
-  that they all have the same set of descriptors _before_ the voting
-  starts.  This is safe, since all descriptors are self-certified and
-  timestamped: it's always okay to replace a signed descriptor with a more
-  recent one signed by the same identity.
-
-  In the long run, we might want some kind of sophisticated process here.
-  For now, since authorities already download one another's networkstatus
-  documents and use them to determine what descriptors to download from one
-  another, we can rely on this existing mechanism to keep authorities up to
-  date.
-
-  [We should do a thorough read-through of dir-spec again to make sure
-  that the authorities converge on which descriptor to "prefer" for
-  each router. Right now the decision happens at the client, which is
-  no longer the right place for it. -RD]
-
-3. Questions and concerns
-
-3.1. Push or pull?
-
-  The URLs above define a push mechanism for publishing votes and consensus
-  signatures via HTTP POST requests, and a pull mechanism for downloading
-  these documents via HTTP GET requests.  As specified, every authority will
-  post to every other.  The "download if no copy has been received" mechanism
-  exists only as a fallback.
-
-4. Migration
-
-     * It would be cool if caches could get ready to download consensus
-       status docs, verify enough signatures, and serve them now.  That way
-       once stuff works all we need to do is upgrade the authorities.  Caches
-       don't need to verify the correctness of the format so long as it's
-       signed (or maybe multisigned?).  We need to make sure that caches back
-       off very quickly from downloading consensus docs until they're
-       actually implemented.
-
diff --git a/doc/spec/proposals/102-drop-opt.txt b/doc/spec/proposals/102-drop-opt.txt
deleted file mode 100644
index 8f6a38a..0000000
--- a/doc/spec/proposals/102-drop-opt.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-Filename: 102-drop-opt.txt
-Title: Dropping "opt" from the directory format
-Version: $Revision$
-Last-Modified: $Date$
-Author: Nick Mathewson
-Created: Jan 2007
-Status: Closed
-Implemented-In: 0.2.0.x
-
-Overview:
-
-  This document proposes a change in the format used to transmit router and
-  directory information.
-
-  This proposal has been accepted, implemented, and merged into dir-spec.txt.
-
-Proposal:
-
-  The "opt" keyword in Tor's directory formats was originally intended to
-  mean, "it is okay to ignore this entry if you don't understand it"; the
-  default behavior has been "discard a routerdesc if it contains entries you
-  don't recognize."
-
-  But so far, every new flag we have added has been marked 'opt'.  It would
-  probably make sense to change the default behavior to "ignore unrecognized
-  fields", and add the statement that clients SHOULD ignore fields they don't
-  recognize.  As a meta-principle, we should say that clients and servers
-  MUST NOT have to understand new fields in order to use directory documents
-  correctly.
-
-  Of course, this will make it impossible to say, "The format has changed a
-  lot; discard this quietly if you don't understand it." We could do that by
-  adding a version field.
-
-Status:
-
-     * We stopped requiring it as of 0.1.2.5-alpha.  We'll stop generating it
-       once earlier formats are obsolete.
-
-
diff --git a/doc/spec/proposals/103-multilevel-keys.txt b/doc/spec/proposals/103-multilevel-keys.txt
deleted file mode 100644
index ef51e18..0000000
--- a/doc/spec/proposals/103-multilevel-keys.txt
+++ /dev/null
@@ -1,206 +0,0 @@
-Filename: 103-multilevel-keys.txt
-Title: Splitting identity key from regularly used signing key.
-Version: $Revision$
-Last-Modified: $Date$
-Author: Nick Mathewson
-Created: Jan 2007
-Status: Closed
-Implemented-In: 0.2.0.x
-
-Overview:
-
-  This document proposes a change in the way identity keys are used, so that
-  highly sensitive keys can be password-protected and seldom loaded into RAM.
-
-  It presents options; it is not yet a complete proposal.
-
-Proposal:
-
-  Replacing a directory authority's identity key in the event of a compromise
-  would be tremendously annoying.  We'd need to tell every client to switch
-  their configuration, or update to a new version with an uploaded list.  So
-  long as some weren't upgraded, they'd be at risk from whoever had
-  compromised the key.
-
-  With this in mind, it's a shame that our current protocol forces us to
-  store identity keys unencrypted in RAM.  We need some kind of signing key
-  stored unencrypted, since we need to generate new descriptors/directories
-  and rotate link and onion keys regularly.  (And since, of course, we can't
-  ask server operators to be on-hand to enter a passphrase every time we
-  want to rotate keys or sign a descriptor.)
-
-  The obvious solution seems to be to have a signing-only key that lives
-  indefinitely (months or longer) and signs descriptors and link keys, and a
-  separate identity key that's used to sign the signing key.  Tor servers
-  could run in one of several modes:
-    1. Identity key stored encrypted.  You need to pick a passphrase when
-       you enable this mode, and re-enter this passphrase every time you
-       rotate the signing key.
-    1'. Identity key stored separate.  You save your identity key to a
-       floppy, and use the floppy when you need to rotate the signing key.
-    2. All keys stored unencrypted.  In this case, we might not want to even
-       *have* a separate signing key.  (We'll need to support no-separate-
-       signing-key mode anyway to keep old servers working.)
-    3. All keys stored encrypted. You need to enter a passphrase to start
-       Tor.
-  (Of course, we might not want to implement all of these.)
-
-  Case 1 is probably most usable and secure, if we assume that people don't
-  forget their passphrases or lose their floppies.  We could mitigate this a
-  bit by encouraging people to PGP-encrypt their passphrases to themselves,
-  or keep a cleartext copy of their secret key secret-split into a few
-  pieces, or something like that.
-
-  Migration presents another difficulty, especially with the authorities.  If
-  we use the current set of identity keys as the new identity keys, we're in
-  the position of having sensitive keys that have been stored on
-  media-of-dubious-encryption up to now.  Also, we need to keep old clients
-  (who will expect descriptors to be signed by the identity keys they know
-  and love, and who will not understand signing keys) happy.
-
-A possible solution:
-
-  One thing to consider is that router identity keys are not very sensitive:
-  if an OR disappears and reappears with a new key, the network treats it as
-  though an old router had disappeared and a new one had joined the network.
-  The Tor network continues unharmed; this isn't a disaster.
-
-  Thus, the ideas above are mostly relevant for authorities.
-
-  The most straightforward solution for the authorities is probably to take
-  advantage of the protocol transition that will come with proposal 101, and
-  introduce a new set of signing _and_ identity keys used only to sign votes
-  and consensus network-status documents.  Signing and identity keys could be
-  delivered to users in a separate, rarely changing "keys" document, so that
-  the consensus network-status documents wouldn't need to include N signing
-  keys, N identity keys, and N certifications.
-
-  Note also that there is no reason that the identity/signing keys used by
-  directory authorities would necessarily have to be the same as the identity
-  keys those authorities use in their capacity as routers.  Decoupling these
-  keys would give directory authorities the following set of keys:
-
-       Directory authority identity:
-           Highly confidential; stored encrypted and/or offline.  Used to
-           identity directory authorities.  Shipped with clients.  Used to
-           sign Directory authority signing keys.
-
-       Directory authority signing key:
-           Stored online, accessible to regular Tor process.  Used to sign
-           votes and consensus directories.  Downloaded as part of a "keys"
-           document.
-
-           [Administrators SHOULD rotate their signing keys every month or
-           two, just to keep in practice and keep from forgetting the
-           password to the authority identity.]
-
-       V1-V2 directory authority identity:
-           Stored online, never changed.  Used to sign legacy network-status
-           and directory documents.
-
-       Router identity:
-           Stored online, seldom changed.  Used to sign server descriptors
-           for this authority in its role as a router.  Implicitly certified
-           by being listed in network-status documents.
-
-       Onion key, link key:
-           As in tor-spec.txt
-
-
-Extensions to Proposal 101.
-
-  Define a new document type, "Key certificate".  It contains the
-  following fields, in order:
-
-    "dir-key-certificate-version": As network-status-version.  Must be
-         "3".
-    "fingerprint": Hex fingerprint, with spaces, based on the directory
-         authority's identity key.
-    "dir-identity-key": The long-term identity key for this authority.
-    "dir-key-published": The time when this directory's signing key was
-         last changed.
-    "dir-key-expires": A time after which this key is no longer valid.
-    "dir-signing-key": As in proposal 101.
-    "dir-key-certification": A signature of the above fields, in order.
-         The signed material extends from the beginning of
-         "dir-key-certicate-version" through the newline after
-         "dir-key-certification".  The identity key is used to generate
-         this signature.
-
-      These elements together constitute a "key certificate".  These are
-      generated offline when starting a v3 authority.  Private identity
-      keys SHOULD be stored offline, encrypted, or both.  A running
-      authority only needs access to the signing key.
-
-      Unlike other keys currently used by Tor, the authority identity
-      keys and directory signing keys MAY be longer than 1024 bits.
-      (They SHOULD be 2048 bits or longer; they MUST NOT be shorter than
-      1024.)
-
-  Vote documents change as follows:
-
-      A key certificate MUST be included in-line in every vote document.  With
-      the exception of "fingerprint", its elements MUST NOT appear in consensus
-      documents.
-
-  Consensus network statuses change as follows:
-
-      Remove dir-signing-key.
-
-      Change "directory-signature" to take a fingerprint of the authority's
-      identity key and a fingerprint of the authority's current signing key
-      rather than the authority's nickname.
-
-      Change "dir-source" to take the a fingerprint of the authority's
-      identity key rather than the authority's nickname or hostname.
-
-  Add a new document type:
-
-      A "keys" document contains all currently known key certificates.
-      All authorities serve it at
-
-          http://<hostname>/tor/status/keys.z
-
-      Caches and clients download the keys document whenever they receive a
-      consensus vote that uses a key they do not recognize.  Caches download
-      from authorities; clients download from caches.
-
-  Processing votes:
-
-      When receiving a vote, authorities check to see if the key
-      certificate for the voter is different from the one they have.  If
-      the key certificate _is_ different, and its dir-key-published is
-      more recent than the most recently known one, and it is
-      well-formed and correctly signed with the correct identity key,
-      then authorities remember it as the new canonical key certificate
-      for that voter.
-
-  A key certificate is invalid if any of the following hold:
-      * The version is unrecognized.
-      * The fingerprint does not match the identity key.
-      * The identity key or the signing key is ill-formed.
-      * The published date is very far in the past or future.
-
-      * The signature is not a valid signature of the key certificate
-        generated with the identity key.
-
-  When processing the signatures on consensus, clients and caches act as
-  follows:
-
-      1. Only consider the directory-signature entries whose identity
-         key hashes match trusted authorities.
-
-      2. If any such entries have signing key hashes that match unknown
-         signing keys, download a new keys document.
-
-      3. For every entry with a known (identity key,signing key) pair,
-         check the signature on the document.
-
-      4. If the document has been signed by more than half of the
-         authorities the client recognizes, treat the consensus as
-         correctly signed.
-
-         If not, but the number entries with known identity keys but
-         unknown signing keys might be enough to make the consensus
-         correctly signed, do not use the consensus, but do not discard
-         it until we have a new keys document.
diff --git a/doc/spec/proposals/104-short-descriptors.txt b/doc/spec/proposals/104-short-descriptors.txt
deleted file mode 100644
index a1c42c8..0000000
--- a/doc/spec/proposals/104-short-descriptors.txt
+++ /dev/null
@@ -1,183 +0,0 @@
-Filename: 104-short-descriptors.txt
-Title: Long and Short Router Descriptors
-Version: $Revision$
-Last-Modified: $Date$
-Author: Nick Mathewson
-Created: Jan 2007
-Status: Closed
-Implemented-In: 0.2.0.x
-
-Overview:
-
-  This document proposes moving unused-by-clients information from regular
-  router descriptors into a new "extra info" router descriptor.
-
-Proposal:
-
-  Some of the costliest fields in the current directory protocol are ones
-  that no client actually uses.  In particular, the "read-history" and
-  "write-history" fields are used only by the authorities for monitoring the
-  status of the network.  If we took them out, the size of a compressed list
-  of all the routers would fall by about 60%.  (No other disposable field
-  would save much more than 2%.)
-
-  We propose to remove these fields from descriptors, and and have them
-  uploaded as a part of a separate signed "extra info" to the authorities.
-  This document will be signed.  A hash of this document will be included in
-  the regular descriptors.
-
-  (We considered another design, where routers would generate and upload a
-  short-form and a long-form descriptor.  Only the short-form descriptor would
-  ever be used by anybody for routing.  The long-form descriptor would be
-  used only for analytics and other tools.   We decided against this because
-  well-behaved tools would need to download short-form descriptors too (as
-  these would be the only ones indexed), and hence get redundant info. Badly
-  behaved tools would download only long-form descriptors, and expose
-  themselves to partitioning attacks.)
-
-Other disposable fields:
-
-  Clients don't need these fields, but removing them doesn't help bandwidth
-  enough to be worthwhile.
-    contact (save about 1%)
-    fingerprint (save about 3%)
-
-  We could represent these fields more succinctly, but removing them would
-  only save 1%.  (!)
-    reject
-    accept
-  (Apparently, exit polices are highly compressible.)
-
-  [Does size-on-disk matter to anybody? Some clients and servers don't
-   have much disk, or have really slow disk (e.g. USB). And we don't
-   store caches compressed right now. -RD]
-
-Specification:
-
-  1. Extra Info Format.
-
-    An "extra info" descriptor contains the following fields:
-
-    "extra-info" Nickname Fingerprint
-        Identifies what router this is an extra info descriptor for.
-        Fingerprint is encoded in hex (using upper-case letters), with
-        no spaces.
-
-    "published" As currently documented in dir-spec.txt.  It MUST match the
-        "published" field of the descriptor published at the same time.
-
-    "read-history"
-    "write-history"
-        As currently documented in dir-spec.txt.  Optional.
-
-    "router-signature" NL Signature NL
-
-        A signature of the PKCS1-padded hash of the entire extra info
-        document, taken from the beginning of the "extra-info" line, through
-        the newline after the "router-signature" line.  An extra info
-        document is not valid unless the signature is performed with the
-        identity key whose digest matches FINGERPRINT.
-
-    The "extra-info" field is required and MUST appear first.  The
-    router-signature field is required and MUST appear last.  All others are
-    optional.  As for other documents, unrecognized fields must be ignored.
-
-  2. Existing formats
-
-     Implementations that use "read-history" and "write-history" SHOULD
-     continue accepting router descriptors that contain them.  (Prior to
-     0.2.0.x, this information was encoded in ordinary router descriptors;
-     in any case they have always been listed as opt, so they should be
-     accepted anyway.)
-
-     Add these fields to router descriptors:
-
-       "extra-info-digest" Digest
-          "Digest" is a hex-encoded digest (using upper-case characters)
-          of the router's extra-info document, as signed in the router's
-          extra-info.  (If this field is absent, no extra-info-digest
-          exists.)
-
-       "caches-extra-info"
-          Present if this router is a directory cache that provides
-          extra-info documents, or an authority that handles extra-info
-          documents.
-
-     (Since implementations before 0.1.2.5-alpha required that the "opt"
-     keyword precede any unrecognized entry, these keys MUST be preceded
-     with "opt" until 0.1.2.5-alpha is obsolete.)
-
-  3. New communications rules
-
-     Servers SHOULD generate and upload one extra-info document after each
-     descriptor they generate and upload; no more, no less.  Servers MUST
-     upload the new descriptor before they upload the new extra-info.
-
-     Authorities receiving an extra-info document SHOULD verify all of the
-     following:
-       * They have a router descriptor for some server with a matching
-         nickname and identity fingerprint.
-       * That server's identity key has been used to sign the extra-info
-         document.
-       * The extra-info-digest field in the router descriptor matches
-         the digest of the extra-info document.
-       * The published fields in the two documents match.
-
-     Authorities SHOULD drop extra-info documents that do not meet these
-     criteria.
-
-     Extra-info documents MAY be uploaded as part of the same HTTP post as
-     the router descriptor, or separately.  Authorities MUST accept both
-     methods.
-
-     Authorities SHOULD try to fetch extra-info documents from one another if
-     they do not have one matching the digest declared in a router
-     descriptor.
-
-     Caches that are running locally with a tool that needs to use extra-info
-     documents MAY download and store extra-info documents.  They should do
-     so when they notice that the recommended descriptor has an
-     extra-info-digest not matching any extra-info document they currently
-     have.  (Caches not running on a host that needs to use extra-info
-     documents SHOULD NOT download or cache them.)
-
-  4. New URLs
-
-     http://<hostname>/tor/extra/d/...
-     http://<hostname>/tor/extra/fp/...
-     http://<hostname>/tor/extra/all[.z]
-        (As for /tor/server/ URLs: supports fetching extra-info documents
-        by their digest, by the fingerprint of their servers, or all
-        at once. When serving by fingerprint, we serve the extra-info
-        that corresponds to the descriptor we would serve by that
-        fingerprint. Only directory authorities are guaranteed to support
-        these URLs.)
-
-     http://<hostname>/tor/extra/authority[.z]
-        (The extra-info document for this router.)
-
-     Extra-info documents are uploaded to the same URLs as regular
-     router descriptors.
-
-Migration:
-
-  For extra info approach:
-     * First:
-       * Authorities should accept extra info, and support serving it.
-       * Routers should upload extra info once authorities accept it.
-       * Caches should support an option to download and cache it, once
-         authorities serve it.
-       * Tools should be updated to use locally cached information.
-         These tools include:
-           lefkada's exit.py script.
-           tor26's noreply script and general directory cache.
-           https://nighteffect.us/tns/ for its graphs
-           and check with or-talk for the rest, once it's time.
-
-     * Set a cutoff time for including bandwidth in router descriptors, so
-       that tools that use bandwidth info know that they will need to fetch
-       extra info documents.
-
-     * Once tools that want bandwidth info support fetching extra info:
-       * Have routers stop including bandwidth info in their router
-         descriptors.
diff --git a/doc/spec/proposals/105-handshake-revision.txt b/doc/spec/proposals/105-handshake-revision.txt
deleted file mode 100644
index f6c209e..0000000
--- a/doc/spec/proposals/105-handshake-revision.txt
+++ /dev/null
@@ -1,325 +0,0 @@
-Filename: 105-handshake-revision.txt
-Title: Version negotiation for the Tor protocol.
-Version: $Revision$
-Last-Modified: $Date$
-Author: Nick Mathewson, Roger Dingledine
-Created: Jan 2007
-Status: Closed
-Implemented-In: 0.2.0.x
-
-Overview:
-
-  This document was extracted from a modified version of tor-spec.txt that we
-  had written before the proposal system went into place.  It adds two new
-  cells types to the Tor link connection setup handshake: one used for
-  version negotiation, and another to prevent MITM attacks.
-
-  This proposal is partially implemented, and partially proceded by
-  proposal 130.
-
-Motivation: Tor versions
-
-   Our *current* approach to versioning the Tor protocol(s) has been as
-   follows:
-     - All changes must be backward compatible.
-     - It's okay to add new cell types, if they would be ignored by previous
-       versions of Tor.
-     - It's okay to add new data elements to cells, if they would be
-       ignored by previous versions of Tor.
-     - For forward compatibility, Tor must ignore cell types it doesn't
-       recognize, and ignore data in those cells it doesn't expect.
-     - Clients can inspect the version of Tor declared in the platform line
-       of a router's descriptor, and use that to learn whether a server
-       supports a given feature.  Servers, however, aren't assumed to all
-       know about each other, and so don't know the version of who they're
-       talking to.
-
-   This system has these problems:
-     - It's very hard to change fundamental aspects of the protocol, like the
-       cell format, the link protocol, any of the various encryption schemes,
-       and so on.
-     - The router-to-router link protocol has remained more-or-less frozen
-       for a long time, since we can't easily have an OR use new features
-       unless it knows the other OR will understand them.
-
-   We need to resolve these problems because:
-     - Our cipher suite is showing its age: SHA1/AES128/RSA1024/DH1024 will
-       not seem like the best idea for all time.
-     - There are many ideas circulating for multiple cell sizes; while it's
-       not obvious whether these are safe, we can't do them at all without a
-       mechanism to permit them.
-     - There are many ideas circulating for alternative circuit building and
-       cell relay rules: they don't work unless they can coexist in the
-       current network.
-     - If our protocol changes a lot, it's hard to describe any coherent
-       version of it: we need to say "the version that Tor versions W through
-       X use when talking to versions Y through Z".  This makes analysis
-       harder.
-
-Motivation: Preventing MITM attacks
-
-   TLS prevents a man-in-the-middle attacker from reading or changing the
-   contents of a communication.  It does not, however, prevent such an
-   attacker from observing timing information.  Since timing attacks are some
-   of the most effective against low-latency anonymity nets like Tor, we
-   should take more care to make sure that we're not only talking to who
-   we think we're talking to, but that we're using the network path we
-   believe we're using.
-
-Motivation: Signed clock information
-
-   It's very useful for Tor instances to know how skewed they are relative
-   to one another.  The only way to find out currently has been to download
-   directory information, and check the Date header--but this is not
-   authenticated, and hence subject to modification on the wire.  Using
-   BEGIN_DIR to create an authenticated directory stream through an existing
-   circuit is better, but that's an extra step and it might be nicer to
-   learn the information in the course of the regular protocol.
-
-Proposal:
-
-1.0. Version numbers
-
-   The node-to-node TLS-based "OR connection" protocol and the multi-hop
-   "circuit" protocol are versioned quasi-independently.
-
-   Of course, some dependencies will continue to exist: Certain versions
-   of the circuit protocol may require a minimum version of the connection
-   protocol to be used.  The connection protocol affects:
-     - Initial connection setup, link encryption, transport guarantees,
-       etc.
-     - The allowable set of cell commands
-     - Allowable formats for cells.
-
-   The circuit protocol determines:
-     - How circuits are established and maintained
-     - How cells are decrypted and relayed
-     - How streams are established and maintained.
-
-   Version numbers are incremented for backward-incompatible protocol changes
-   only.  Backward-compatible changes are generally implemented by adding
-   additional fields to existing structures; implementations MUST ignore
-   fields they do not expect.  Unused portions of cells MUST be set to zero.
-
-   Though versioning the protocol will make it easier to maintain backward
-   compatibility with older versions of Tor, we will nevertheless continue to
-   periodically drop support for older protocols,
-      - to keep the implementation from growing without bound,
-      - to limit the maintenance burden of patching bugs in obsolete Tors,
-      - to limit the testing burden of verifying that many old protocol
-        versions continue to be implemented properly, and
-      - to limit the exposure of the network to protocol versions that are
-        expensive to support.
-
-   The Tor protocol as implemented through the 0.1.2.x Tor series will be
-   called "version 1" in its link protocol and "version 1" in its relay
-   protocol.  Versions of the Tor protocol so old as to be incompatible with
-   Tor 0.1.2.x can be considered to be version 0 of each, and are not
-   supported.
-
-2.1. VERSIONS cells
-
-   When a Tor connection is established, both parties normally send a
-   VERSIONS cell before sending any other cells.  (But see below.)
-
-         VersionsLen          [2 byte]
-         Versions             [VersionsLen bytes]
-
-   "Versions" is a sequence of VersionsLen bytes.  Each value between 1 and
-   127 inclusive represents a single version; current implementations MUST
-   ignore other bytes.  Parties should list all of the versions which they
-   are able and willing to support.  Parties can only communicate if they
-   have some connection protocol version in common.
-
-   Version 0.2.0.x-alpha and earlier don't understand VERSIONS cells,
-   and therefore don't support version negotiation.  Thus, waiting until
-   the other side has sent a VERSIONS cell won't work for these servers:
-   if the other side sends no cells back, it is impossible to tell
-   whether they
-   have sent a VERSIONS cell that has been stalled, or whether they have
-   dropped our own VERSIONS cell as unrecognized.  Therefore, we'll
-   change the TLS negotiation parameters so that old parties can still
-   negotiate, but new parties can recognize each other.  Immediately
-   after a TLS connection has been established, the parties check
-   whether the other side negotiated the connection in an "old" way or a
-   "new" way.  If either party negotiated in the "old" way, we assume a
-   v1 connection.  Otherwise, both parties send VERSIONS cells listing
-   all their supported versions.  Upon receiving the other party's
-   VERSIONS cell, the implementation begins using the highest-valued
-   version common to both cells.  If the first cell from the other party
-   has a recognized command, and is _not_ a VERSIONS cell, we assume a
-   v1 protocol.
-
-   (For more detail on the TLS protocol change, see forthcoming draft
-   proposals from Steven Murdoch.)
-
-   Implementations MUST discard VERSIONS cells that are not the first
-   recognized cells sent on a connection.
-
-   The VERSIONS cell must be sent as a v1 cell (2 bytes of circuitID, 1
-   byte of command, 509 bytes of payload).
-
-   [NOTE: The VERSIONS cell is assigned the command number 7.]
-
-2.2. MITM-prevention and time checking
-
-   If we negotiate a v2 connection or higher, the second cell we send SHOULD
-   be a NETINFO cell.  Implementations SHOULD NOT send NETINFO cells at other
-   times.
-
-   A NETINFO cell contains:
-         Timestamp              [4 bytes]
-         Other OR's address     [variable]
-         Number of addresses    [1 byte]
-         This OR's addresses    [variable]
-
-   Timestamp is the OR's current Unix time, in seconds since the epoch.  If
-   an implementation receives time values from many ORs that
-   indicate that its clock is skewed, it SHOULD try to warn the
-   administrator. (We leave the definition of 'many' intentionally vague
-   for now.)
-
-   Before believing the timestamp in a NETINFO cell, implementations
-   SHOULD compare the time at which they received the cell to the time
-   when they sent their VERSIONS cell.  If the difference is very large,
-   it is likely that the cell was delayed long enough that its
-   contents are out of date.
-
-   Each address contains Type/Length/Value as used in Section 6.4 of
-   tor-spec.txt.  The first address is the one that the party sending
-   the NETINFO cell believes the other has -- it can be used to learn
-   what your IP address is if you have no other hints.
-   The rest of the addresses are the advertised addresses of the party
-   sending the NETINFO cell -- we include them
-   to block a man-in-the-middle attack on TLS that lets an attacker bounce
-   traffic through his own computers to enable timing and packet-counting
-   attacks.
-
-   A Tor instance should use the other Tor's reported address
-   information as part of logic to decide whether to treat a given
-   connection as suitable for extending circuits to a given address/ID
-   combination.  When we get an extend request, we use an
-   existing OR connection if the ID matches, and ANY of the following
-   conditions hold:
-       - The IP matches the requested IP.
-       - We know that the IP we're using is canonical because it was
-         listed in the NETINFO cell.
-       - We know that the IP we're using is canonical because it was
-         listed in the server descriptor.
-
-   [NOTE: The NETINFO cell is assigned the command number 8.]
-
-Discussion: Versions versus feature lists
-
-   Many protocols negotiate lists of available features instead of (or in
-   addition to) protocol versions.  While it's possible that some amount of
-   feature negotiation could be supported in a later Tor, we should prefer to
-   use protocol versions whenever possible, for reasons discussed in
-   the "Anonymity Loves Company" paper.
-
-Discussion: Bytes per version, versions per cell
-
-   This document provides for a one-byte count of how many versions a Tor
-   supports, and allows one byte per version.  Thus, it can only support only
-   254 more versions of the protocol beyond the unallocated v0 and the
-   current v1.  If we ever need to split the protocol into 255 incompatible
-   versions, we've probably screwed up badly somewhere.
-
-   Nevertheless, here are two ways we could support more versions:
-     - Change the version count to a two-byte field that counts the number of
-       _bytes_ used, and use a UTF8-style encoding: versions 0 through 127
-       take one byte to encode, versions 128 through 2047 take two bytes to
-       encode, and so on.  We wouldn't need to parse any version higher than
-       127 right now, since all bytes used to encode higher versions would
-       have their high bit set.
-
-       We'd still have a limit of 380 simultaneously versions that could be
-       declared in any version.  This is probably okay.
-
-     - Decide that if we need to support more versions, we can add a
-       MOREVERSIONS cell that gets sent before the VERSIONS cell.  The spec
-       above requires Tors to ignore unrecognized cell types that they get
-       before the first VERSIONS cell, and still allows version negotiation
-       to
-       succeed.
-
-   [Resolution: Reserve the high bit and the v0 value for later use.  If
-    we ever have more live versions than we can fit in a cell, we've made a
-    bad design decision somewhere along the line.]
-
-Discussion: Reducing round-trips
-
-   It might be appealing to see if we can cram more information in the
-   initial VERSIONS cell.  For example, the contents of NETINFO will pretty
-   soon be sent by everybody before any more information is exchanged, but
-   decoupling them from the version exchange increases round-trips.
-
-   Instead, we could speculatively include handshaking information at
-   the end of a VERSIONS cell, wrapped in a marker to indicate, "if we wind
-   up speaking VERSION 2, here's the NETINFO I'll send.  Otherwise, ignore
-   this."  This could be extended to opportunistically reduce round trips
-   when possible for future versions when we guess the versions right.
-
-   Of course, we'd need to be careful about using a feature like this:
-     - We don't want to include things that are expensive to compute,
-       like PK signatures or proof-of-work.
-     - We don't want to speculate as a mobile client: it may leak our
-       experience with the server in question.
-
-Discussion: Advertising versions in routerdescs and networkstatuses.
-
-   In network-statuses:
-
-     The networkstatus "v" line now has the format:
-        "v" IMPLEMENTATION IMPL-VERSION "Link" LINK-VERSION-LIST
-            "Circuit" CIRCUIT-VERSION-LIST NL
-
-     LINK-VERSION-LIST and CIRCUIT-VERSION-LIST are comma-separated lists of
-     supported version numbers.  IMPLEMENTATION is the name of the
-     implementation of the Tor protocol (e.g., "Tor"), and IMPL-VERSION is the
-     version of the implementation.
-
-     Examples:
-        v Tor 0.2.5.1-alpha Link 1,2,3 Circuit 2,5
-
-        v OtherOR 2000+ Link 3 Circuit 5
-
-     Implementations that release independently of the Tor codebase SHOULD NOT
-     use "Tor" as the value of their IMPLEMENTATION.
-
-     Additional fields on the "v" line MUST be ignored.
-
-   In router descriptors:
-
-     The router descriptor should contain a line of the form,
-       "protocols" "Link" LINK-VERSION-LIST "Circuit" CIRCUIT_VERSION_LIST
-
-     Additional fields on the "protocols" line MUST be ignored.
-
-     [Versions of Tor before 0.1.2.5-alpha rejected router descriptors with
-     unrecognized items; the protocols line should be preceded with an "opt"
-     until these Tors are obsolete.]
-
-Security issues:
-
-   Client partitioning is the big danger when we introduce new versions; if a
-   client supports some very unusual set of protocol versions, it will stand
-   out from others no matter where it goes.  If a server supports an unusual
-   version, it will get a disproportionate amount of traffic from clients who
-   prefer that version.  We can mitigate this somewhat as follows:
-
-     - Do not have clients prefer any protocol version by default until that
-       version is widespread.  (First introduce the new version to servers,
-       and have clients admit to using it only when configured to do so for
-       testing.  Then, once many servers are running the new protocol
-       version, enable its use by default.)
-
-     - Do not multiply protocol versions needlessly.
-
-     - Encourage protocol implementors to implement the same protocol version
-       sets as some popular version of Tor.
-
-     - Disrecommend very old/unpopular versions of Tor via the directory
-       authorities' RecommmendedVersions mechanism, even if it is still
-       technically possible to use them.
-
diff --git a/doc/spec/proposals/106-less-tls-constraint.txt b/doc/spec/proposals/106-less-tls-constraint.txt
deleted file mode 100644
index 35d6bf1..0000000
--- a/doc/spec/proposals/106-less-tls-constraint.txt
+++ /dev/null
@@ -1,113 +0,0 @@
-Filename: 106-less-tls-constraint.txt
-Title: Checking fewer things during TLS handshakes
-Version: $Revision$
-Last-Modified: $Date$
-Author: Nick Mathewson
-Created: 9-Feb-2007
-Status: Closed
-Implemented-In: 0.2.0.x
-
-Overview:
-
-    This document proposes that we relax our requirements on the context of
-    X.509 certificates during initial TLS handshakes.
-
-Motivation:
-
-    Later, we want to try harder to avoid protocol fingerprinting attacks.
-    This means that we'll need to make our connection handshake look closer
-    to a regular HTTPS connection: one certificate on the server side and
-    zero certificates on the client side.  For now, about the best we
-    can do is to stop requiring things during handshake that we don't
-    actually use.
-
-What we check now, and where we check it:
-
- tor_tls_check_lifetime:
-    peer has certificate
-    notBefore <= now <= notAfter
-
- tor_tls_verify:
-    peer has at least one certificate
-    There is at least one certificate in the chain
-    At least one of the certificates in the chain is not the one used to
-        negotiate the connection.  (The "identity cert".)
-    The certificate _not_ used to negotiate the connection has signed the
-        link cert
-
- tor_tls_get_peer_cert_nickname:
-    peer has a certificate.
-    certificate has a subjectName.
-    subjectName has a commonName.
-    commonName consists only of characters in LEGAL_NICKNAME_CHARACTERS. [2]
-
- tor_tls_peer_has_cert:
-    peer has a certificate.
-
- connection_or_check_valid_handshake:
-    tor_tls_peer_has_cert [1]
-    tor_tls_get_peer_cert_nickname [1]
-    tor_tls_verify [1]
-    If nickname in cert is a known, named router, then its identity digest
-        must be as expected.
-    If we initiated the connection, then we got the identity digest we
-        expected.
-
- USEFUL THINGS WE COULD DO:
-
- [1] We could just not force clients to have any certificate at all, let alone
-     an identity certificate.  Internally to the code, we could assign the
-     identity_digest field of these or_connections to a random number, or even
-     not add them to the identity_digest->or_conn map.
- [so if somebody connects with no certs, we let them. and mark them as
- a client and don't treat them as a server. great. -rd]
-
- [2] Instead of using a restricted nickname character set that makes our
-     commonName structure look unlike typical SSL certificates, we could treat
-     the nickname as extending from the start of the commonName up to but not
-     including the first non-nickname character.
-
-     Alternatively, we could stop checking commonNames entirely.  We don't
-     actually _do_ anything based on the nickname in the certificate, so
-     there's really no harm in letting every router have any commonName it
-     wants.
- [this is the better choice -rd]
- [agreed. -nm]
-
-REMAINING WAYS TO RECOGNIZE CLIENT->SERVER CONNECTIONS:
-
- Assuming that we removed the above requirements, we could then (in a later
- release) have clients not send certificates, and sometimes and started
- making our DNs a little less formulaic, client->server OR connections would
- still be recognizable by:
-    having a two-certificate chain sent by the server
-    using a particular set of ciphersuites
-    traffic patterns
-    probing the server later
-
-OTHER IMPLICATIONS:
-
- If we stop verifying the above requirements:
-
-    It will be slightly (but only slightly) more common to connect to a non-Tor
-    server running TLS, and believe that you're talking to a Tor server (until
-    you send the first cell).
-
-    It will be far easier for non-Tor SSL clients to accidentally connect to
-    Tor servers and speak HTTPS or whatever to them.
-
- If, in a later release, we have clients not send certificates, and we make
- DNs less recognizable:
-
-    If clients don't send certs, servers don't need to verify them: win!
-
-    If we remove these restrictions, it will be easier for people to write
-    clients to fuzz our protocol: sorta win!
-
-    If clients don't send certs, they look slightly less like servers.
-
-OTHER SPEC CHANGES:
-
- When a client doesn't give us an identity, we should never extend any
- circuits to it (duh), and we should allow it to set circuit ID however it
- wants.
diff --git a/doc/spec/proposals/107-uptime-sanity-checking.txt b/doc/spec/proposals/107-uptime-sanity-checking.txt
deleted file mode 100644
index b11be89..0000000
--- a/doc/spec/proposals/107-uptime-sanity-checking.txt
+++ /dev/null
@@ -1,56 +0,0 @@
-Filename: 107-uptime-sanity-checking.txt
-Title: Uptime Sanity Checking
-Version: $Revision$
-Last-Modified: $Date$
-Author: Kevin Bauer & Damon McCoy
-Created: 8-March-2007
-Status: Closed
-Implemented-In: 0.2.0.x
-
-Overview:
-
-   This document describes how to cap the uptime that is used when computing
-   which routers are marked as stable such that highly stable routers cannot
-   be displaced by malicious routers that report extremely high uptime
-   values.
-
-   This is similar to how bandwidth is capped at 1.5MB/s.
-
-Motivation:
-
-   It has been pointed out that an attacker can displace all stable nodes and
-   entry guard nodes by reporting high uptimes. This is an easy fix that will
-   prevent highly stable nodes from being displaced.
-
-Security implications:
-
-   It should decrease the effectiveness of routing attacks that report high
-   uptimes while not impacting the normal routing algorithms.
-
-Specification:
-
-  So we could patch Section 3.1 of dir-spec.txt to say:
-
-   "Stable" -- A router is 'Stable' if it is running, valid, not
-   hibernating, and either its uptime is at least the median uptime for
-   known running, valid, non-hibernating routers, or its uptime is at
-   least 30 days. Routers are never called stable if they are running
-   a version of Tor known to drop circuits stupidly.  (0.1.1.10-alpha
-   through 0.1.1.16-rc are stupid this way.)
-
-Compatibility:
-
-   There should be no compatibility issues due to uptime capping.
-
-Implementation:
-
-   Implemented and merged into dir-spec in 0.2.0.0-alpha-dev (r9788).
-
-Discussion:
-
-   Initially, this proposal set the maximum at 60 days, not 30; the 30 day
-   limit and spec wording was suggested by Roger in an or-dev post on 9 March
-   2007.
-
-   This proposal also led to 108-mtbf-based-stability.txt
-
diff --git a/doc/spec/proposals/108-mtbf-based-stability.txt b/doc/spec/proposals/108-mtbf-based-stability.txt
deleted file mode 100644
index 2c66481..0000000
--- a/doc/spec/proposals/108-mtbf-based-stability.txt
+++ /dev/null
@@ -1,90 +0,0 @@
-Filename: 108-mtbf-based-stability.txt
-Title: Base "Stable" Flag on Mean Time Between Failures
-Version: $Revision$
-Last-Modified: $Date$
-Author: Nick Mathewson
-Created: 10-Mar-2007
-Status: Closed
-Implemented-In: 0.2.0.x
-
-Overview:
-
-   This document proposes that we change how directory authorities set the
-   stability flag from inspection of a router's declared Uptime to the
-   authorities' perceived mean time between failure for the router.
-
-Motivation:
-
-   Clients prefer nodes that the authorities call Stable.  This flag is (as
-   of 0.2.0.0-alpha-dev) set entirely based on the node's declared value for
-   uptime.  This creates an opportunity for malicious nodes to declare
-   falsely high uptimes in order to get more traffic.
-
-Spec changes:
-
-   Replace the current rule for setting the Stable flag with:
-
-   "Stable" -- A router is 'Stable' if it is active and its observed Stability
-   for the past month is at or above the median Stability for active routers.
-   Routers are never called stable if they are running a version of Tor
-   known to drop circuits stupidly. (0.1.1.10-alpha through 0.1.1.16-rc
-   are stupid this way.)
-
-   Stability shall be defined as the weighted mean length of the runs
-   observed by a given directory authority.  A run begins when an authority
-   decides that the server is Running, and ends when the authority decides
-   that the server is not Running.  In-progress runs are counted when
-   measuring Stability.  When calculating the mean, runs are weighted by
-   $\alpha ^ t$, where $t$ is time elapsed since the end of the run, and
-   $0 < \alpha < 1$.  Time when an authority is down do not count to the
-   length of the run.
-
-Rejected Alternative:
-
-   "A router's Stability shall be defined as the sum of $\alpha ^ d$ for every
-   $d$ such that the router was considered reachable for the entire day
-   $d$ days ago.
-
-   This allows a simpler implementation: every day, we multiply
-   yesterday's Stability by alpha, and if the router was observed to be
-   available every time we looked today, we add 1.
-
-   Instead of "day", we could pick an arbitrary time unit.  We should
-   pick alpha to be high enough that long-term stability counts, but low
-   enough that the distant past is eventually forgotten.  Something
-   between .8 and .95 seems right.
-
-   (By requiring that routers be up for an entire day to get their
-   stability increased, instead of counting fractions of a day, we
-   capture the notion that stability is more like "probability of
-   staying up for the next hour" than it is like "probability of being
-   up at some randomly chosen time over the next hour."  The former
-   notion of stability is far more relevant for long-lived circuits.)
-
-Limitations:
-
-   Authorities can have false positives and false negatives when trying to
-   tell whether a router is up or down.  So long as these aren't terribly
-   wrong, and so long as they aren't significantly biased, we should be able
-   to use them to estimate stability pretty well.
-
-   Probing approaches like the above could miss short incidents of
-   downtime.  If we use the router's declared uptime, we could detect
-   these: but doing so would penalize routers who reported their uptime
-   accurately.
-
-Implementation:
-
-   For now, the easiest way to store this information at authorities
-   would probably be in some kind of periodically flushed flat file.
-   Later, we could move to Berkeley db or something if we really had to.
-
-   For each router, an authority will need to store:
-     The router ID.
-     Whether the router is up.
-     The time when the current run started, if the router is up.
-     The weighted sum length of all previous runs.
-     The time at which the weighted sum length was last weighted down.
-
-   Servers should probe at random intervals to test whether servers are
-   running.
diff --git a/doc/spec/proposals/109-no-sharing-ips.txt b/doc/spec/proposals/109-no-sharing-ips.txt
deleted file mode 100644
index 1a88b00..0000000
--- a/doc/spec/proposals/109-no-sharing-ips.txt
+++ /dev/null
@@ -1,92 +0,0 @@
-Filename: 109-no-sharing-ips.txt
-Title: No more than one server per IP address.
-Version: $Revision$
-Last-Modified: $Date$
-Author: Kevin Bauer & Damon McCoy
-Created: 9-March-2007
-Status: Closed
-Implemented-In: 0.2.0.x
-
-Overview:
-  This document describes a solution to a Sybil attack vulnerability in the
-  directory servers. Currently, it is possible for a single IP address to
-  host an arbitrarily high number of Tor routers. We propose that the
-  directory servers limit the number of Tor routers that may be registered at
-  a particular IP address to some small (fixed) number, perhaps just one Tor
-  router per IP address.
-
-  While Tor never uses more than one server from a given /16 in the same
-  circuit, an attacker with multiple servers in the same place is still
-  dangerous because he can get around the per-server bandwidth cap that is
-  designed to prevent a single server from attracting too much of the overall
-  traffic.
-
-Motivation:
-  Since it is possible for an attacker to register an arbitrarily large
-  number of Tor routers, it is possible for malicious parties to do this
-  as part of a traffic analysis attack.
-
-Security implications:
-  This countermeasure will increase the number of IP addresses that an
-  attacker must control in order to carry out traffic analysis.
-
-Specification:
-
-  For each IP address, each directory authority tracks the number of routers
-  using that IP address, along with their total observed bandwidth.  If there
-  are more than MAX_SERVERS_PER_IP servers at some IP, the authority should
-  "disable" all but MAX_SERVERS_PER_IP servers.  When choosing which servers
-  to disable, the authority should first disable non-Running servers in
-  increasing order of observed bandwidth, and then should disable Running
-  servers in increasing order of bandwidth.
-
-  [[  We don't actually do this part here. -NM
-
-  If the total observed
-  bandwidth of the remaining non-"disabled" servers exceeds MAX_BW_PER_IP,
-  the authority should "disable" some of the remaining servers until only one
-  server remains, or until the remaining observed bandwidth of non-"disabled"
-  servers is under MAX_BW_PER_IP.
-  ]]
-
-  Servers that are "disabled" MUST be marked as non-Valid and non-Running.
-
-  MAX_SERVERS_PER_IP is 3.
-
-  MAX_BW_PER_IP is 8 MB per s.
-
-Compatibility:
-
-  Upon inspection of a directory server, we found that the following IP
-  addresses have more than one Tor router:
-
-  Scruples    68.5.113.81     ip68-5-113-81.oc.oc.cox.net     443
-  WiseUp      68.5.113.81     ip68-5-113-81.oc.oc.cox.net     9001
-  Unnamed     62.1.196.71     pc01-megabyte-net-arkadiou.megabyte.gr  9001
-  Unnamed     62.1.196.71     pc01-megabyte-net-arkadiou.megabyte.gr  9001
-  Unnamed     62.1.196.71     pc01-megabyte-net-arkadiou.megabyte.gr  9001
-  aurel       85.180.62.138   e180062138.adsl.alicedsl.de     9001
-  sokrates    85.180.62.138   e180062138.adsl.alicedsl.de     9001
-  moria1      18.244.0.188    moria.mit.edu   9001
-  peacetime   18.244.0.188    moria.mit.edu   9100
-
-  There may exist compatibility issues with this proposed fix.  Reasons why
-  more than one server would share an IP address include:
-
-  * Testing. moria1, moria2, peacetime, and other morias all run on one
-    computer at MIT, because that way we get testing. Moria1 and moria2 are
-    run by Roger, and peacetime is run by Nick.
-  * NAT. If there are several servers but they port-forward through the same
-    IP address, ... we can hope that the operators coordinate with each
-    other. Also, we should recognize that while they help the network in
-    terms of increased capacity, they don't help as much as they could in
-    terms of location diversity. But our approach so far has been to take
-    what we can get.
-  * People who have more than 1.5MB/s and want to help out more. For
-    example, for a while Tonga was offering 10MB/s and its Tor server
-    would only make use of a bit of it. So Roger suggested that he run
-    two Tor servers, to use more.
-
-[Note Roger's tweak to this behavior, in
-http://archives.seul.org/or/cvs/Oct-2007/msg00118.html]
-
diff --git a/doc/spec/proposals/110-avoid-infinite-circuits.txt b/doc/spec/proposals/110-avoid-infinite-circuits.txt
deleted file mode 100644
index 1834cd3..0000000
--- a/doc/spec/proposals/110-avoid-infinite-circuits.txt
+++ /dev/null
@@ -1,122 +0,0 @@
-Filename: 110-avoid-infinite-circuits.txt
-Title: Avoiding infinite length circuits
-Version: $Revision$
-Last-Modified: $Date$
-Author: Roger Dingledine
-Created: 13-Mar-2007
-Status: Accepted
-Target: 0.2.1.x
-Implemented-In: 0.2.1.3-alpha
-
-History:
-
-  Revised 28 July 2008 by nickm: set K.
-  Revised 3 July 2008 by nickm: rename from relay_extend to
-     relay_early.  Revise to current migration plan.  Allow K cells
-     over circuit lifetime, not just at start.
-
-Overview:
-
-  Right now, an attacker can add load to the Tor network by extending a
-  circuit an arbitrary number of times. Every cell that goes down the
-  circuit then adds N times that amount of load in overall bandwidth
-  use. This vulnerability arises because servers don't know their position
-  on the path, so they can't tell how many nodes there are before them
-  on the path.
-
-  We propose a new set of relay cells that are distinguishable by
-  intermediate hops as permitting extend cells. This approach will allow
-  us to put an upper bound on circuit length relative to the number of
-  colluding adversary nodes; but there are some downsides too.
-
-Motivation:
-
-  The above attack can be used to generally increase load all across the
-  network, or it can be used to target specific servers: by building a
-  circuit back and forth between two victim servers, even a low-bandwidth
-  attacker can soak up all the bandwidth offered by the fastest Tor
-  servers.
-
-  The general attacks could be used as a demonstration that Tor isn't
-  perfect (leading to yet more media articles about "breaking" Tor), and
-  the targetted attacks will come into play once we have a reputation
-  system -- it will be trivial to DoS a server so it can't pass its
-  reputation checks, in turn impacting security.
-
-Design:
-
-  We should split RELAY cells into two types: RELAY and RELAY_EARLY.
-
-  Only K (say, 10) Relay_early cells can be sent across a circuit, and
-  only relay_early cells are allowed to contain extend requests. We
-  still support obscuring the length of the circuit (if more research
-  shows us what to do), because Alice can choose how many of the K to
-  mark as relay_early. Note that relay_early cells *can* contain any
-  sort of data cell; so in effect it's actually the relay type cells
-  that are restricted. By default, she would just send the first K
-  data cells over the stream as relay_early cells, regardless of their
-  actual type.
-
-  (Note that a circuit that is out of relay_early cells MUST NOT be
-  cannibalized later, since it can't extend.  Note also that it's always okay
-  to use regular RELAY cells when sending non-EXTEND commands targetted at
-  the first hop of a circuit, since there is no intermediate hop to try to
-  learn the relay command type.)
-
-  Each intermediate server would pass on the same type of cell that it
-  received (either relay or relay_early), and the cell's destination
-  will be able to learn whether it's allowed to contain an Extend request.
-
-  If an intermediate server receives more than K relay_early cells, or
-  if it sees a relay cell that contains an extend request, then it
-  tears down the circuit (protocol violation).
-
-Security implications:
-
-  The upside is that this limits the bandwidth amplification factor to
-  K: for an individual circuit to become arbitrary-length, the attacker
-  would need an adversary-controlled node every K hops, and at that
-  point the attack is no worse than if the attacker creates N/K separate
-  K-hop circuits.
-
-  On the other hand, we want to pick a large enough value of K that we
-  don't mind the cap.
-
-  If we ever want to take steps to hide the number of hops in the circuit
-  or a node's position in the circuit, this design probably makes that
-  more complex.
-
-Migration:
-
-  In 0.2.0, servers speaking v2 or later of the link protocol accept
-  RELAY_EARLY cells, and pass them on.  If the next OR in the circuit
-  is not speaking the v2 link protocol, the server relays the cell as
-  a RELAY cell.
-
-  In 0.2.1.3-alpha, clients begin using RELAY_EARLY cells on v2
-  connections.  This functionality can be safely backported to
-  0.2.0.x.  Clients should pick a random number betweeen (say) K and
-  K-2 to send.
-
-  In 0.2.1.3-alpha, servers close any circuit in which more than K
-  relay_early cells are sent.
-
-  Once all versions the do not send RELAY_EARLY cells are obsolete,
-  servers can begin to reject any EXTEND requests not sent in a
-  RELAY_EARLY cell.
-
-Parameters:
-
-  Let K = 8, for no terribly good reason.
-
-Spec:
-
-  [We can formalize this part once we think the design is a good one.]
-
-Acknowledgements:
-
-  This design has been kicking around since Christian Grothoff and I came
-  up with it at PET 2004. (Nathan Evans, Christian Grothoff's student,
-  is working on implementing a fix based on this design in the summer
-  2007 timeframe.)
-
diff --git a/doc/spec/proposals/111-local-traffic-priority.txt b/doc/spec/proposals/111-local-traffic-priority.txt
deleted file mode 100644
index f8a37ef..0000000
--- a/doc/spec/proposals/111-local-traffic-priority.txt
+++ /dev/null
@@ -1,153 +0,0 @@
-Filename: 111-local-traffic-priority.txt
-Title: Prioritizing local traffic over relayed traffic
-Version: $Revision$
-Last-Modified: $Date$
-Author: Roger Dingledine
-Created: 14-Mar-2007
-Status: Closed
-Implemented-In: 0.2.0.x
-
-Overview:
-
-  We describe some ways to let Tor users operate as a relay and enforce
-  rate limiting for relayed traffic without impacting their locally
-  initiated traffic.
-
-Motivation:
-
-  Right now we encourage people who use Tor as a client to configure it
-  as a relay too ("just click the button in Vidalia"). Most of these users
-  are on asymmetric links, meaning they have a lot more download capacity
-  than upload capacity. But if they enable rate limiting too, suddenly
-  they're limited to the same download capacity as upload capacity. And
-  they have to enable rate limiting, or their upstream pipe gets filled
-  up, starts dropping packets, and now their net connection doesn't work
-  even for non-Tor stuff. So they end up turning off the relaying part
-  so they can use Tor (and other applications) again.
-
-  So far this hasn't mattered that much: most of our fast relays are
-  being operated only in relay mode, so the rate limiting makes sense
-  for them. But if we want to be able to attract many more relays in
-  the future, we need to let ordinary users act as relays too.
-
-  Further, as we begin to deploy the blocking-resistance design and we
-  rely on ordinary users to click the "Tor for Freedom" button, this
-  limitation will become a serious stumbling block to getting volunteers
-  to act as bridges.
-
-The problem:
-
-  Tor implements its rate limiting on the 'read' side by only reading
-  a certain number of bytes from the network in each second. If it has
-  emptied its token bucket, it doesn't read any more from the network;
-  eventually TCP notices and stalls until we resume reading. But if we
-  want to have two classes of service, we can't know what class a given
-  incoming cell will be until we look at it, at which point we've already
-  read it.
-
-Some options:
-
-  Option 1: read when our token bucket is full enough, and if it turns
-  out that what we read was local traffic, then add the tokens back into
-  the token bucket. This will work when local traffic load alternates
-  with relayed traffic load; but it's a poor option in general, because
-  when we're receiving both local and relayed traffic, there are plenty
-  of cases where we'll end up with an empty token bucket, and then we're
-  back where we were before.
-
-  More generally, notice that our problem is easy when a given TCP
-  connection either has entirely local circuits or entirely relayed
-  circuits. In fact, even if they are both present, if one class is
-  entirely idle (none of its circuits have sent or received in the past
-  N seconds), we can ignore that class until it wakes up again. So it
-  only gets complex when a single connection contains active circuits
-  of both classes.
-
-  Next, notice that local traffic uses only the entry guards, whereas
-  relayed traffic likely doesn't. So if we're a bridge handling just
-  a few users, the expected number of overlapping connections would be
-  almost zero, and even if we're a full relay the number of overlapping
-  connections will be quite small.
-
-  Option 2: build separate TCP connections for local traffic and for
-  relayed traffic. In practice this will actually only require a few
-  extra TCP connections: we would only need redundant TCP connections
-  to at most the number of entry guards in use.
-
-  However, this approach has some drawbacks. First, if the remote side
-  wants to extend a circuit to you, how does it know which TCP connection
-  to send it on? We would need some extra scheme to label some connections
-  "client-only" during construction. Perhaps we could do this by seeing
-  whether any circuit was made via CREATE_FAST; but this still opens
-  up a race condition where the other side sends a create request
-  immediately. The only ways I can imagine to avoid the race entirely
-  are to specify our preference in the VERSIONS cell, or to add some
-  sort of "nope, not this connection, why don't you try another rather
-  than failing" response to create cells, or to forbid create cells on
-  connections that you didn't initiate and on which you haven't seen
-  any circuit creation requests yet -- this last one would lead to a bit
-  more connection bloat but doesn't seem so bad. And we already accept
-  this race for the case where directory authorities establish new TCP
-  connections periodically to check reachability, and then hope to hang
-  up on them soon after. (In any case this issue is moot for bridges,
-  since each destination will be one-way with respect to extend requests:
-  either receiving extend requests from bridge users or sending extend
-  requests to the Tor server, never both.)
-
-  The second problem with option 2 is that using two TCP connections
-  reveals that there are two classes of traffic (and probably quickly
-  reveals which is which, based on throughput). Now, it's unclear whether
-  this information is already available to the other relay -- he would
-  easily be able to tell that some circuits are fast and some are rate
-  limited, after all -- but it would be nice to not add even more ways to
-  leak that information. Also, it's less clear that an external observer
-  already has this information if the circuits are all bundled together,
-  and for this case it's worth trying to protect it.
-
-  Option 3: tell the other side about our rate limiting rules. When we
-  establish the TCP connection, specify the different policy classes we
-  have configured. Each time we extend a circuit, specify which policy
-  class that circuit should be part of. Then hope the other side obeys
-  our wishes. (If he doesn't, hang up on him.) Besides the design and
-  coordination hassles involved in this approach, there's a big problem:
-  our rate limiting classes apply to all our connections, not just
-  pairwise connections. How does one server we're connected to know how
-  much of our bucket has already been spent by another? I could imagine
-  a complex and inefficient "ok, now you can send me those two more cells
-  that you've got queued" protocol. I'm not sure how else we could do it.
-
-  (Gosh. How could UDP designs possibly be compatible with rate limiting
-  with multiple bucket sizes?)
-
-  Option 4: put both classes of circuits over a single connection, and
-  keep track of the last time we read or wrote a high-priority cell. If
-  it's been less than N seconds, give the whole connection high priority,
-  else give the whole connection low priority.
-
-  Option 5: put both classes of circuits over a single connection, and
-  play a complex juggling game by periodically telling the remote side
-  what rate limits to set for that connection, so you end up giving
-  priority to the right connections but still stick to roughly your
-  intended bandwidthrate and relaybandwidthrate.
-
-  Option 6: ?
-
-Prognosis:
-
-  Nick really didn't like option 2 because of the partitioning questions.
-
-  I've put option 4 into place as of Tor 0.2.0.3-alpha.
-
-  In terms of implementation, it will be easy: just add a time_t to
-  or_connection_t that specifies client_used (used by the initiator
-  of the connection to rate limit it differently depending on how
-  recently the time_t was reset). We currently update client_used
-  in three places:
-    - command_process_relay_cell() when we receive a relay cell for
-      an origin circuit.
-    - relay_send_command_from_edge() when we send a relay cell for
-      an origin circuit.
-    - circuit_deliver_create_cell() when send a create cell.
-  We could probably remove the third case and it would still work,
-  but hey.
-
diff --git a/doc/spec/proposals/112-bring-back-pathlencoinweight.txt b/doc/spec/proposals/112-bring-back-pathlencoinweight.txt
deleted file mode 100644
index e7cc6b4..0000000
--- a/doc/spec/proposals/112-bring-back-pathlencoinweight.txt
+++ /dev/null
@@ -1,165 +0,0 @@
-Filename: 112-bring-back-pathlencoinweight.txt
-Title: Bring Back Pathlen Coin Weight
-Version: $Revision$
-Last-Modified: $Date$
-Author: Mike Perry
-Created:
-Status: Superseded
-Superseded-By: 115
-
-
-Overview:
-
-  The idea is that users should be able to choose a weight which
-  probabilistically chooses their path lengths to be 2 or 3 hops. This
-  weight will essentially be a biased coin that indicates an
-  additional hop (beyond 2) with probability P. The user should be
-  allowed to choose 0 for this weight to always get 2 hops and 1 to
-  always get 3.
-
-  This value should be modifiable from the controller, and should be
-  available from Vidalia.
-
-
-Motivation:
-
-  The Tor network is slow and overloaded. Increasingly often I hear
-  stories about friends and friends of friends who are behind firewalls,
-  annoying censorware, or under surveillance that interferes with their
-  productivity and Internet usage, or chills their speech. These people
-  know about Tor, but they choose to put up with the censorship because
-  Tor is too slow to be usable for them. In fact, to download a fresh,
-  complete copy of levine-timing.pdf for the Anonymity Implications
-  section of this proposal over Tor took me 3 tries.
-
-  There are many ways to improve the speed problem, and of course we
-  should and will implement as many as we can. Johannes's GSoC project
-  and my reputation system are longer term, higher-effort things that
-  will still provide benefit independent of this proposal.
-
-  However, reducing the path length to 2 for those who do not need the
-  (questionable) extra anonymity 3 hops provide not only improves
-  their Tor experience but also reduces their load on the Tor network by
-  33%, and can be done in less than 10 lines of code. That's not just
-  Win-Win, it's Win-Win-Win.
-
-  Furthermore, when blocking resistance measures insert an extra relay
-  hop into the equation, 4 hops will certainly be completely unusable
-  for these users, especially since it will be considerably more
-  difficult to balance the load across a dark relay net than balancing
-  the load on Tor itself (which today is still not without its flaws).
-
-
-Anonymity Implications:
-
-  It has long been established that timing attacks against mixed
-  networks are extremely effective, and that regardless of path
-  length, if the adversary has compromised your first and last
-  hop of your path, you can assume they have compromised your
-  identity for that connection.
-
-  In [1], it is demonstrated that for all but the slowest, lossiest
-  networks, error rates for false positives and false negatives were
-  very near zero. Only for constant streams of traffic over slow and
-  (more importantly) extremely lossy network links did the error rate
-  hit 20%. For loss rates typical to the Internet, even the error rate
-  for slow nodes with constant traffic streams was 13%.
-
-  When you take into account that most Tor streams are not constant,
-  but probably much more like their "HomeIP" dataset, which consists
-  mostly of web traffic that exists over finite intervals at specific
-  times, error rates drop to fractions of 1%, even for the "worst"
-  network nodes.
-
-  Therefore, the user has little benefit from the extra hop, assuming
-  the adversary does timing correlation on their nodes. The real
-  protection is the probability of getting both the first and last hop,
-  and this is constant whether the client chooses 2 hops, 3 hops, or 42.
-
-  Partitioning attacks form another concern. Since Tor uses telescoping
-  to build circuits, it is possible to tell a user is constructing only
-  two hop paths at the entry node. It is questionable if this data is
-  actually worth anything though, especially if the majority of users
-  have easy access to this option, and do actually choose their path
-  lengths semi-randomly.
-
-  Nick has postulated that exits may also be able to tell that you are
-  using only 2 hops by the amount of time between sending their
-  RELAY_CONNECTED cell and the first bit of RELAY_DATA traffic they
-  see from the OP. I doubt that they will be able to make much use
-  of this timing pattern, since it will likely vary widely depending
-  upon the type of node selected for that first hop, and the user's
-  connection rate to that first hop. It is also questionable if this
-  data is worth anything, especially if many users are using this
-  option (and I imagine many will).
-
-  Perhaps most seriously, two hop paths do allow malicious guards
-  to easily fail circuits if they do not extend to their colluding peers
-  for the exit hop. Since guards can detect the number of hops in a
-  path, they could always fail the 3 hop circuits and focus on
-  selectively failing the two hop ones until a peer was chosen.
-
-  I believe currently guards are rotated if circuits fail, which does
-  provide some protection, but this could be changed so that an entry
-  guard is completely abandoned after a certain ratio of extend or
-  general circuit failures with respect to non-failed circuits. This 
-  could possibly be gamed to increase guard turnover, but such a game 
-  would be much more noticeable than an individual guard failing circuits, 
-  though, since it would affect all clients, not just those who chose 
-  a particular guard.
-
-
-Why not fix Pathlen=2?:
-
-  The main reason I am not advocating that we always use 2 hops is that
-  in some situations, timing correlation evidence by itself may not be
-  considered as solid and convincing as an actual, uninterrupted, fully
-  traced path. Are these timing attacks as effective on a real network
-  as they are in simulation? Would an extralegal adversary or authoritarian
-  government even care? In the face of these situation-dependent unknowns,
-  it should be up to the user to decide if this is a concern for them or not.
-
-  It should probably also be noted that even a false positive
-  rate of 1% for a 200k concurrent-user network could mean that for a
-  given node, a given stream could be confused with something like 10
-  users, assuming ~200 nodes carry most of the traffic (ie 1000 users
-  each). Though of course to really know for sure, someone needs to do
-  an attack on a real network, unfortunately.
-
-
-Implementation:
-
-  new_route_len() can be modified directly with a check of the
-  PathlenCoinWeight option (converted to percent) and a call to
-  crypto_rand_int(0,100) for the weighted coin.
-
-  The entry_guard_t structure could have num_circ_failed and
-  num_circ_succeeded members such that if it exceeds N% circuit 
-  extend failure rate to a second hop, it is removed from the entry list. 
-  N should be sufficiently high to avoid churn from normal Tor circuit 
-  failure as determined by TorFlow scans.
-
-  The Vidalia option should be presented as a boolean, to minimize confusion
-  for the user. Something like a radiobutton with:
- 
-   * "I use Tor for Censorship Resistance, not Anonymity. Speed is more
-      important to me than Anonymity."
-   * "I use Tor for Anonymity. I need extra protection at the cost of speed."
-  
-  and then some explanation in the help for exactly what this means, and
-  the risks involved with eliminating the adversary's need for timing attacks 
-  wrt to false positives, etc.
-
-Migration:
-
-  Phase one: Experiment with the proper ratio of circuit failures
-  used to expire garbage or malicious guards via TorFlow.
-
-  Phase two: Re-enable config and modify new_route_len() to add an
-  extra hop if coin comes up "heads".
-
-  Phase three: Make radiobutton in Vidalia, along with help entry
-  that explains in layman's terms the risks involved.
-
-
-[1] http://www.cs.umass.edu/~mwright/papers/levine-timing.pdf
diff --git a/doc/spec/proposals/113-fast-authority-interface.txt b/doc/spec/proposals/113-fast-authority-interface.txt
deleted file mode 100644
index 20cf33e..0000000
--- a/doc/spec/proposals/113-fast-authority-interface.txt
+++ /dev/null
@@ -1,87 +0,0 @@
-Filename: 113-fast-authority-interface.txt
-Title: Simplifying directory authority administration
-Version: $Revision$
-Last-Modified: $Date$
-Author: Nick Mathewson
-Created:
-Status: Superseded
-
-Overview
-
-The problem:
-
-  Administering a directory authority is a pain: you need to go through
-  emails and manually add new nodes as "named".  When bad things come up,
-  you need to mark nodes (or whole regions) as invalid, badexit, etc.
-
-  This means that mostly, authority admins don't: only 2/4 current authority
-  admins actually bind names or list bad exits, and those two have often
-  complained about how annoying it is to do so.
-
-  Worse, name binding is a common path, but it's a pain in the neck: nobody
-  has done it for a couple of months.
-
-Digression: who knows what?
-
-  It's trivial for Tor to automatically keep track of all of the
-  following information about a server:
-    name, fingerprint, IP, last-seen time, first-seen time, declared
-    contact.
-
-  All we need to have the administrator set is:
-    - Is this name/fingerprint pair bound?
-    - Is this fingerprint/IP a bad exit?
-    - Is this fingerprint/IP an invalid node?
-    - Is this fingerprint/IP to be rejected?
-
-  The workflow for authority admins has two parts:
-    - Periodically, go through tor-ops and add new names.  This doesn't
-      need to be done urgently.
-    - Less often, mark badly behaved serves as badly behaved.  This is more
-      urgent.
-
-Possible solution #1: Web-interface for name binding.
-
-  Deprecate use of the tor-ops mailing list; instead, have operators go to a
-  webform and enter their server info.  This would put the information in a
-  standardized format, thus allowing quick, nearly-automated approval and
-  reply.
-
-Possible solution #2: Self-binding names.
-
-  Peter Palfrader has proposed that names be assigned automatically to nodes
-  that have been up and running and valid for a while.
-
-Possible solution #3: Self-maintaining approved-routers file
-
-  Mixminion alpha has a neat feature where whenever a new server is seen,
-  a stub line gets added to a configuration file.  For Tor, it could look
-  something like this:
-
-    ## First seen with this key on 2007-04-21 13:13:14
-    ## Stayed up for at least 12 hours on IP 192.168.10.10
-    #RouterName AAAABBBBCCCCDDDDEFEF
-
-  (Note that the implementation needs to parse commented lines to make sure
-  that it doesn't add duplicates, but that's not so hard.)
-
-  To add a router as named, administrators would only need to uncomment the
-  entry.  This automatically maintained file could be kept separately from a
-  manually maintained one.
-
-  This could be combined with solution #2, such that Tor would do the hard
-  work of uncommenting entries for routers that should get Named, but
-  operators could override its decisions.
-
-Possible solution #4: A separate mailing list for authority operators.
-
-  Right now, the tor-ops list is very high volume.  There should be another
-  list that's only for dealing with problems that need prompt action, like
-  marking a router as !badexit.
-
-Resolution:
-
-  Solution #2 is described in "Proposal 123: Naming authorities
-  automatically create bindings", and that approach is implemented.
-  There are remaining issues in the problem statement above that need
-  their own solutions.
diff --git a/doc/spec/proposals/114-distributed-storage.txt b/doc/spec/proposals/114-distributed-storage.txt
deleted file mode 100644
index e9271fb..0000000
--- a/doc/spec/proposals/114-distributed-storage.txt
+++ /dev/null
@@ -1,441 +0,0 @@
-Filename: 114-distributed-storage.txt
-Title: Distributed Storage for Tor Hidden Service Descriptors
-Version: $Revision$
-Last-Modified: $Date$
-Author: Karsten Loesing
-Created: 13-May-2007
-Status: Closed
-Implemented-In: 0.2.0.x
-
-Change history:
-
-  13-May-2007  Initial proposal
-  14-May-2007  Added changes suggested by Lasse Ã?verlier
-  30-May-2007  Changed descriptor format, key length discussion, typos
-  09-Jul-2007  Incorporated suggestions by Roger, added status of specification
-               and implementation for upcoming GSoC mid-term evaluation
-  11-Aug-2007  Updated implementation statuses, included non-consecutive
-               replication to descriptor format
-  20-Aug-2007  Renamed config option HSDir as HidServDirectoryV2
-  02-Dec-2007  Closed proposal
-
-Overview:
-
-  The basic idea of this proposal is to distribute the tasks of storing and
-  serving hidden service descriptors from currently three authoritative
-  directory nodes among a large subset of all onion routers. The three
-  reasons to do this are better robustness (availability), better
-  scalability, and improved security properties. Further,
-  this proposal suggests changes to the hidden service descriptor format to
-  prevent new security threats coming from decentralization and to gain even
-  better security properties.
-
-Status:
-
-  As of December 2007, the new hidden service descriptor format is implemented
-  and usable. However, servers and clients do not yet make use of descriptor
-  cookies, because there are open usability issues of this feature that might
-  be resolved in proposal 121. Further, hidden service directories do not
-  perform replication by themselves, because (unauthorized) replica fetch
-  requests would allow any attacker to fetch all hidden service descriptors in
-  the system. As neither issue is critical to the functioning of v2
-  descriptors and their distribution, this proposal is considered as Closed.
-  
-Motivation:
-
-  The current design of hidden services exhibits the following performance and
-  security problems:
-
-  First, the three hidden service authoritative directories constitute a
-  performance bottleneck in the system. The directory nodes are responsible for
-  storing and serving all hidden service descriptors. As of May 2007 there are
-  about 1000 descriptors at a time, but this number is assumed to increase in
-  the future. Further, there is no replication protocol for descriptors between
-  the three directory nodes, so that hidden services must ensure the
-  availability of their descriptors by manually publishing them on all
-  directory nodes. Whenever a fourth or fifth hidden service authoritative
-  directory is added, hidden services will need to maintain an equally
-  increasing number of replicas. These scalability issues have an impact on the
-  current usage of hidden services and put an even higher burden on the
-  development of new kinds of applications for hidden services that might
-  require storing even more descriptors.
-
-  Second, besides posing a limitation to scalability, storing all hidden
-  service descriptors on three directory nodes also constitutes a security
-  risk. The directory node operators could easily analyze the publish and fetch
-  requests to derive information on service activity and usage and read the
-  descriptor contents to determine which onion routers work as introduction
-  points for a given hidden service and need to be attacked or threatened to
-  shut it down. Furthermore, the contents of a hidden service descriptor offer
-  only minimal security properties to the hidden service. Whoever gets aware of
-  the service ID can easily find out whether the service is active at the
-  moment and which introduction points it has. This applies to (former)
-  clients, (former) introduction points, and of course to the directory nodes.
-  It requires only to request the descriptor for the given service ID, which
-  can be performed by anyone anonymously.
-
-  This proposal suggests two major changes to approach the described
-  performance and security problems:
-
-  The first change affects the storage location for hidden service descriptors.
-  Descriptors are distributed among a large subset of all onion routers instead
-  of three fixed directory nodes. Each storing node is responsible for a subset
-  of descriptors for a limited time only. It is not able to choose which
-  descriptors it stores at a certain time, because this is determined by its
-  onion ID which is hard to change frequently and in time (only routers which
-  are stable for a given time are accepted as storing nodes). In order to
-  resist single node failures and untrustworthy nodes, descriptors are
-  replicated among a certain number of storing nodes. A first replication
-  protocol makes sure that descriptors don't get lost when the node population
-  changes; therefore, a storing node periodically requests the descriptors from
-  its siblings. A second replication protocol distributes descriptors among
-  non-consecutive nodes of the ID ring to prevent a group of adversaries from
-  generating new onion keys until they have consecutive IDs to create a 'black
-  hole' in the ring and make random services unavailable. Connections to
-  storing nodes are established by extending existing circuits by one hop to
-  the storing node. This also ensures that contents are encrypted. The effect
-  of this first change is that the probability that a single node operator
-  learns about a certain hidden service is very small and that it is very hard
-  to track a service over time, even when it collaborates with other node
-  operators.
-  
-  The second change concerns the content of hidden service descriptors.
-  Obviously, security problems cannot be solved only by decentralizing storage;
-  in fact, they could also get worse if done without caution. At first, a
-  descriptor ID needs to change periodically in order to be stored on changing
-  nodes over time. Next, the descriptor ID needs to be computable only for the
-  service's clients, but should be unpredictable for all other nodes. Further,
-  the storing node needs to be able to verify that the hidden service is the
-  true originator of the descriptor with the given ID even though it is not a
-  client. Finally, a storing node should learn as little information as
-  necessary by storing a descriptor, because it might not be as trustworthy as
-  a directory node; for example it does not need to know the list of
-  introduction points. Therefore, a second key is applied that is only known to
-  the hidden service provider and its clients and that is not included in the
-  descriptor. It is used to calculate descriptor IDs and to encrypt the
-  introduction points. This second key can either be given to all clients
-  together with the hidden service ID, or to a group or a single client as
-  an authentication token. In the future this second key could be the result of
-  some key agreement protocol between the hidden service and one or more
-  clients. A new text-based format is proposed for descriptors instead of an
-  extension of the existing binary format for reasons of future extensibility.
-
-Design:
-
-  The proposed design is described by the required changes to the current
-  design. These requirements are grouped by content, rather than by affected
-  specification documents or code files, and numbered for reference below.
-
-  Hidden service clients, servers, and directories:
-
-  /1/ Create routing list
-
-    All participants can filter the consensus status document received from the
-    directory authorities to one routing list containing only those servers
-    that store and serve hidden service descriptors and which are running for
-    at least 24 hours. A participant only trusts its own routing list and never
-    learns about routing information from other parties.
-
-  /2/ Determine responsible hidden service directory
-
-    All participants can determine the hidden service directory that is
-    responsible for storing and serving a given ID, as well as the hidden
-    service directories that replicate its content. Every hidden service
-    directory is responsible for the descriptor IDs in the interval from
-    its predecessor, exclusive, to its own ID, inclusive. Further, a hidden
-    service directory holds replicas for its n predecessors, where n denotes
-    the number of consecutive replicas. (requires /1/)
-
-  [/3/ and /4/ were requirements to use BEGIN_DIR cells for directory
-   requests which have not been fulfilled in the course of the implementation
-   of this proposal, but elsewhere.]
-
-  Hidden service directory nodes:
-    
-  /5/ Advertise hidden service directory functionality
-
-    Every onion router that has its directory port open can decide whether it
-    wants to store and serve hidden service descriptors by setting a new config
-    option "HidServDirectoryV2" 0|1 to 1. An onion router with this config
-    option being set includes the flag "hidden-service-dir" in its router
-    descriptors that it sends to directory authorities.
-
-  /6/ Accept v2 publish requests, parse and store v2 descriptors
-
-    Hidden service directory nodes accept publish requests for hidden service
-    descriptors and store them to their local memory. (It is not necessary to
-    make descriptors persistent, because after disconnecting, the onion router
-    would not be accepted as storing node anyway, because it has not been
-    running for at least 24 hours.) All requests and replies are formatted as
-    HTTP messages. Requests are directed to the router's directory port and are
-    contained within BEGIN_DIR cells. A hidden service directory node stores a
-    descriptor only when it thinks that it is responsible for storing that
-    descriptor based on its own routing table. Every hidden service directory
-    node is responsible for the descriptor IDs in the interval of its n-th
-    predecessor in the ID circle up to its own ID (n denotes the number of
-    consecutive replicas). (requires /1/)
-
-  /7/ Accept v2 fetch requests
-
-    Same as /6/, but with fetch requests for hidden service descriptors.
-    (requires /2/)
-
-  /8/ Replicate descriptors with neighbors
-
-    A hidden service directory node replicates descriptors from its two
-    predecessors by downloading them once an hour. Further, it checks its
-    routing table periodically for changes. Whenever it realizes that a
-    predecessor has left the network, it establishes a connection to the new
-    n-th predecessor and requests its stored descriptors in the interval of its
-    (n+1)-th predecessor and the requested n-th predecessor. Whenever it
-    realizes that a new onion router has joined with an ID higher than its
-    former n-th predecessor, it adds it to its predecessors and discards all
-    descriptors in the interval of its (n+1)-th and its n-th predecessor.
-    (requires /1/)
-
-    [Dec 02: This function has not been implemented, because arbitrary nodes
-     what have been able to download the entire set of v2 descriptors. An
-     authorized replication request would be necessary. For the moment, the
-     system runs without any directory-side replication. -KL]
-
-  Authoritative directory nodes:
-
-  /9/ Confirm a router's hidden service directory functionality
-
-    Directory nodes include a new flag "HSDir" for routers that decided to
-    provide storage for hidden service descriptors and that are running for at
-    least 24 hours. The last requirement prevents a node from frequently
-    changing its onion key to become responsible for an identifier it wants to
-    target.
-
-  Hidden service provider:
-
-  /10/ Configure v2 hidden service
-
-    Each hidden service provider that has set the config option
-    "PublishV2HidServDescriptors" 0|1 to 1 is configured to publish v2
-    descriptors and conform to the v2 connection establishment protocol. When
-    configuring a hidden service, a hidden service provider checks if it has
-    already created a random secret_cookie and a hostname2 file; if not, it
-    creates both of them. (requires /2/)
-
-  /11/ Establish introduction points with fresh key
-
-    If configured to publish only v2 descriptors and no v0/v1 descriptors any
-    more, a hidden service provider that is setting up the hidden service at
-    introduction points does not pass its own public key, but the public key
-    of a freshly generated key pair. It also includes these fresh public keys
-    in the hidden service descriptor together with the other introduction point
-    information. The reason is that the introduction point does not need to and
-    therefore should not know for which hidden service it works, so as to
-    prevent it from tracking the hidden service's activity. (If a hidden
-    service provider supports both, v0/v1 and v2 descriptors, v0/v1 clients
-    rely on the fact that all introduction points accept the same public key,
-    so that this new feature cannot be used.)
-
-  /12/ Encode v2 descriptors and send v2 publish requests
-
-    If configured to publish v2 descriptors, a hidden service provider
-    publishes a new descriptor whenever its content changes or a new
-    publication period starts for this descriptor. If the current publication
-    period would only last for less than 60 minutes (= 2 x 30 minutes to allow
-    the server to be 30 minutes behind and the client 30 minutes ahead), the
-    hidden service provider publishes both a current descriptor and one for
-    the next period. Publication is performed by sending the descriptor to all
-    hidden service directories that are responsible for keeping replicas for
-    the descriptor ID. This includes two non-consecutive replicas that are
-    stored at 3 consecutive nodes each. (requires /1/ and /2/)
-
-  Hidden service client:
-
-  /13/ Send v2 fetch requests
-
-    A hidden service client that has set the config option
-    "FetchV2HidServDescriptors" 0|1 to 1 handles SOCKS requests for v2 onion
-    addresses by requesting a v2 descriptor from a randomly chosen hidden
-    service directory that is responsible for keeping replica for the
-    descriptor ID. In total there are six replicas of which the first and the
-    last three are stored on consecutive nodes. The probability of picking one
-    of the three consecutive replicas is 1/6, 2/6, and 3/6 to incorporate the
-    fact that the availability will be the highest on the node with next higher
-    ID. A hidden service client relies on the hidden service provider to store
-    two sets of descriptors to compensate clock skew between service and
-    client. (requires /1/ and /2/)
-
-  /14/ Process v2 fetch reply and parse v2 descriptors
-
-    A hidden service client that has sent a request for a v2 descriptor can
-    parse it and store it to the local cache of rendezvous service descriptors.
-
-  /15/ Establish connection to v2 hidden service
-
-    A hidden service client can establish a connection to a hidden service
-    using a v2 descriptor. This includes using the secret cookie for decrypting
-    the introduction points contained in the descriptor. When contacting an
-    introduction point, the client does not use the public key of the hidden
-    service provider, but the freshly-generated public key that is included in
-    the hidden service descriptor. Whether or not a fresh key is used instead
-    of the key of the hidden service depends on the available protocol versions
-    that are included in the descriptor; by this, connection establishment is
-    to a certain extend decoupled from fetching the descriptor.
-
-  Hidden service descriptor:
-
-  (Requirements concerning the descriptor format are contained in /6/ and /7/.)
-  
-    The new v2 hidden service descriptor format looks like this:
-
-      onion-address = h(public-key) + cookie
-      descriptor-id = h(h(public-key) + h(time-period + cookie + relica))
-      descriptor-content = {
-        descriptor-id,
-        version,
-        public-key,
-        h(time-period + cookie + replica),
-        timestamp,
-        protocol-versions,
-        { introduction-points } encrypted with cookie
-      } signed with private-key
-
-    The "descriptor-id" needs to change periodically in order for the
-    descriptor to be stored on changing nodes over time. It may only be
-    computable by a hidden service provider and all of his clients to prevent
-    unauthorized nodes from tracking the service activity by periodically
-    checking whether there is a descriptor for this service. Finally, the
-    hidden service directory needs to be able to verify that the hidden service
-    provider is the true originator of the descriptor with the given ID.
-    
-    Therefore, "descriptor-id" is derived from the "public-key" of the hidden
-    service provider, the current "time-period" which changes every 24 hours,
-    a secret "cookie" shared between hidden service provider and clients, and
-    a "replica" denoting the number of this non-consecutive replica. (The
-    "time-period" is constructed in a way that time periods do not change at
-    the same moment for all descriptors by deriving a value between 0:00 and
-    23:59 hours from h(public-key) and making the descriptors of this hidden
-    service provider expire at that time of the day.) The "descriptor-id" is
-    defined to be 160 bits long. [extending the "descriptor-id" length
-    suggested by LÃ?]
-    
-    Only the hidden service provider and the clients are able to generate
-    future "descriptor-ID"s. Hence, the "onion-address" is extended from now 
-    the hash value of "public-key" by the secret "cookie". The "public-key" is
-    determined to be 80 bits long, whereas the "cookie" is dimensioned to be
-    120 bits long. This makes a total of 200 bits or 40 base32 chars, which is
-    quite a lot to handle for a human, but necessary to provide sufficient
-    protection against an adversary from generating a key pair with same
-    "public-key" hash or guessing the "cookie".
-    
-    A hidden service directory can verify that a descriptor was created by the
-    hidden service provider by checking if the "descriptor-id" corresponds to
-    the "public-key" and if the signature can be verified with the
-    "public-key".
-
-    The "introduction-points" that are included in the descriptor are encrypted
-    using the same "cookie" that is shared between hidden service provider and
-    clients. [correction to use another key than h(time-period + cookie) as
-    encryption key for introduction points made by LÃ?]
-
-    A new text-based format is proposed for descriptors instead of an extension
-    of the existing binary format for reasons of future extensibility.
-
-Security implications:
-
-  The security implications of the proposed changes are grouped by the roles of
-  nodes that could perform attacks or on which attacks could be performed.
-
-  Attacks by authoritative directory nodes
-
-    Authoritative directory nodes are no longer the single places in the
-    network that know about a hidden service's activity and introduction
-    points. Thus, they cannot perform attacks using this information, e.g.
-    track a hidden service's activity or usage pattern or attack its
-    introduction points. Formerly, it would only require a single corrupted
-    authoritative directory operator to perform such an attack.
-
-  Attacks by hidden service directory nodes
-
-    A hidden service directory node could misuse a stored descriptor to track a
-    hidden service's activity and usage pattern by clients. Though there is no
-    countermeasure against this kind of attack, it is very expensive to track a
-    certain hidden service over time. An attacker would need to run a large
-    number of stable onion routers that work as hidden service directory nodes
-    to have a good probability to become responsible for its changing
-    descriptor IDs. For each period, the probability is:
-
-      1-(N-c choose r)/(N choose r) for N-c>=r and 1 otherwise, with N
-      as total
-      number of hidden service directories, c as compromised nodes, and r as
-      number of replicas
-
-    The hidden service directory nodes could try to make a certain hidden
-    service unavailable to its clients. Therefore, they could discard all
-    stored descriptors for that hidden service and reply to clients that there
-    is no descriptor for the given ID or return an old or false descriptor
-    content. The client would detect a false descriptor, because it could not
-    contain a correct signature. But an old content or an empty reply could
-    confuse the client. Therefore, the countermeasure is to replicate
-    descriptors among a small number of hidden service directories, e.g. 5.
-    The probability of a group of collaborating nodes to make a hidden service
-    completely unavailable is in each period:
-
-      (c choose r)/(N choose r) for c>=r and N>=r, and 0 otherwise,
-      with N as total
-      number of hidden service directories, c as compromised nodes, and r as
-      number of replicas
-
-    A hidden service directory could try to find out which introduction points
-    are working on behalf of a hidden service. In contrast to the previous
-    design, this is not possible anymore, because this information is encrypted
-    to the clients of a hidden service.
-
-  Attacks on hidden service directory nodes
-
-    An anonymous attacker could try to swamp a hidden service directory with
-    false descriptors for a given descriptor ID. This is prevented by requiring
-    that descriptors are signed.
-
-    Anonymous attackers could swamp a hidden service directory with correct
-    descriptors for non-existing hidden services. There is no countermeasure
-    against this attack. However, the creation of valid descriptors is more
-    expensive than verification and storage in local memory. This should make
-    this kind of attack unattractive.
-
-  Attacks by introduction points
-
-    Current or former introduction points could try to gain information on the
-    hidden service they serve. But due to the fresh key pair that is used by
-    the hidden service, this attack is not possible anymore.
-
-  Attacks by clients
-
-    Current or former clients could track a hidden service's activity, attack
-    its introduction points, or determine the responsible hidden service
-    directory nodes and attack them. There is nothing that could prevent them
-    from doing so, because honest clients need the full descriptor content to
-    establish a connection to the hidden service. At the moment, the only
-    countermeasure against dishonest clients is to change the secret cookie and
-    pass it only to the honest clients.
-
-Compatibility:
-
-  The proposed design is meant to replace the current design for hidden service
-  descriptors and their storage in the long run.
-
-  There should be a first transition phase in which both, the current design
-  and the proposed design are served in parallel. Onion routers should start
-  serving as hidden service directories, and hidden service providers and
-  clients should make use of the new design if both sides support it. Hidden
-  service providers should be allowed to publish descriptors of the current
-  format in parallel, and authoritative directories should continue storing and
-  serving these descriptors.
-
-  After the first transition phase, hidden service providers should stop
-  publishing descriptors on authoritative directories, and hidden service
-  clients should not try to fetch descriptors from the authoritative
-  directories. However, the authoritative directories should continue serving
-  hidden service descriptors for a second transition phase. As of this point,
-  all v2 config options should be set to a default value of 1.
-
-  After the second transition phase, the authoritative directories should stop
-  serving hidden service descriptors.
-
diff --git a/doc/spec/proposals/115-two-hop-paths.txt b/doc/spec/proposals/115-two-hop-paths.txt
deleted file mode 100644
index ee10d94..0000000
--- a/doc/spec/proposals/115-two-hop-paths.txt
+++ /dev/null
@@ -1,387 +0,0 @@
-Filename: 115-two-hop-paths.txt
-Title: Two Hop Paths
-Version: $Revision$
-Last-Modified: $Date$
-Author: Mike Perry
-Created:
-Status: Dead
-Supersedes: 112
-
-
-Overview:
-
-  The idea is that users should be able to choose if they would like
-  to have either two or three hop paths through the tor network. 
-
-  Let us be clear: the users who would choose this option should be
-  those that are concerned with IP obfuscation only: ie they would not be
-  targets of a resource-intensive multi-node attack. It is sometimes said
-  that these users should find some other network to use other than Tor.
-  This is a foolish suggestion: more users improves security of everyone,
-  and the current small userbase size is a critical hindrance to
-  anonymity, as is discussed below and in [1].
-
-  This value should be modifiable from the controller, and should be
-  available from Vidalia.
-
-
-Motivation:
-
-  The Tor network is slow and overloaded. Increasingly often I hear
-  stories about friends and friends of friends who are behind firewalls,
-  annoying censorware, or under surveillance that interferes with their
-  productivity and Internet usage, or chills their speech. These people
-  know about Tor, but they choose to put up with the censorship because
-  Tor is too slow to be usable for them. In fact, to download a fresh,
-  complete copy of levine-timing.pdf for the Theoretical Argument
-  section of this proposal over Tor took me 3 tries.
-
-  Furthermore, the biggest current problem with Tor's anonymity for
-  those who really need it is not someone attacking the network to
-  discover who they are. It's instead the extreme danger that so few
-  people use Tor because it's so slow, that those who do use it have
-  essentially no confusion set.
-
-  The recent case where the professor and the rogue Tor user were the
-  only Tor users on campus, and thus suspected in an incident involving
-  Tor and that University underscores this point: "That was why the police
-  had come to see me. They told me that only two people on our campus were
-  using Tor: me and someone they suspected of engaging in an online scam.
-  The detectives wanted to know whether the other user was a former
-  student of mine, and why I was using Tor"[1].
-
-  Not only does Tor provide no anonymity if you use it to be anonymous
-  but are obviously from a certain institution, location or circumstance,
-  it is also dangerous to use Tor for risk of being accused of having
-  something significant enough to hide to be willing to put up with
-  the horrible performance as opposed to using some weaker alternative.
-
-  There are many ways to improve the speed problem, and of course we
-  should and will implement as many as we can. Johannes's GSoC project
-  and my reputation system are longer term, higher-effort things that
-  will still provide benefit independent of this proposal.
-
-  However, reducing the path length to 2 for those who do not need the
-  extra anonymity 3 hops provide not only improves their Tor experience
-  but also reduces their load on the Tor network by 33%, and should
-  increase adoption of Tor by a good deal. That's not just Win-Win, it's
-  Win-Win-Win.
-
-
-Who will enable this option?
-
-  This is the crux of the proposal. Admittedly, there is some anonymity
-  loss and some degree of decreased investment required on the part of
-  the adversary to attack 2 hop users versus 3 hop users, even if it is
-  minimal and limited mostly to up-front costs and false positives.
-
-  The key questions are:
-
-  1. Are these users in a class such that their risk is significantly
-     less than the amount of this anonymity loss?
-
-  2. Are these users able to identify themselves?
-
-  Many many users of Tor are not at risk for an adversary capturing c/n
-  nodes of the network just to see what they do. These users use Tor to
-  circumvent aggressive content filters, or simply to keep their IP out of
-  marketing and search engine databases. Most content filters have no
-  interest in running Tor nodes to catch violators, and marketers
-  certainly would never consider such a thing, both on a cost basis and a
-  legal one.
-
-  In a sense, this represents an alternate threat model against these
-  users who are not at risk for Tor's normal threat model.
-
-  It should be evident to these users that they fall into this class. All
-  that should be needed is a radio button
-
-   * "I use Tor for local content filter circumvention and/or IP obfuscation, 
-      not anonymity. Speed is more important to me than high anonymity. 
-      No one will make considerable efforts to determine my real IP."
-   * "I use Tor for anonymity and/or national-level, legally enforced 
-      censorship. It is possible effort will be taken to identify 
-      me, including but not limited to network surveillance. I need more 
-      protection."
- 
-  and then some explanation in the help for exactly what this means, and
-  the risks involved with eliminating the adversary's need for timing
-  attacks with respect to false positives. Ultimately, the decision is a
-  simple one that can be made without this information, however. The user
-  does not need Paul Syverson to instruct them on the deep magic of Onion
-  Routing to make this decision. They just need to know why they use Tor.
-  If they use it just to stay out of marketing databases and/or bypass a
-  local content filter, two hops is plenty. This is likely the vast
-  majority of Tor users, and many non-users we would like to bring on 
-  board.
-
-  So, having established this class of users, let us now go on to
-  examine theoretical and practical risks we place them at, and determine
-  if these risks violate the users needs, or introduce additional risk 
-  to node operators who may be subject to requests from law enforcement
-  to track users who need 3 hops, but use 2 because they enjoy the
-  thrill of russian roulette.
-
-
-Theoretical Argument:
-
-  It has long been established that timing attacks against mixed
-  and onion networks are extremely effective, and that regardless 
-  of path length, if the adversary has compromised your first and 
-  last hop of your path, you can assume they have compromised your
-  identity for that connection.
-
-  In fact, it was demonstrated that for all but the slowest, lossiest
-  networks, error rates for false positives and false negatives were
-  very near zero[2]. Only for constant streams of traffic over slow and
-  (more importantly) extremely lossy network links did the error rate
-  hit 20%. For loss rates typical to the Internet, even the error rate
-  for slow nodes with constant traffic streams was 13%.
-
-  When you take into account that most Tor streams are not constant,
-  but probably much more like their "HomeIP" dataset, which consists
-  mostly of web traffic that exists over finite intervals at specific
-  times, error rates drop to fractions of 1%, even for the "worst"
-  network nodes.
-
-  Therefore, the user has little benefit from the extra hop, assuming
-  the adversary does timing correlation on their nodes. Since timing
-  correlation is simply an implementation issue and is most likely
-  a single up-front cost (and one that is like quite a bit cheaper
-  than the cost of the machines purchased to host the nodes to mount
-  an attack), the real protection is the low probability of getting
-  both the first and last hop of a client's stream.
-
-
-Practical Issues:
-
-  Theoretical issues aside, there are several practical issues with the
-  implementation of Tor that need to be addressed to ensure that
-  identity information is not leaked by the implementation.
-
-  Exit policy issues:
-
-  If a client chooses an exit with a very restrictive exit policy
-  (such as an IP or IP range), the first hop then knows a good deal
-  about the destination. For this reason, clients should not select
-  exits that match their destination IP with anything other than "*".
-
-  Partitioning:
-
-  Partitioning attacks form another concern. Since Tor uses telescoping
-  to build circuits, it is possible to tell a user is constructing only
-  two hop paths at the entry node and on the local network. An external
-  adversary can potentially differentiate 2 and 3 hop users, and decide
-  that all IP addresses connecting to Tor and using 3 hops have something
-  to hide, and should be scrutinized more closely or outright apprehended.
-
-  One solution to this is to use the "leaky-circuit" method of attaching
-  streams: The user always creates 3-hop circuits, but if the option
-  is enabled, they always exit from their 2nd hop. The ideal solution
-  would be to create a RELAY_SHISHKABOB cell which contains onion
-  skins for every host along the path, but this requires protocol
-  changes at the nodes to support.
-
-  Guard nodes:
-
-  Since guard nodes can rotate due to client relocation, network
-  failure, node upgrades and other issues, if you amortize the risk a
-  mobile, dialup, or otherwise intermittently connected user is exposed to
-  over any reasonable duration of Tor usage (on the order of a year), it
-  is the same with or without guard nodes. Assuming an adversary has
-  c%/n% of network bandwidth, and guards rotate on average with period R,
-  statistically speaking, it's merely a question of if the user wishes
-  their risk to be concentrated with probability c/n over an expected
-  period of R*c, and probability 0 over an expected period of R*(n-c),
-  versus a continuous risk of (c/n)^2. So statistically speaking, guards
-  only create a time-tradeoff of risk over the long run for normal Tor
-  usage. Rotating guards do not reduce risk for normal client usage long
-  term.[3]
-
-  On other other hand, assuming a more stable method of guard selection
-  and preservation is devised, or a more stable client side network than 
-  my own is typical (which rotates guards frequently due to network issues
-  and moving about), guard nodes provide a tradeoff in the form of c/n% of
-  the users being "sacrificial users" who are exposed to high risk O(c/n)
-  of identification, while the rest of the network is exposed to zero
-  risk.
-
-  The nature of Tor makes it likely an adversary will take a "shock and
-  awe" approach to suppressing Tor by rounding up a few users whose
-  browsing activity has been observed to be made into examples, in an
-  attempt to prove that Tor is not perfect.
-
-  Since this "shock and awe" attack can be applied with or without guard
-  nodes, stable guard nodes do offer a measure of accountability of sorts.
-  If a user was using a small set of guard nodes and knows them well, and
-  then is suddenly apprehended as a result of Tor usage, having a fixed
-  set of entry points to suspect is a lot better than suspecting the whole
-  network. Conversely, it can also give non-apprehended users comfort
-  that they are likely to remain safe indefinitely with their set of (now
-  presumably trusted) guards. This is probably the most beneficial
-  property of reliable guards: they deter the adversary from mounting
-  "shock and awe" attacks because the surviving users will not
-  intimidated, but instead made more confident. Of course, guards need to
-  be made much more stable and users need to be encouraged to know their
-  guards for this property to really take effect. 
-
-  This beneficial property of client vigilance also carries over to an
-  active adversary, except in this case instead of relying on the user
-  to remember their guard nodes and somehow communicate them after
-  apprehension, the code can alert them to the presence of an active
-  adversary before they are apprehended. But only if they use guard nodes.
-
-  So lets consider the active adversary: Two hop paths allow malicious
-  guards to get considerably more benefit from failing circuits if they do
-  not extend to their colluding peers for the exit hop. Since guards can
-  detect the number of hops in a path via either timing or by statistical
-  analysis of the exit policy of the 2nd hop, they can perform this attack
-  predominantly against 2 hop users.
-
-  This can be addressed by completely abandoning an entry guard after a
-  certain ratio of extend or general circuit failures with respect to
-  non-failed circuits. The proper value for this ratio can be determined
-  experimentally with TorFlow. There is the possibility that the local
-  network can abuse this feature to cause certain guards to be dropped,
-  but they can do that anyways with the current Tor by just making guards
-  they don't like unreachable. With this mechanism, Tor will complain
-  loudly if any guard failure rate exceeds the expected in any failure
-  case, local or remote.
-
-  Eliminating guards entirely would actually not address this issue due
-  to the time-tradeoff nature of risk. In fact, it would just make it
-  worse. Without guard nodes, it becomes much more difficult for clients
-  to become alerted to Tor entry points that are failing circuits to make
-  sure that they only devote bandwidth to carry traffic for streams which
-  they observe both ends. Yet the rogue entry points are still able to
-  significantly increase their success rates by failing circuits.
-
-  For this reason, guard nodes should remain enabled for 2 hop users,
-  at least until an IP-independent, undetectable guard scanner can
-  be created. TorFlow can scan for failing guards, but after a while, 
-  its unique behavior gives away the fact that its IP is a scanner and 
-  it can be given selective service.
-  
-  Consideration of risks for node operators:
-
-  There is a serious risk for two hop users in the form of guard
-  profiling. If an adversary running an exit node notices that a
-  particular site is always visited from a fixed previous hop, it is
-  likely that this is a two hop user using a certain guard, which could be
-  monitored to determine their identity. Thus, for the protection of both
-  2 hop users and node operators, 2 hop users should limit their guard
-  duration to a sufficient number of days to verify reliability of a node,
-  but not much more. This duration can be determined experimentally by
-  TorFlow.
-
-  Considering a Tor client builds on average 144 circuits/day (10
-  minutes per circuit), if the adversary owns c/n% of exits on the
-  network, they can expect to see 144*c/n circuits from this user, or
-  about 14 minutes of usage per day per percentage of network penetration.
-  Since it will take several occurrences of user-linkable exit content
-  from the same predecessor hop for the adversary to have any confidence
-  this is a 2 hop user, it is very unlikely that any sort of demands made
-  upon the predecessor node would guaranteed to be effective (ie it
-  actually was a guard), let alone be executed in time to apprehend the 
-  user before they rotated guards.
-
-  The reverse risk also warrants consideration. If a malicious guard has
-  orders to surveil Mike Perry, it can determine Mike Perry is using two
-  hops by observing his tendency to choose a 2nd hop with a viable exit
-  policy. This can be done relatively quickly, unfortunately, and
-  indicates Mike Perry should spend some of his time building real 3 hop
-  circuits through the same guards, to require them to at least wait for
-  him to actually use Tor to determine his style of operation, rather than
-  collect this information from his passive building patterns.
-
-  However, to actively determine where Mike Perry is going, the guard
-  will need to require logging ahead of time at multiple exit nodes that
-  he may use over the course of the few days while he is at that guard,
-  and correlate the usage times of the exit node with Mike Perry's
-  activity at that guard for the few days he uses it. At this point, the
-  adversary is mounting a scale and method of attack (widespread logging,
-  timing attacks) that works pretty much just as effectively against 3
-  hops, so exit node operators are exposed to no additional danger than
-  they otherwise normally are.
-
-
-Why not fix Pathlen=2?:
-
-  The main reason I am not advocating that we always use 2 hops is that
-  in some situations, timing correlation evidence by itself may not be
-  considered as solid and convincing as an actual, uninterrupted, fully
-  traced path. Are these timing attacks as effective on a real network as
-  they are in simulation? Maybe the circuit multiplexing of Tor can serve 
-  to frustrate them to a degree? Would an extralegal adversary or 
-  authoritarian government even care? In the face of these situation 
-  dependent unknowns, it should be up to the user to decide if this is 
-  a concern for them or not.
-
-  It should probably also be noted that even a false positive
-  rate of 1% for a 200k concurrent-user network could mean that for a
-  given node, a given stream could be confused with something like 10
-  users, assuming ~200 nodes carry most of the traffic (ie 1000 users
-  each). Though of course to really know for sure, someone needs to do
-  an attack on a real network, unfortunately.
-
-  Additionally, at some point cover traffic schemes may be implemented to
-  frustrate timing attacks on the first hop. It is possible some expert
-  users may do this ad-hoc already, and may wish to continue using 3 hops
-  for this reason.
-
-
-Implementation:
-
-  new_route_len() can be modified directly with a check of the
-  Pathlen option. However, circuit construction logic should be
-  altered so that both 2 hop and 3 hop users build the same types of
-  circuits, and the option should ultimately govern circuit selection,
-  not construction. This improves coverage against guard nodes being
-  able to passively profile users who aren't even using Tor.
-  PathlenCoinWeight, anyone? :)
-
-  The exit policy hack is a bit more tricky. compare_addr_to_addr_policy
-  needs to return an alternate ADDR_POLICY_ACCEPTED_WILDCARD or
-  ADDR_POLICY_ACCEPTED_SPECIFIC return value for use in
-  circuit_is_acceptable.
-  
-  The leaky exit is trickier still.. handle_control_attachstream
-  does allow paths to exit at a given hop. Presumably something similar
-  can be done in connection_ap_handshake_process_socks, and elsewhere?
-  Circuit construction would also have to be performed such that the
-  2nd hop's exit policy is what is considered, not the 3rd's.
-
-  The entry_guard_t structure could have num_circ_failed and
-  num_circ_succeeded members such that if it exceeds F% circuit
-  extend failure rate to a second hop, it is removed from the entry list.
-
-  F should be sufficiently high to avoid churn from normal Tor circuit
-  failure as determined by TorFlow scans.
-
-  The Vidalia option should be presented as a radio button.
-
-
-Migration:
-
-  Phase 1: Adjust exit policy checks if Pathlen is set, implement leaky
-  circuit ability, and 2-3 hop circuit selection logic governed by
-  Pathlen.
-
-  Phase 2: Experiment to determine the proper ratio of circuit
-  failures used to expire garbage or malicious guards via TorFlow
-  (pending Bug #440 backport+adoption).
-
-  Phase 3: Implement guard expiration code to kick off failure-prone
-  guards and warn the user. Cap 2 hop guard duration to a proper number
-  of days determined sufficient to establish guard reliability (to be
-  determined by TorFlow).
-
-  Phase 4: Make radiobutton in Vidalia, along with help entry
-  that explains in layman's terms the risks involved.
-
-  Phase 5: Allow user to specify path length by HTTP URL suffix.
-
-
-[1] http://p2pnet.net/story/11279
-[2] http://www.cs.umass.edu/~mwright/papers/levine-timing.pdf
-[3] Proof available upon request ;)
diff --git a/doc/spec/proposals/116-two-hop-paths-from-guard.txt b/doc/spec/proposals/116-two-hop-paths-from-guard.txt
deleted file mode 100644
index 454b344..0000000
--- a/doc/spec/proposals/116-two-hop-paths-from-guard.txt
+++ /dev/null
@@ -1,120 +0,0 @@
-Filename: 116-two-hop-paths-from-guard.txt
-Title: Two hop paths from entry guards
-Version: $Revision$
-Last-Modified: $Date$
-Author: Michael Lieberman
-Created: 26-Jun-2007
-Status: Dead
-
-This proposal is related to (but different from) Mike Perry's proposal 115
-"Two Hop Paths."
-
-Overview:
-
-Volunteers who run entry guards should have the option of using only 2
-additional tor nodes when constructing their own tor circuits.
-
-While the option of two hop paths should perhaps be extended to every client
-(as discussed in Mike Perry's thread), I believe the anonymity properties of
-two hop paths are particularly well-suited to client computers that are also
-serving as entry guards.
-
-First I will describe the details of the strategy, as well as possible
-avenues of attack. Then I will list advantages and disadvantages. Then, I
-will discuss some possibly safer variations of the strategy, and finally
-some implementation issues.
-
-Details:
-
-Suppose Alice is an entry guard, and wants to construct a two hop circuit.
-Alice chooses a middle node at random (not using the entry guard strategy),
-and gains anonymity by having her traffic look just like traffic from
-someone else using her as an entry guard.
-
-Can Alice's middle node figure out that she is initiator of the traffic? I
-can think of four possible approaches for distinguishing traffic from Alice
-with traffic through Alice:
-
-1) Notice that communication from Alice comes too fast: Experimentation is
-needed to determine if traffic from Alice can be distinguished from traffic
-from a computer with a decent link to Alice.
-
-2) Monitor Alice's network traffic to discover the lack of incoming packets
-at the appropriate times. If an adversary has this ability, then Alice
-already has problems in the current system, because the adversary can run a
-standard timing attack on Alice's traffic.
-
-3) Notice that traffic from Alice is unique in some way such that if Alice
-was just one of 3 entry guards for this traffic, then the traffic should be
-coming from two other entry guards as well. An example of "unique traffic"
-could be always sending 117 packets every 3 minutes to an exit node that
-exits to port 4661. However, if such patterns existed with sufficient
-precision, then it seems to me that Tor already has a problem. (This "unique
-traffic" may not be a problem if clients often end up choosing a single
-entry guard because their other two are down. Does anyone know if this is
-the case?)
-
-4) First, control the middle node *and* some other part of the traffic,
-using standard attacks on a two hop circuit without entry nodes (my recent
-paper on Browser-Based Attacks would work well for this
-http://petworkshop.org/2007/papers/PET2007_preproc_Browser_based.pdf). With
-control of the circuit, we can now cause "unique traffic" as in 3).
-Alternatively, if we know something about Alice independently, and we can
-see what websites are being visited, we might be able to guess that she is
-the kind of person that would visit those websites.
-
-Anonymity Advantages:
-
--Alice never has the problem of choosing a malicious entry guard. In some
-sense, Alice acts as her own entry guard.
-
-Anonymity Disadvantages:
-
--If Alice's traffic is identified as originating from herself (see above for
-how hard that might be), then she has the anonymity of a 2 hop circuit
-without entry guards.
-
-Additional advantages:
-
--A discussion of the latency advantages of two hop circuits is going on in
-Mike Perry's thread already.
--Also, we can advertise this change as "Run an entry guard and decrease your
-own Tor latency." This incentive has the potential to add nodes to the
-network, improving the network as a whole.
-
-Safer variations:
-
-To solve the "unique traffic" problem, Alice could use two hop paths only
-1/3 of the time, and choose 2 other entry guards for the other 2/3 of the
-time. All the advantages are now 1/3 as useful (possibly more, if the other
-2 entry guards are not always up).
-
-To solve the problem that Alice's responses are too fast, Alice could delay
-her responses (ideally based on some real data of response time when Alice
-is used an entry guard). This loses most of the speed advantages of the two
-hop path, but if Alice is a fast entry guard, it doesn't lose everything. It
-also still has the (arguable) anonymity advantage that Alice doesn't have to
-worry about having a malicious entry guard.
-
-Implementation details:
-For Alice to remain anonymous using this strategy, she has to actually be
-acting as an entry guard for other nodes. This means the two hop option can
-only be available to whatever high-performance threshold is currently set on
-entry guards. Alice may need to somehow check her own current status as an
-entry guard before choosing this two hop strategy.
-
-Another thing to consider: suppose Alice is also an exit node. If the
-fraction of exit nodes in existence is too small, she may rarely or never be
-chosen as an entry guard. It would be sad if we offered an incentive to run
-an entry guard that didn't extend to exit nodes. I suppose clients of Exit
-nodes could pull the same trick, and bypass using Tor altogether (zero hop
-paths), though that has additional issues.*
-
-Mike Lieberman
-MIT
-
-*Why we shouldn't recommend Exit nodes pull the same trick:
-1) Exit nodes would suffer heavily from the problem of "unique traffic"
-mentioned above.
-2) It would give governments an incentive to confiscate exit nodes to see if
-they are pulling this trick.
diff --git a/doc/spec/proposals/117-ipv6-exits.txt b/doc/spec/proposals/117-ipv6-exits.txt
deleted file mode 100644
index c840282..0000000
--- a/doc/spec/proposals/117-ipv6-exits.txt
+++ /dev/null
@@ -1,412 +0,0 @@
-Filename: 117-ipv6-exits.txt
-Title: IPv6 exits
-Version: $Revision$
-Last-Modified: $Date$
-Author: coderman
-Created: 10-Jul-2007
-Status: Accepted
-Target: 0.2.1.x
-
-Overview
-
-   Extend Tor for TCP exit via IPv6 transport and DNS resolution of IPv6
-   addresses.  This proposal does not imply any IPv6 support for OR
-   traffic, only exit and name resolution.
-
-
-Contents
-
-0. Motivation
-
-   As the IPv4 address space becomes more scarce there is increasing
-   effort to provide Internet services via the IPv6 protocol.  Many
-   hosts are available at IPv6 endpoints which are currently
-   inaccessible for Tor users.
-
-   Extending Tor to support IPv6 exit streams and IPv6 DNS name
-   resolution will allow users of the Tor network to access these hosts.
-   This capability would be present for those who do not currently have
-   IPv6 access, thus increasing the utility of Tor and furthering
-   adoption of IPv6.
-
-
-1. Design
-
-1.1. General design overview
-
-   There are three main components to this proposal.  The first is a
-   method for routers to advertise their ability to exit IPv6 traffic.
-   The second is the manner in which routers resolve names to IPv6
-   addresses.  Last but not least is the method in which clients
-   communicate with Tor to resolve and connect to IPv6 endpoints
-   anonymously.
-
-1.2. Router IPv6 exit support
-
-   In order to specify exit policies and IPv6 capability new directives
-   in the Tor configuration will be needed.  If a router advertises IPv6
-   exit policies in its descriptor this will signal the ability to
-   provide IPv6 exit.  There are a number of additional default deny
-   rules associated with this new address space which are detailed in
-   the addendum.
-
-   When Tor is started on a host it should check for the presence of a
-   global unicast IPv6 address and if present include the default IPv6
-   exit policies and any user specified IPv6 exit policies.
-
-   If a user provides IPv6 exit policies but no global unicast IPv6
-   address is available Tor should generate a warning and not publish the
-   IPv6 policies in the router descriptor.
-
-   It should be noted that IPv4 mapped IPv6 addresses are not valid exit
-   destinations.  This mechanism is mainly used to interoperate with
-   both IPv4 and IPv6 clients on the same socket.  Any attempts to use
-   an IPv4 mapped IPv6 address, perhaps to circumvent exit policy for
-   IPv4, must be refused.
-
-1.3. DNS name resolution of IPv6 addresses (AAAA records)
-
-   In addition to exit support for IPv6 TCP connections, a method to
-   resolve domain names to their respective IPv6 addresses is also
-   needed.  This is accomplished in the existing DNS system via AAAA
-   records.  Routers will perform both A and AAAA requests when
-   resolving a name so that the client can utilize an IPv6 endpoint when
-   available or preferred.
-
-   To avoid potential problems with caching DNS servers that behave
-   poorly all NXDOMAIN responses to AAAA requests should be ignored if a
-   successful response is received for an A request.  This implies that
-   both AAAA and A requests will always be performed for each name
-   resolution.
-
-   For reverse lookups on IPv6 addresses, like that used for
-   RESOLVE_PTR, Tor will perform the necessary PTR requests via
-   IP6.ARPA.
-
-   All routers which perform DNS resolution on behalf of clients
-   (RELAY_RESOLVE) should perform and respond with both A and AAAA
-   resources.
-
-   [NOTE: In a future version, when we extend the behavior of RESOLVE to
-    encapsulate more of real DNS, it will make sense to allow more
-    flexibility here. -nickm]
-
-1.4. Client interaction with IPv6 exit capability
-
-1.4.1. Usability goals
-
-   There are a number of behaviors which Tor can provide when
-   interacting with clients that will improve the usability of IPv6 exit
-   capability.  These behaviors are designed to make it simple for
-   clients to express a preference for IPv6 transport and utilize IPv6
-   host services.
-
-1.4.2. SOCKSv5 IPv6 client behavior
-
-   The SOCKS version 5 protocol supports IPv6 connections.  When using
-   SOCKSv5 with hostnames it is difficult to determine if a client
-   wishes to use an IPv4 or IPv6 address to connect to the desired host
-   if it resolves to both address types.
-
-   In order to make this more intuitive the SOCKSv5 protocol can be
-   supported on a local IPv6 endpoint, [::1] port 9050 for example.
-   When a client requests a connection to the desired host via an IPv6
-   SOCKS connection Tor will prefer IPv6 addresses when resolving the
-   host name and connecting to the host.
-
-   Likewise, RESOLVE and RESOLVE_PTR requests from an IPv6 SOCKS
-   connection will return IPv6 addresses when available, and fall back
-   to IPv4 addresses if not.
-
-   [NOTE: This means that SocksListenAddress and DNSListenAddress should
-    support IPv6 addresses.  Perhaps there should also be a general option
-    to have listeners that default to 127.0.0.1 and 0.0.0.0 listen
-    additionally or instead on ::1 and :: -nickm]
-
-1.4.3. MAPADDRESS behavior
-
-   The MAPADDRESS capability supports clients that may not be able to
-   use the SOCKSv4a or SOCKSv5 hostname support to resolve names via
-   Tor.  This ability should be extended to IPv6 addresses in SOCKSv5 as
-   well.
-
-   When a client requests an address mapping from the wildcard IPv6
-   address, [::0], the server will respond with a unique local IPv6
-   address on success.  It is important to note that there may be two
-   mappings for the same name if both an IPv4 and IPv6 address are
-   associated with the host.  In this case a CONNECT to a mapped IPv6
-   address should prefer IPv6 for the connection to the host, if
-   available, while CONNECT to a mapped IPv4 address will prefer IPv4.
-
-   It should be noted that IPv6 does not provide the concept of a host
-   local subnet, like 127.0.0.0/8 in IPv4.  For this reason integration
-   of Tor with IPv6 clients should consider a firewall or filter rule to
-   drop unique local addresses to or from the network when possible.
-   These packets should not be routed, however, keeping them off the
-   subnet entirely is worthwhile.
-
-1.4.3.1. Generating unique local IPv6 addresses
-
-   The usual manner of generating a unique local IPv6 address is to
-   select a Global ID part randomly, along with a Subnet ID, and sharing
-   this prefix among the communicating parties who each have their own
-   distinct Interface ID.  In this style a given Tor instance might
-   select a random Global and Subnet ID and provide MAPADDRESS
-   assignments with a random Interface ID as needed.  This has the
-   potential to associate unique Global/Subnet identifiers with a given
-   Tor instance and may expose attacks against the anonymity of Tor
-   users.
-
-   Tor avoid this potential problem entirely MAPADDRESS must always
-   generate the Global, Subnet, and Interface IDs randomly for each
-   request.  It is also highly suggested that explicitly specifying an
-   IPv6 source address instead of the wildcard address not be supported
-   to ensure that a good random address is used.
-
-1.4.4. DNSProxy IPv6 client behavior
-
-   A new capability in recent Tor versions is the transparent DNS proxy.
-   This feature will need to return both A and AAAA resource records
-   when responding to client name resolution requests.
-
-   The transparent DNS proxy should also support reverse lookups for
-   IPv6 addresses.  It is suggested that any such requests to the
-   deprecated IP6.INT domain should be translated to IP6.ARPA instead.
-   This translation is not likely to be used and is of low priority.
-
-   It would be nice to support DNS over IPv6 transport as well, however,
-   this is not likely to be used and is of low priority.
-
-1.4.5. TransPort IPv6 client behavior
-
-   Tor also provides transparent TCP proxy support via the Trans*
-   directives in the configuration.  The TransListenAddress directive
-   should accept an IPv6 address in addition to IPv4 so that IPv6 TCP
-   connections can be transparently proxied.
-
-1.5. Additional changes
-
-   The RedirectExit option should be deprecated rather than extending
-   this feature to IPv6.
-
-
-2. Spec changes
-
-2.1. Tor specification
-
-   In '6.2. Opening streams and transferring data' the following should
-   be changed to indicate IPv6 exit capability:
-
-      "No version of Tor currently generates the IPv6 format."
-
-   In '6.4. Remote hostname lookup' the following should be updated to
-   reflect use of ip6.arpa in addition to in-addr.arpa.
-
-      "For a reverse lookup, the OP sends a RELAY_RESOLVE cell containing an
-       in-addr.arpa address."
-
-   In 'A.1. Differences between spec and implementation' the following
-   should be updated to indicate IPv6 exit capability:
-
-      "The current codebase has no IPv6 support at all."
-
-   [NOTE: the EXITPOLICY end-cell reason says that it can hold an ipv4 or an
-    ipv6 address, but doesn't say how.  We may want a separate EXITPOLICY2
-    type that can hold an ipv6 address, since the way we encode ipv6
-    addresses elsewhere ("0.0.0.0 indicates that the next 16 bytes are ipv6")
-    is a bit dumb. -nickm]
-   [Actually, the length field lets us distinguish EXITPOLICY. -nickm]
-
-2.2. Directory specification
-
-   In '2.1. Router descriptor format' a new set of directives is needed
-   for IPv6 exit policy.  The existing accept/reject directives should
-   be clarified to indicate IPv4 or wildcard address relevance.  The new
-   IPv6 directives will be in the form of:
-
-      "accept6" exitpattern NL
-      "reject6" exitpattern NL
-
-   The section describing accept6/reject6 should explain that the
-   presence of accept6 or reject6 exit policies in a router descriptor
-   signals the ability of that router to exit IPv6 traffic (according to
-   IPv6 exit policies).
-
-   The "[::]/0" notation is used to represent "all IPv6 addresses".
-   "[::0]/0" may also be used for this representation.
-
-   If a user specifies a 'reject6 [::]/0:*' policy in the Tor
-   configuration this will be interpreted as forcing no IPv6 exit
-   support and no accept6/reject6 policies will be included in the
-   published descriptor.  This will prevent IPv6 exit if the router host
-   has a global unicast IPv6 address present.
-
-   It is important to note that a wildcard address in an accept or
-   reject policy applies to both IPv4 and IPv6 addresses.
-
-2.3. Control specification
-
-   In '3.8. MAPADDRESS' the potential to have to addresses for a given
-   name should be explained.  The method for generating unique local
-   addresses for IPv6 mappings needs explanation as described above.
-
-   When IPv6 addresses are used in this document they should include the
-   brackets for consistency.  For example, the null IPv6 address should
-   be written as "[::0]" and not "::0".  The control commands will
-   expect the same syntax as well.
-
-   In '3.9. GETINFO' the "address" command should return both public
-   IPv4 and IPv6 addresses if present.  These addresses should be
-   separated via \r\n.
-
-
-2.4. Tor SOCKS extensions
-
-   In '2. Name lookup' a description of IPv6 address resolution is
-   needed for SOCKSv5 as described above.  IPv6 addresses should be
-   supported in both the RESOLVE and RESOLVE_PTR extensions.
-
-   A new section describing the ability to accept SOCKSv5 clients on a
-   local IPv6 address to indicate a preference for IPv6 transport as
-   described above is also needed.  The behavior of Tor SOCKSv5 proxy
-   with an IPv6 preference should be explained, for example, preferring
-   IPv6 transport to a named host with both IPv4 and IPv6 addresses
-   available (A and AAAA records).
-
-
-3. Questions and concerns
-
-3.1. DNS A6 records
-
-   A6 is explicitly avoided in this document.  There are potential
-   reasons for implementing this, however, the inherent complexity of
-   the protocol and resolvers make this unappealing.  Is there a
-   compelling reason to consider A6 as part of IPv6 exit support?
-
-   [IMO not till anybody needs it. -nickm]
-
-3.2. IPv4 and IPv6 preference
-
-   The design above tries to infer a preference for IPv4 or IPv6
-   transport based on client interactions with Tor.  It might be useful
-   to provide more explicit control over this preference.  For example,
-   an IPv4 SOCKSv5 client may want to use IPv6 transport to named hosts
-   in CONNECT requests while the current implementation would assume an
-   IPv4 preference.  Should more explicit control be available, through
-   either configuration directives or control commands?
-
-   Many applications support a inet6-only or prefer-family type option
-   that provides the user manual control over address preference.  This
-   could be provided as a Tor configuration option.
-
-   An explicit preference is still possible by resolving names and then
-   CONNECTing to an IPv4 or IPv6 address as desired, however, not all
-   client applications may have this option available.
-
-3.3. Support for IPv6 only transparent proxy clients
-
-   It may be useful to support IPv6 only transparent proxy clients using
-   IPv4 mapped IPv6 like addresses.  This would require transparent DNS
-   proxy using IPv6 transport and the ability to map A record responses
-   into IPv4 mapped IPv6 like addresses in the manner described in the
-   "NAT-PT" RFC for a traditional Basic-NAT-PT with DNS-ALG.  The
-   transparent TCP proxy would thus need to detect these mapped addresses
-   and connect to the desired IPv4 host.
-
-   The IPv6 prefix used for this purpose must not be the actual IPv4
-   mapped IPv6 address prefix, though the manner in which IPv4 addresses
-   are embedded in IPv6 addresses would be the same.
-
-   The lack of any IPv6 only hosts which would use this transparent proxy
-   method makes this a lot of work for very little gain.  Is there a
-   compelling reason to support this NAT-PT like capability?
-
-3.4. IPv6 DNS and older Tor routers
-
-   It is expected that many routers will continue to run with older
-   versions of Tor when the IPv6 exit capability is released.  Clients
-   who wish to use IPv6 will need to route RELAY_RESOLVE requests to the
-   newer routers which will respond with both A and AAAA resource
-   records when possible.
-
-   One way to do this is to route RELAY_RESOLVE requests to routers with
-   IPv6 exit policies published, however, this would not utilize current
-   routers that can resolve IPv6 addresses even if they can't exit such
-   traffic.
-
-   There was also concern expressed about the ability of existing clients
-   to cope with new RELAY_RESOLVE responses that contain IPv6 addresses.
-   If this breaks backward compatibility, a new request type may be
-   necessary, like RELAY_RESOLVE6, or some other mechanism of indicating
-   the ability to parse IPv6 responses when making the request.
-
-3.5. IPv4 and IPv6 bindings in MAPADDRESS
-
-   It may be troublesome to try and support two distinct address mappings
-   for the same name in the existing MAPADDRESS implementation.  If this
-   cannot be accommodated then the behavior should replace existing
-   mappings with the new address regardless of family.  A warning when
-   this occurs would be useful to assist clients who encounter problems
-   when both an IPv4 and IPv6 application are using MAPADDRESS for the
-   same names concurrently, causing lost connections for one of them.
-
-4. Addendum
-
-4.1. Sample IPv6 default exit policy
-
-   reject 0.0.0.0/8
-   reject 169.254.0.0/16
-   reject 127.0.0.0/8
-   reject 192.168.0.0/16
-   reject 10.0.0.0/8
-   reject 172.16.0.0/12
-   reject6 [0000::]/8
-   reject6 [0100::]/8
-   reject6 [0200::]/7
-   reject6 [0400::]/6
-   reject6 [0800::]/5
-   reject6 [1000::]/4
-   reject6 [4000::]/3
-   reject6 [6000::]/3
-   reject6 [8000::]/3
-   reject6 [A000::]/3
-   reject6 [C000::]/3
-   reject6 [E000::]/4
-   reject6 [F000::]/5
-   reject6 [F800::]/6
-   reject6 [FC00::]/7
-   reject6 [FE00::]/9
-   reject6 [FE80::]/10
-   reject6 [FEC0::]/10
-   reject6 [FF00::]/8
-   reject *:25
-   reject *:119
-   reject *:135-139
-   reject *:445
-   reject *:1214
-   reject *:4661-4666
-   reject *:6346-6429
-   reject *:6699
-   reject *:6881-6999
-   accept *:*
-   # accept6 [2000::]/3:* is implied
-
-4.2. Additional resources
-
-   'DNS Extensions to Support IP Version 6'
-   http://www.ietf.org/rfc/rfc3596.txt
-
-   'DNS Extensions to Support IPv6 Address Aggregation and Renumbering'
-   http://www.ietf.org/rfc/rfc2874.txt
-
-   'SOCKS Protocol Version 5'
-   http://www.ietf.org/rfc/rfc1928.txt
-
-   'Unique Local IPv6 Unicast Addresses'
-   http://www.ietf.org/rfc/rfc4193.txt
-
-   'INTERNET PROTOCOL VERSION 6 ADDRESS SPACE'
-   http://www.iana.org/assignments/ipv6-address-space
-
-   'Network Address Translation - Protocol Translation (NAT-PT)'
-   http://www.ietf.org/rfc/rfc2766.txt
diff --git a/doc/spec/proposals/118-multiple-orports.txt b/doc/spec/proposals/118-multiple-orports.txt
deleted file mode 100644
index 1bef250..0000000
--- a/doc/spec/proposals/118-multiple-orports.txt
+++ /dev/null
@@ -1,86 +0,0 @@
-Filename: 118-multiple-orports.txt
-Title: Advertising multiple ORPorts at once
-Version: $Revision$
-Last-Modified: $Date$
-Author: Nick Mathewson
-Created: 09-Jul-2007
-Status: Accepted
-Target: 0.2.1.x
-
-Overview:
-
-   This document is a proposal for servers to advertise multiple
-   address/port combinations for their ORPort.
-
-Motivation:
-
-   Sometimes servers want to support multiple ports for incoming
-   connections, either in order to support multiple address families, to
-   better use multiple interfaces, or to support a variety of
-   FascistFirewallPorts settings.  This is easy to set up now, but
-   there's no way to advertise it to clients.
-
-New descriptor syntax:
-
-   We add a new line in the router descriptor, "or-address".  This line
-   can occur zero, one, or multiple times.  Its format is:
-
-      or-address SP ADDRESS ":" PORTLIST NL
-
-      ADDRESS = IP6ADDR / IP4ADDR
-      IPV6ADDR = an ipv6 address, surrounded by square brackets.
-      IPV4ADDR = an ipv4 address, represented as a dotted quad.
-      PORTLIST = PORTSPEC | PORTSPEC "," PORTLIST
-      PORTSPEC = PORT | PORT "-" PORT
-
-   [This is the regular format for specifying sets of addresses and
-   ports in Tor.]
-
-New OR behavior:
-
-   We add two more options to supplement ORListenAddress:
-   ORPublishedListenAddress, and ORPublishAddressSet.  The former
-   listens on an address-port combination and publishes it in addition
-   to the regular address.  The latter advertises a set of address-port
-   combinations, but does not listen on them.  [To use this option, the
-   server operator should set up port forwarding to the regular ORPort,
-   as for example with firewall rules.]
-
-   Servers should extend their testing to include advertised addresses
-   and ports.  No address or port should be advertised until it's been
-   tested.  [This might get expensive in practice.]
-
-New authority behavior:
-
-   Authorities should spot-test descriptors, and reject any where a
-   substantial part of the addresses can't be reached.
-
-New client behavior:
-
-   When connecting to another server, clients SHOULD pick an
-   address-port ocmbination at random as supported by their
-   reachableaddresses.  If a client has a connection to a server at one
-   address, it SHOULD use that address for any simultaneous connections
-   to that server.  Clients SHOULD use the canonical address for any
-   server when generating extend cells.
-
-Not addressed here:
-
-   * There's no reason to listen on multiple dirports; current Tors
-   mostly don't connect directly to the dirport anyway.
-
-   * It could be advantageous to list something about extra addresses in
-   the network-status document.  This would, however, eat space there.
-   More analysis is needed, particularly in light of proposal 141
-   ("Download server descriptors on demand")
-
-Dependencies:
-
-   Testing for canonical connections needs to be implemented before it's
-   safe to use this proposal.
-
-
-Notes 3 July:
-  - Write up the simple version of this.  No ranges needed yet.  No
-    networkstatus chagnes yet.
-
diff --git a/doc/spec/proposals/119-controlport-auth.txt b/doc/spec/proposals/119-controlport-auth.txt
deleted file mode 100644
index dc57a27..0000000
--- a/doc/spec/proposals/119-controlport-auth.txt
+++ /dev/null
@@ -1,142 +0,0 @@
-Filename: 119-controlport-auth.txt
-Title: New PROTOCOLINFO command for controllers
-Version: $Revision$
-Last-Modified: $Date$
-Author: Roger Dingledine
-Created: 14-Aug-2007
-Status: Closed
-Implemented-In: 0.2.0.x
-
-Overview:
-
-  Here we describe how to help controllers locate the cookie
-  authentication file when authenticating to Tor, so we can a) require
-  authentication by default for Tor controllers and b) still keep
-  things usable.  Also, we propose an extensible, general-purpose mechanism
-  for controllers to learn about a Tor instance's protocol and
-  authentication requirements before authenticating.
-
-The Problem:
-
-  When we first added the controller protocol, we wanted to make it
-  easy for people to play with it, so by default we didn't require any
-  authentication from controller programs. We allowed requests only from
-  localhost as a stopgap measure for security.
-
-  Due to an increasing number of vulnerabilities based on this approach,
-  it's time to add authentication in default configurations.
-
-  We have a number of goals:
-  - We want the default Vidalia bundles to transparently work. That
-    means we don't want the users to have to type in or know a password.
-  - We want to allow multiple controller applications to connect to the
-    control port. So if Vidalia is launching Tor, it can't just keep the
-    secrets to itself.
-
-  Right now there are three authentication approaches supported
-  by the control protocol: NULL, CookieAuthentication, and
-  HashedControlPassword. See Sec 5.1 in control-spec.txt for details.
-
-  There are a couple of challenges here. The first is: if the controller
-  launches Tor, how should we teach Tor what authentication approach
-  it should require, and the secret that goes along with it? Next is:
-  how should this work when the controller attaches to an existing Tor,
-  rather than launching Tor itself?
-
-  Cookie authentication seems most amenable to letting multiple controller
-  applications interact with Tor. But that brings in yet another question:
-  how does the controller guess where to look for the cookie file,
-  without first knowing what DataDirectory Tor is using?
-
-Design:
-
-  We should add a new controller command PROTOCOLINFO that can be sent
-  as a valid first command (the others being AUTHENTICATE and QUIT). If
-  PROTOCOLINFO is sent as the first command, the second command must be
-  either a successful AUTHENTICATE or a QUIT.
-
-  If the initial command sequence is not valid, Tor closes the connection.
-
-
-Spec:
-
-  C:  "PROTOCOLINFO" *(SP PIVERSION) CRLF
-  S:  "250+PROTOCOLINFO" SP PIVERSION CRLF *InfoLine "250 OK" CRLF
-
-    InfoLine = AuthLine / VersionLine / OtherLine
-
-     AuthLine = "250-AUTH" SP "METHODS=" AuthMethod *(",")AuthMethod
-                       *(SP "COOKIEFILE=" AuthCookieFile) CRLF
-     VersionLine = "250-VERSION" SP "Tor=" TorVersion [SP Arguments] CRLF
-
-     AuthMethod =
-      "NULL"           / ; No authentication is required
-      "HASHEDPASSWORD" / ; A controller must supply the original password
-      "COOKIE"         / ; A controller must supply the contents of a cookie
-
-     AuthCookieFile = QuotedString
-     TorVersion = QuotedString
-
-     OtherLine = "250-" Keyword [SP Arguments] CRLF
-
-  For example:
-
-  C: PROTOCOLINFO CRLF
-  S: "250+PROTOCOLINFO 1" CRLF
-  S: "250-AUTH Methods=HASHEDPASSWORD,COOKIE COOKIEFILE="/tor/cookie"" CRLF
-  S: "250-VERSION Tor=0.2.0.5-alpha" CRLF
-  S: "250 OK" CRLF
-
-  Tor MAY give its InfoLines in any order; controllers MUST ignore InfoLines
-  with keywords it does not recognize.  Controllers MUST ignore extraneous
-  data on any InfoLine.
-
-  PIVERSION is there in case we drastically change the syntax one day. For
-  now it should always be "1", for the controller protocol.  Controllers MAY
-  provide a list of the protocol versions they support; Tor MAY select a
-  version that the controller does not support.
-
-  Right now only two "topics" (AUTH and VERSION) are included, but more
-  may be included in the future. Controllers must accept lines with
-  unexpected topics.
-
-  AuthCookieFile = QuotedString
-
-  AuthMethod is used to specify one or more control authentication
-  methods that Tor currently accepts.
-
-  AuthCookieFile specifies the absolute path and filename of the
-  authentication cookie that Tor is expecting and is provided iff
-  the METHODS field contains the method "COOKIE".  Controllers MUST handle
-  escape sequences inside this string.
-
-  The VERSION line contains the Tor version.
-
-  [What else might we want to include that could be useful? -RD]
-
-Compatibility:
-
-  Tor 0.1.2.16 and 0.2.0.4-alpha hang up after the first failed
-  command. Earlier Tors don't know about this command but don't hang
-  up. That means controllers will need a mechanism for distinguishing
-  whether they're talking to a Tor that speaks PROTOCOLINFO or not.
-
-  I suggest that the controllers attempt a PROTOCOLINFO. Then:
-    - If it works, great. Authenticate as required.
-    - If they get hung up on, reconnect and do a NULL AUTHENTICATE.
-    - If it's unrecognized but they're not hung up on, do a NULL
-      AUTHENTICATE.
-
-Unsolved problems:
-
-  If Torbutton wants to be a Tor controller one day... talking TCP is
-  bad enough, but reading from the filesystem is even harder. Is there
-  a way to let simple programs work with the controller port without
-  needing all the auth infrastructure?
-
-  Once we put this approach in place, the next vulnerability we see will
-  involve an attacker somehow getting read access to the victim's files
-  --- and then we're back where we started. This means we still need
-  to think about how to demand password-based authentication without
-  bothering the user about it.
-
diff --git a/doc/spec/proposals/120-shutdown-descriptors.txt b/doc/spec/proposals/120-shutdown-descriptors.txt
deleted file mode 100644
index dc1265b..0000000
--- a/doc/spec/proposals/120-shutdown-descriptors.txt
+++ /dev/null
@@ -1,85 +0,0 @@
-Filename: 120-shutdown-descriptors.txt
-Title: Shutdown descriptors when Tor servers stop
-Version: $Revision$
-Last-Modified: $Date$
-Author: Roger Dingledine
-Created: 15-Aug-2007
-Status: Dead
-
-[Proposal dead as of 11 Jul 2008. The point of this proposal was to give
-routers a good way to get out of the networkstatus early, but proposal
-138 (already implemented) has achieved this.]
-
-Overview:
-
-  Tor servers should publish a last descriptor whenever they shut down,
-  to let others know that they are no longer offering service.
-
-The Problem:
-
-  The main reason for this is in reaction to Internet services that want
-  to treat connections from the Tor network differently. Right now,
-  if a user experiments with turning on the "relay" functionality, he
-  is punished by being locked out of some websites, some IRC networks,
-  etc --- and this lockout persists for several days even after he turns
-  the server off.
-
-Design:
-
-  During the "slow shutdown" period if exiting, or shortly after the
-  user sets his ORPort back to 0 if not exiting, Tor should publish a
-  final descriptor with the following characteristics:
-
-  1) Exit policy is listed as "reject *:*"
-  2) It includes a new entry called "opt shutdown 1"
-
-  The first step is so current blacklists will no longer list this node
-  as exiting to whatever the service is.
-
-  The second step is so directory authorities can avoid wasting time
-  doing reachability testing. Authorities should automatically not list
-  as Running any router whose latest descriptor says it shut down.
-
-  [I originally had in mind a third step --- Advertised bandwidth capacity
-  is listed as "0" --- so current Tor clients will skip over this node
-  when building most circuits. But since clients won't fetch descriptors
-  from nodes not listed as Running, this step seems pointless. -RD]
-
-Spec:
-
-  TBD but should be pretty straightforward.
-
-Security issues:
-
-  Now external people can learn exactly when a node stopped offering
-  relay service. How bad is this? I can see a few minor attacks based
-  on this knowledge, but on the other hand as it is we don't really take
-  any steps to keep this information secret.
-
-Overhead issues:
-
-  We are creating more descriptors that want to be remembered. However,
-  since the router won't be marked as Running, ordinary clients won't
-  fetch the shutdown descriptors. Caches will, though. I hope this is ok.
-
-Implementation:
-
-  To make things easy, we should publish the shutdown descriptor only
-  on controlled shutdown (SIGINT as opposed to SIGTERM). That would
-  leave enough time for publishing that we probably wouldn't need any
-  extra synchronization code.
-
-  If that turns out to be too unintuitive for users, I could imagine doing
-  it on SIGTERMs too, and just delaying exit until we had successfully
-  published to at least one authority, at which point we'd hope that it
-  propagated from there.
-
-Acknowledgements:
-
-  tup suggested this idea.
-
-Comments:
-
-  2) Maybe add a rule "Don't do this for hibernation if we expect to wake
-     up before the next consensus is published"?
-                                                      - NM 9 Oct 2007
diff --git a/doc/spec/proposals/121-hidden-service-authentication.txt b/doc/spec/proposals/121-hidden-service-authentication.txt
deleted file mode 100644
index 828bf3c..0000000
--- a/doc/spec/proposals/121-hidden-service-authentication.txt
+++ /dev/null
@@ -1,778 +0,0 @@
-Filename: 121-hidden-service-authentication.txt
-Title: Hidden Service Authentication
-Version: $Revision$
-Last-Modified: $Date$
-Author: Tobias Kamm, Thomas Lauterbach, Karsten Loesing, Ferdinand Rieger,
-        Christoph Weingarten
-Created: 10-Sep-2007
-Status: Finished
-Implemented-In: 0.2.1.x
-
-Change history:
-
-  26-Sep-2007  Initial proposal for or-dev
-  08-Dec-2007  Incorporated comments by Nick posted to or-dev on 10-Oct-2007
-  15-Dec-2007  Rewrote complete proposal for better readability, modified
-               authentication protocol, merged in personal notes
-  24-Dec-2007  Replaced misleading term "authentication" by "authorization"
-               and added some clarifications (comments by Sven Kaffille)
-  28-Apr-2008  Updated most parts of the concrete authorization protocol
-  04-Jul-2008  Add a simple algorithm to delay descriptor publication for
-               different clients of a hidden service
-  19-Jul-2008  Added INTRODUCE1V cell type (1.2), improved replay
-               protection for INTRODUCE2 cells (1.3), described limitations
-               for auth protocols (1.6), improved hidden service protocol
-               without client authorization (2.1), added second, more
-               scalable authorization protocol (2.2), rewrote existing
-               authorization protocol (2.3); changes based on discussion
-               with Nick
-  31-Jul-2008  Limit maximum descriptor size to 20 kilobytes to prevent
-               abuse.
-  01-Aug-2008  Use first part of Diffie-Hellman handshake for replay
-               protection instead of rendezvous cookie.
-  01-Aug-2008  Remove improved hidden service protocol without client
-               authorization (2.1). It might get implemented in proposal
-               142.
-
-Overview:
-
-  This proposal deals with a general infrastructure for performing
-  authorization (not necessarily implying authentication) of requests to
-  hidden services at three points: (1) when downloading and decrypting
-  parts of the hidden service descriptor, (2) at the introduction point,
-  and (3) at Bob's Tor client before contacting the rendezvous point. A
-  service provider will be able to restrict access to his service at these
-  three points to authorized clients only. Further, the proposal contains
-  specific authorization protocols as instances that implement the
-  presented authorization infrastructure.
-
-  This proposal is based on v2 hidden service descriptors as described in
-  proposal 114 and introduced in version 0.2.0.10-alpha.
-
-  The proposal is structured as follows: The next section motivates the
-  integration of authorization mechanisms in the hidden service protocol.
-  Then we describe a general infrastructure for authorization in hidden
-  services, followed by specific authorization protocols for this
-  infrastructure. At the end we discuss a number of attacks and non-attacks
-  as well as compatibility issues.
-
-Motivation:
-
-  The major part of hidden services does not require client authorization
-  now and won't do so in the future. To the contrary, many clients would
-  not want to be (pseudonymously) identifiable by the service (though this
-  is unavoidable to some extent), but rather use the service
-  anonymously. These services are not addressed by this proposal.
-
-  However, there may be certain services which are intended to be accessed
-  by a limited set of clients only. A possible application might be a
-  wiki or forum that should only be accessible for a closed user group.
-  Another, less intuitive example might be a real-time communication
-  service, where someone provides a presence and messaging service only to
-  his buddies. Finally, a possible application would be a personal home
-  server that should be remotely accessed by its owner.
-
-  Performing authorization for a hidden service within the Tor network, as
-  proposed here, offers a range of advantages compared to allowing all
-  client connections in the first instance and deferring authorization to
-  the transported protocol:
-
-  (1) Reduced traffic: Unauthorized requests would be rejected as early as
-  possible, thereby reducing the overall traffic in the network generated
-  by establishing circuits and sending cells.
-
-  (2) Better protection of service location: Unauthorized clients could not
-  force Bob to create circuits to their rendezvous points, thus preventing
-  the attack described by Øverlier and Syverson in their paper "Locating
-  Hidden Servers" even without the need for guards.
-
-  (3) Hiding activity: Apart from performing the actual authorization, a
-  service provider could also hide the mere presence of his service from
-  unauthorized clients when not providing hidden service descriptors to
-  them, rejecting unauthorized requests already at the introduction
-  point (ideally without leaking presence information at any of these
-  points), or not answering unauthorized introduction requests.
-
-  (4) Better protection of introduction points: When providing hidden
-  service descriptors to authorized clients only and encrypting the
-  introduction points as described in proposal 114, the introduction points
-  would be unknown to unauthorized clients and thereby protected from DoS
-  attacks.
-
-  (5) Protocol independence: Authorization could be performed for all
-  transported protocols, regardless of their own capabilities to do so.
-
-  (6) Ease of administration: A service provider running multiple hidden
-  services would be able to configure access at a single place uniformly
-  instead of doing so for all services separately.
-
-  (7) Optional QoS support: Bob could adapt his node selection algorithm
-  for building the circuit to Alice's rendezvous point depending on a
-  previously guaranteed QoS level, thus providing better latency or
-  bandwidth for selected clients.
-
-  A disadvantage of performing authorization within the Tor network is
-  that a hidden service cannot make use of authorization data in
-  the transported protocol. Tor hidden services were designed to be
-  independent of the transported protocol. Therefore it's only possible to
-  either grant or deny access to the whole service, but not to specific
-  resources of the service.
-
-  Authorization often implies authentication, i.e. proving one's identity.
-  However, when performing authorization within the Tor network, untrusted
-  points should not gain any useful information about the identities of
-  communicating parties, neither server nor client. A crucial challenge is
-  to remain anonymous towards directory servers and introduction points.
-  However, trying to hide identity from the hidden service is a futile
-  task, because a client would never know if he is the only authorized
-  client and therefore perfectly identifiable. Therefore, hiding client
-  identity from the hidden service is not an aim of this proposal.
-
-  The current implementation of hidden services does not provide any kind
-  of authorization. The hidden service descriptor version 2, introduced by
-  proposal 114, was designed to use a descriptor cookie for downloading and
-  decrypting parts of the descriptor content, but this feature is not yet
-  in use. Further, most relevant cell formats specified in rend-spec
-  contain fields for authorization data, but those fields are neither
-  implemented nor do they suffice entirely.
-
-Details:
-
-  1. General infrastructure for authorization to hidden services
-
-  We spotted three possible authorization points in the hidden service
-  protocol:
-
-    (1) when downloading and decrypting parts of the hidden service
-        descriptor,
-    (2) at the introduction point, and
-    (3) at Bob's Tor client before contacting the rendezvous point.
-
-  The general idea of this proposal is to allow service providers to
-  restrict access to some or all of these points to authorized clients
-  only.
-
-  1.1. Client authorization at directory
-
-  Since the implementation of proposal 114 it is possible to combine a
-  hidden service descriptor with a so-called descriptor cookie. If done so,
-  the descriptor cookie becomes part of the descriptor ID, thus having an
-  effect on the storage location of the descriptor. Someone who has learned
-  about a service, but is not aware of the descriptor cookie, won't be able
-  to determine the descriptor ID and download the current hidden service
-  descriptor; he won't even know whether the service has uploaded a
-  descriptor recently. Descriptor IDs are calculated as follows (see
-  section 1.2 of rend-spec for the complete specification of v2 hidden
-  service descriptors):
-
-      descriptor-id =
-          H(service-id | H(time-period | descriptor-cookie | replica))
-
-  Currently, service-id is equivalent to permanent-id which is calculated
-  as in the following formula. But in principle it could be any public
-  key.
-
-      permanent-id = H(permanent-key)[:10]
-
-  The second purpose of the descriptor cookie is to encrypt the list of
-  introduction points, including optional authorization data. Hence, the
-  hidden service directories won't learn any introduction information from
-  storing a hidden service descriptor. This feature is implemented but
-  unused at the moment. So this proposal will harness the advantages
-  of proposal 114.
-
-  The descriptor cookie can be used for authorization by keeping it secret
-  from everyone but authorized clients. A service could then decide whether
-  to publish hidden service descriptors using that descriptor cookie later
-  on. An authorized client being aware of the descriptor cookie would be
-  able to download and decrypt the hidden service descriptor.
-
-  The number of concurrently used descriptor cookies for one hidden service
-  is not restricted. A service could use a single descriptor cookie for all
-  users, a distinct cookie per user, or something in between, like one
-  cookie per group of users. It is up to the specific protocol and how it
-  is applied by a service provider.
-
-  Two or more hidden service descriptors for different groups or users
-  should not be uploaded at the same time. A directory node could conclude
-  easily that the descriptors were issued by the same hidden service, thus
-  being able to link the two groups or users. Therefore, descriptors for
-  different users or clients that ought to be stored on the same directory
-  are delayed, so that only one descriptor is uploaded to a directory at a
-  time. The remaining descriptors are uploaded with a delay of up to
-  30 seconds.
-  Further, descriptors for different groups or users that are to be stored
-  on different directories are delayed for a random time of up to 30
-  seconds to hide relations from colluding directories. Certainly, this
-  does not prevent linking entirely, but it makes it somewhat harder.
-  There is a conflict between hiding links between clients and making a
-  service available in a timely manner.
-
-  Although this part of the proposal is meant to describe a general
-  infrastructure for authorization, changing the way of using the
-  descriptor cookie to look up hidden service descriptors, e.g. applying
-  some sort of asymmetric crypto system, would require in-depth changes
-  that would be incompatible to v2 hidden service descriptors. On the
-  contrary, using another key for en-/decrypting the introduction point
-  part of a hidden service descriptor, e.g. a different symmetric key or
-  asymmetric encryption, would be easy to implement and compatible to v2
-  hidden service descriptors as understood by hidden service directories
-  (clients and services would have to be upgraded anyway for using the new
-  features).
-
-  An adversary could try to abuse the fact that introduction points can be
-  encrypted by storing arbitrary, unrelated data in the hidden service
-  directory. This abuse can be limited by setting a hard descriptor size
-  limit, forcing the adversary to split data into multiple chunks. There
-  are some limitations that make splitting data across multiple descriptors
-  unattractive: 1) The adversary would not be able to choose descriptor IDs
-  freely and would therefore have to implement his own indexing
-  structure. 2) Validity of descriptors is limited to at most 24 hours
-  after which descriptors need to be republished.
-
-  The regular descriptor size in bytes is 745 + num_ipos * 837 + auth_data.
-  A large descriptor with 7 introduction points and 5 kilobytes of
-  authorization data would be 11724 bytes in size. The upper size limit of
-  descriptors should be set to 20 kilobytes, which limits the effect of
-  abuse while retaining enough flexibility in designing authorization
-  protocols.
-
-  1.2. Client authorization at introduction point
-
-  The next possible authorization point after downloading and decrypting
-  a hidden service descriptor is the introduction point. It may be important
-  for authorization, because it bears the last chance of hiding presence
-  of a hidden service from unauthorized clients. Further, performing
-  authorization at the introduction point might reduce traffic in the
-  network, because unauthorized requests would not be passed to the
-  hidden service. This applies to those clients who are aware of a
-  descriptor cookie and thereby of the hidden service descriptor, but do
-  not have authorization data to pass the introduction point or access the
-  service (such a situation might occur when authorization data for
-  authorization at the directory is not issued on a per-user basis, but
-  authorization data for authorization at the introduction point is).
-
-  It is important to note that the introduction point must be considered
-  untrustworthy, and therefore cannot replace authorization at the hidden
-  service itself. Nor should the introduction point learn any sensitive
-  identifiable information from either the service or the client.
-
-  In order to perform authorization at the introduction point, three
-  message formats need to be modified: (1) v2 hidden service descriptors,
-  (2) ESTABLISH_INTRO cells, and (3) INTRODUCE1 cells.
-
-  A v2 hidden service descriptor needs to contain authorization data that
-  is introduction-point-specific and sometimes also authorization data
-  that is introduction-point-independent. Therefore, v2 hidden service
-  descriptors as specified in section 1.2 of rend-spec already contain two
-  reserved fields "intro-authorization" and "service-authorization"
-  (originally, the names of these fields were "...-authentication")
-  containing an authorization type number and arbitrary authorization
-  data. We propose that authorization data consists of base64 encoded
-  objects of arbitrary length, surrounded by "-----BEGIN MESSAGE-----" and
-  "-----END MESSAGE-----". This will increase the size of hidden service
-  descriptors, but this is allowed since there is no strict upper limit.
-
-  The current ESTABLISH_INTRO cells as described in section 1.3 of
-  rend-spec do not contain either authorization data or version
-  information. Therefore, we propose a new version 1 of the ESTABLISH_INTRO
-  cells adding these two issues as follows:
-
-     V      Format byte: set to 255               [1 octet]
-     V      Version byte: set to 1                [1 octet]
-     KL     Key length                           [2 octets]
-     PK     Bob's public key                    [KL octets]
-     HS     Hash of session info                [20 octets]
-     AUTHT  The auth type that is supported       [1 octet]
-     AUTHL  Length of auth data                  [2 octets]
-     AUTHD  Auth data                            [variable]
-     SIG    Signature of above information       [variable]
-
-  From the format it is possible to determine the maximum allowed size for
-  authorization data: given the fact that cells are 512 octets long, of
-  which 498 octets are usable (see section 6.1 of tor-spec), and assuming
-  1024 bit = 128 octet long keys, there are 215 octets left for
-  authorization data. Hence, authorization protocols are bound to use no
-  more than these 215 octets, regardless of the number of clients that
-  shall be authenticated at the introduction point. Otherwise, one would
-  need to send multiple ESTABLISH_INTRO cells or split them up, which we do
-  not specify here.
-
-  In order to understand a v1 ESTABLISH_INTRO cell, the implementation of
-  a relay must have a certain Tor version. Hidden services need to be able
-  to distinguish relays being capable of understanding the new v1 cell
-  formats and perform authorization. We propose to use the version number
-  that is contained in networkstatus documents to find capable
-  introduction points.
-
-  The current INTRODUCE1 cell as described in section 1.8 of rend-spec is
-  not designed to carry authorization data and has no version number, too.
-  Unfortunately, unversioned INTRODUCE1 cells consist only of a fixed-size,
-  seemingly random PK_ID, followed by the encrypted INTRODUCE2 cell. This
-  makes it impossible to distinguish unversioned INTRODUCE1 cells from any
-  later format. In particular, it is not possible to introduce some kind of
-  format and version byte for newer versions of this cell. That's probably
-  where the comment "[XXX011 want to put intro-level auth info here, but no
-  version. crap. -RD]" that was part of rend-spec some time ago comes from.
-
-  We propose that new versioned INTRODUCE1 cells use the new cell type 41
-  RELAY_INTRODUCE1V (where V stands for versioned):
-
-  Cleartext
-     V      Version byte: set to 1                [1 octet]
-     PK_ID  Identifier for Bob's PK             [20 octets]
-     AUTHT  The auth type that is included        [1 octet]
-     AUTHL  Length of auth data                  [2 octets]
-     AUTHD  Auth data                            [variable]
-  Encrypted to Bob's PK:
-     (RELAY_INTRODUCE2 cell)
-
-  The maximum length of contained authorization data depends on the length
-  of the contained INTRODUCE2 cell. A calculation follows below when
-  describing the INTRODUCE2 cell format we propose to use.
-
-  1.3. Client authorization at hidden service
-
-  The time when a hidden service receives an INTRODUCE2 cell constitutes
-  the last possible authorization point during the hidden service
-  protocol. Performing authorization here is easier than at the other two
-  authorization points, because there are no possibly untrusted entities
-  involved.
-
-  In general, a client that is successfully authorized at the introduction
-  point should be granted access at the hidden service, too. Otherwise, the
-  client would receive a positive INTRODUCE_ACK cell from the introduction
-  point and conclude that it may connect to the service, but the request
-  will be dropped without notice. This would appear as a failure to
-  clients. Therefore, the number of cases in which a client successfully
-  passes the introduction point but fails at the hidden service should be
-  zero. However, this does not lead to the conclusion that the
-  authorization data used at the introduction point and the hidden service
-  must be the same, but only that both authorization data should lead to
-  the same authorization result.
-
-  Authorization data is transmitted from client to server via an
-  INTRODUCE2 cell that is forwarded by the introduction point. There are
-  versions 0 to 2 specified in section 1.8 of rend-spec, but none of these
-  contain fields for carrying authorization data. We propose a slightly
-  modified version of v3 INTRODUCE2 cells that is specified in section
-  1.8.1 and which is not implemented as of December 2007. In contrast to
-  the specified v3 we avoid specifying (and implementing) IPv6 capabilities,
-  because Tor relays will be required to support IPv4 addresses for a long
-  time in the future, so that this seems unnecessary at the moment. The
-  proposed format of v3 INTRODUCE2 cells is as follows:
-
-     VER    Version byte: set to 3.               [1 octet]
-     AUTHT  The auth type that is used            [1 octet]
-     AUTHL  Length of auth data                  [2 octets]
-     AUTHD  Auth data                            [variable]
-     TS     Timestamp (seconds since 1-1-1970)   [4 octets]
-     IP     Rendezvous point's address           [4 octets]
-     PORT   Rendezvous point's OR port           [2 octets]
-     ID     Rendezvous point identity ID        [20 octets]
-     KLEN   Length of onion key                  [2 octets]
-     KEY    Rendezvous point onion key        [KLEN octets]
-     RC     Rendezvous cookie                   [20 octets]
-     g^x    Diffie-Hellman data, part 1        [128 octets]
-
-  The maximum possible length of authorization data is related to the
-  enclosing INTRODUCE1V cell. A v3 INTRODUCE2 cell with
-  1024 bit = 128 octets long public key without any authorization data
-  occupies 306 octets (AUTHL is only used when AUTHT has a value != 0),
-  plus 58 octets for hybrid public key encryption (see
-  section 5.1 of tor-spec on hybrid encryption of CREATE cells). The
-  surrounding INTRODUCE1V cell requires 24 octets. This leaves only 110
-  of the 498 available octets free, which must be shared between
-  authorization data to the introduction point _and_ to the hidden
-  service.
-
-  When receiving a v3 INTRODUCE2 cell, Bob checks whether a client has
-  provided valid authorization data to him. He also requires that the
-  timestamp is no more than 30 minutes in the past or future and that the
-  first part of the Diffie-Hellman handshake has not been used in the past
-  60 minutes to prevent replay attacks by rogue introduction points. (The
-  reason for not using the rendezvous cookie to detect replays---even
-  though it is only sent once in the current design---is that it might be
-  desirable to re-use rendezvous cookies for multiple introduction requests
-  in the future.) If all checks pass, Bob builds a circuit to the provided
-  rendezvous point. Otherwise he drops the cell.
-
-  1.4. Summary of authorization data fields
-
-  In summary, the proposed descriptor format and cell formats provide the
-  following fields for carrying authorization data:
-
-  (1) The v2 hidden service descriptor contains:
-      - a descriptor cookie that is used for the lookup process, and
-      - an arbitrary encryption schema to ensure authorization to access
-        introduction information (currently symmetric encryption with the
-        descriptor cookie).
-
-  (2) For performing authorization at the introduction point we can use:
-      - the fields intro-authorization and service-authorization in
-        hidden service descriptors,
-      - a maximum of 215 octets in the ESTABLISH_INTRO cell, and
-      - one part of 110 octets in the INTRODUCE1V cell.
-
-  (3) For performing authorization at the hidden service we can use:
-      - the fields intro-authorization and service-authorization in
-        hidden service descriptors,
-      - the other part of 110 octets in the INTRODUCE2 cell.
-
-  It will also still be possible to access a hidden service without any
-  authorization or only use a part of the authorization infrastructure.
-  However, this requires to consider all parts of the infrastructure. For
-  example, authorization at the introduction point relying on confidential
-  intro-authorization data transported in the hidden service descriptor
-  cannot be performed without using an encryption schema for introduction
-  information.
-
-  1.5. Managing authorization data at servers and clients
-
-  In order to provide authorization data at the hidden service and the
-  authenticated clients, we propose to use files---either the Tor
-  configuration file or separate files. The exact format of these special
-  files depends on the authorization protocol used.
-
-  Currently, rend-spec contains the proposition to encode client-side
-  authorization data in the URL, like in x.y.z.onion. This was never used
-  and is also a bad idea, because in case of HTTP the requested URL may be
-  contained in the Host and Referer fields.
-
-  1.6. Limitations for authorization protocols
-
-  There are two limitations of the current hidden service protocol for
-  authorization protocols that shall be identified here.
-
-    1. The three cell types ESTABLISH_INTRO, INTRODUCE1V, and INTRODUCE2
-       restricts the amount of data that can be used for authorization.
-       This forces authorization protocols that require per-user
-       authorization data at the introduction point to restrict the number
-       of authorized clients artificially. A possible solution could be to
-       split contents among multiple cells and reassemble them at the
-       introduction points.
-
-    2. The current hidden service protocol does not specify cell types to
-       perform interactive authorization between client and introduction
-       point or hidden service. If there should be an authorization
-       protocol that requires interaction, new cell types would have to be
-       defined and integrated into the hidden service protocol.
-
-
-  2. Specific authorization protocol instances
-
-  In the following we present two specific authorization protocols that
-  make use of (parts of) the new authorization infrastructure:
-
-    1. The first protocol allows a service provider to restrict access
-       to clients with a previously received secret key only, but does not
-       attempt to hide service activity from others.
-
-    2. The second protocol, albeit being feasible for a limited set of about
-       16 clients, performs client authorization and hides service activity
-       from everyone but the authorized clients.
-
-  These two protocol instances extend the existing hidden service protocol
-  version 2. Hidden services that perform client authorization may run in
-  parallel to other services running versions 0, 2, or both.
-
-  2.1. Service with large-scale client authorization
-
-  The first client authorization protocol aims at performing access control
-  while consuming as few additional resources as possible. A service
-  provider should be able to permit access to a large number of clients
-  while denying access for everyone else. However, the price for
-  scalability is that the service won't be able to hide its activity from
-  unauthorized or formerly authorized clients.
-
-  The main idea of this protocol is to encrypt the introduction-point part
-  in hidden service descriptors to authorized clients using symmetric keys.
-  This ensures that nobody else but authorized clients can learn which
-  introduction points a service currently uses, nor can someone send a
-  valid INTRODUCE1 message without knowing the introduction key. Therefore,
-  a subsequent authorization at the introduction point is not required.
-
-  A service provider generates symmetric "descriptor cookies" for his
-  clients and distributes them outside of Tor. The suggested key size is
-  128 bits, so that descriptor cookies can be encoded in 22 base64 chars
-  (which can hold up to 22 * 5 = 132 bits, leaving 4 bits to encode the
-  authorization type (here: "0") and allow a client to distinguish this
-  authorization protocol from others like the one proposed below).
-  Typically, the contact information for a hidden service using this
-  authorization protocol looks like this:
-
-    v2cbb2l4lsnpio4q.onion Ll3X7Xgz9eHGKCCnlFH0uz
-
-  When generating a hidden service descriptor, the service encrypts the
-  introduction-point part with a single randomly generated symmetric
-  128-bit session key using AES-CTR as described for v2 hidden service
-  descriptors in rend-spec. Afterwards, the service encrypts the session
-  key to all descriptor cookies using AES. Authorized client should be able
-  to efficiently find the session key that is encrypted for him/her, so
-  that 4 octet long client ID are generated consisting of descriptor cookie
-  and initialization vector. Descriptors always contain a number of
-  encrypted session keys that is a multiple of 16 by adding fake entries.
-  Encrypted session keys are ordered by client IDs in order to conceal
-  addition or removal of authorized clients by the service provider.
-
-     ATYPE  Authorization type: set to 1.                      [1 octet]
-     ALEN   Number of clients := 1 + ((clients - 1) div 16)    [1 octet]
-   for each symmetric descriptor cookie:
-     ID     Client ID: H(descriptor cookie | IV)[:4]          [4 octets]
-     SKEY   Session key encrypted with descriptor cookie     [16 octets]
-   (end of client-specific part)
-     RND    Random data      [(15 - ((clients - 1) mod 16)) * 20 octets]
-     IV     AES initialization vector                        [16 octets]
-     IPOS   Intro points, encrypted with session key  [remaining octets]
-
-  An authorized client needs to configure Tor to use the descriptor cookie
-  when accessing the hidden service. Therefore, a user adds the contact
-  information that she received from the service provider to her torrc
-  file. Upon downloading a hidden service descriptor, Tor finds the
-  encrypted introduction-point part and attempts to decrypt it using the
-  configured descriptor cookie. (In the rare event of two or more client
-  IDs being equal a client tries to decrypt all of them.)
-
-  Upon sending the introduction, the client includes her descriptor cookie
-  as auth type "1" in the INTRODUCE2 cell that she sends to the service.
-  The hidden service checks whether the included descriptor cookie is
-  authorized to access the service and either responds to the introduction
-  request, or not.
-
-  2.2. Authorization for limited number of clients
-
-  A second, more sophisticated client authorization protocol goes the extra
-  mile of hiding service activity from unauthorized clients. With all else
-  being equal to the preceding authorization protocol, the second protocol
-  publishes hidden service descriptors for each user separately and gets
-  along with encrypting the introduction-point part of descriptors to a
-  single client. This allows the service to stop publishing descriptors for
-  removed clients. As long as a removed client cannot link descriptors
-  issued for other clients to the service, it cannot derive service
-  activity any more. The downside of this approach is limited scalability.
-  Even though the distributed storage of descriptors (cf. proposal 114)
-  tackles the problem of limited scalability to a certain extent, this
-  protocol should not be used for services with more than 16 clients. (In
-  fact, Tor should refuse to advertise services for more than this number
-  of clients.)
-
-  A hidden service generates an asymmetric "client key" and a symmetric
-  "descriptor cookie" for each client. The client key is used as
-  replacement for the service's permanent key, so that the service uses a
-  different identity for each of his clients. The descriptor cookie is used
-  to store descriptors at changing directory nodes that are unpredictable
-  for anyone but service and client, to encrypt the introduction-point
-  part, and to be included in INTRODUCE2 cells. Once the service has
-  created client key and descriptor cookie, he tells them to the client
-  outside of Tor. The contact information string looks similar to the one
-  used by the preceding authorization protocol (with the only difference
-  that it has "1" encoded as auth-type in the remaining 4 of 132 bits
-  instead of "0" as before).
-
-  When creating a hidden service descriptor for an authorized client, the
-  hidden service uses the client key and descriptor cookie to compute
-  secret ID part and descriptor ID:
-
-    secret-id-part = H(time-period | descriptor-cookie | replica)
-
-    descriptor-id = H(client-key[:10] | secret-id-part)
-
-  The hidden service also replaces permanent-key in the descriptor with
-  client-key and encrypts introduction-points with the descriptor cookie.
-
-     ATYPE  Authorization type: set to 2.                         [1 octet]
-     IV     AES initialization vector                           [16 octets]
-     IPOS   Intro points, encr. with descriptor cookie   [remaining octets]
-
-  When uploading descriptors, the hidden service needs to make sure that
-  descriptors for different clients are not uploaded at the same time (cf.
-  Section 1.1) which is also a limiting factor for the number of clients.
-
-  When a client is requested to establish a connection to a hidden service
-  it looks up whether it has any authorization data configured for that
-  service. If the user has configured authorization data for authorization
-  protocol "2", the descriptor ID is determined as described in the last
-  paragraph. Upon receiving a descriptor, the client decrypts the
-  introduction-point part using its descriptor cookie. Further, the client
-  includes its descriptor cookie as auth-type "2" in INTRODUCE2 cells that
-  it sends to the service.
-
-  2.3. Hidden service configuration
-
-  A hidden service that is meant to perform client authorization adds a
-  new option HiddenServiceAuthorizeClient to its hidden service
-  configuration. This option contains the authorization type which is
-  either "1" for the protocol described in 2.1 or "2" for the protocol in
-  2.2 and a comma-separated list of human-readable client names, so that
-  Tor can create authorization data for these clients:
-
-    HiddenServiceAuthorizeClient auth-type client-name,client-name,...
-
-  If this option is configured, HiddenServiceVersion is automatically
-  reconfigured to contain only version numbers of 2 or higher.
-
-  Tor stores all generated authorization data for the authorization
-  protocols described in Sections 2.1 and 2.2 in a new file using the
-  following file format:
-
-     "client-name" human-readable client identifier NL
-     "descriptor-cookie" 128-bit key ^= 22 base64 chars NL
-
-  If the authorization protocol of Section 2.2 is used, Tor also generates
-  and stores the following data:
-
-     "client-key" NL a public key in PEM format
-
-  2.4. Client configuration
-
-  Clients need to make their authorization data known to Tor using another
-  configuration option that contains a service name (mainly for the sake of
-  convenience), the service address, and the descriptor cookie that is
-  required to access a hidden service (the authorization protocol number is
-  encoded in the descriptor cookie):
-
-    HidServAuth service-name service-address descriptor-cookie
-
-Security implications:
-
-  In the following we want to discuss possible attacks by dishonest
-  entities in the presented infrastructure and specific protocol. These
-  security implications would have to be verified once more when adding
-  another protocol. The dishonest entities (theoretically) include the
-  hidden service itself, the authenticated clients, hidden service directory
-  nodes, introduction points, and rendezvous points. The relays that are
-  part of circuits used during protocol execution, but never learn about
-  the exchanged descriptors or cells by design, are not considered.
-  Obviously, this list makes no claim to be complete. The discussed attacks
-  are sorted by the difficulty to perform them, in ascending order,
-  starting with roles that everyone could attempt to take and ending with
-  partially trusted entities abusing the trust put in them.
-
-  (1) A hidden service directory could attempt to conclude presence of a
-  service from the existence of a locally stored hidden service descriptor:
-  This passive attack is possible only for a single client-service
-  relation, because descriptors need to contain a publicly visible
-  signature of the service using the client key.
-  A possible protection would be to increase the number of hidden service
-  directories in the network.
-
-  (2) A hidden service directory could try to break the descriptor cookies
-  of locally stored descriptors: This attack can be performed offline. The
-  only useful countermeasure against it might be using safe passwords that
-  are generated by Tor.
-
-[passwords? where did those come in? -RD]
-
-  (3) An introduction point could try to identify the pseudonym of the
-  hidden service on behalf of which it operates: This is impossible by
-  design, because the service uses a fresh public key for every
-  establishment of an introduction point (see proposal 114) and the
-  introduction point receives a fresh introduction cookie, so that there is
-  no identifiable information about the service that the introduction point
-  could learn. The introduction point cannot even tell if client accesses
-  belong to the same client or not, nor can it know the total number of
-  authorized clients. The only information might be the pattern of
-  anonymous client accesses, but that is hardly enough to reliably identify
-  a specific service.
-
-  (4) An introduction point could want to learn the identities of accessing
-  clients: This is also impossible by design, because all clients use the
-  same introduction cookie for authorization at the introduction point.
-
-  (5) An introduction point could try to replay a correct INTRODUCE1 cell
-  to other introduction points of the same service, e.g. in order to force
-  the service to create a huge number of useless circuits: This attack is
-  not possible by design, because INTRODUCE1 cells are encrypted using a
-  freshly created introduction key that is only known to authorized
-  clients.
-
-  (6) An introduction point could attempt to replay a correct INTRODUCE2
-  cell to the hidden service, e.g. for the same reason as in the last
-  attack: This attack is stopped by the fact that a service will drop
-  INTRODUCE2 cells containing a DH handshake they have seen recently.
-
-  (7) An introduction point could block client requests by sending either
-  positive or negative INTRODUCE_ACK cells back to the client, but without
-  forwarding INTRODUCE2 cells to the server: This attack is an annoyance
-  for clients, because they might wait for a timeout to elapse until trying
-  another introduction point. However, this attack is not introduced by
-  performing authorization and it cannot be targeted towards a specific
-  client. A countermeasure might be for the server to periodically perform
-  introduction requests to his own service to see if introduction points
-  are working correctly.
-
-  (8) The rendezvous point could attempt to identify either server or
-  client: This remains impossible as it was before, because the
-  rendezvous cookie does not contain any identifiable information.
-
-  (9) An authenticated client could swamp the server with valid INTRODUCE1
-  and INTRODUCE2 cells, e.g. in order to force the service to create
-  useless circuits to rendezvous points; as opposed to an introduction
-  point replaying the same INTRODUCE2 cell, a client could include a new
-  rendezvous cookie for every request: The countermeasure for this attack
-  is the restriction to 10 connection establishments per client per hour.
-
-Compatibility:
-
-  An implementation of this proposal would require changes to hidden
-  services and clients to process authorization data and encode and
-  understand the new formats. However, both services and clients would
-  remain compatible to regular hidden services without authorization.
-
-Implementation:
-
-  The implementation of this proposal can be divided into a number of
-  changes to hidden service and client side. There are no
-  changes necessary on directory, introduction, or rendezvous nodes. All
-  changes are marked with either [service] or [client] do denote on which
-  side they need to be made.
-
-  /1/ Configure client authorization [service]
-
-  - Parse configuration option HiddenServiceAuthorizeClient containing
-    authorized client names.
-  - Load previously created client keys and descriptor cookies.
-  - Generate missing client keys and descriptor cookies, add them to
-    client_keys file.
-  - Rewrite the hostname file.
-  - Keep client keys and descriptor cookies of authorized clients in
-    memory.
- [- In case of reconfiguration, mark which client authorizations were
-    added and whether any were removed. This can be used later when
-    deciding whether to rebuild introduction points and publish new
-    hidden service descriptors. Not implemented yet.]
-
-  /2/ Publish hidden service descriptors [service]
-
-  - Create and upload hidden service descriptors for all authorized
-    clients.
- [- See /1/ for the case of reconfiguration.]
-
-  /3/ Configure permission for hidden services [client]
-
-  - Parse configuration option HidServAuth containing service
-    authorization, store authorization data in memory.
-
-  /5/ Fetch hidden service descriptors [client]
-
-  - Look up client authorization upon receiving a hidden service request.
-  - Request hidden service descriptor ID including client key and
-    descriptor cookie. Only request v2 descriptors, no v0.
-
-  /6/ Process hidden service descriptor [client]
-
-  - Decrypt introduction points with descriptor cookie.
-
-  /7/ Create introduction request [client]
-
-  - Include descriptor cookie in INTRODUCE2 cell to introduction point.
-  - Pass descriptor cookie around between involved connections and
-    circuits.
-
-  /8/ Process introduction request [service]
-
-  - Read descriptor cookie from INTRODUCE2 cell.
-  - Check whether descriptor cookie is authorized for access, including
-    checking access counters.
-  - Log access for accountability.
-
diff --git a/doc/spec/proposals/122-unnamed-flag.txt b/doc/spec/proposals/122-unnamed-flag.txt
deleted file mode 100644
index 6502b9c..0000000
--- a/doc/spec/proposals/122-unnamed-flag.txt
+++ /dev/null
@@ -1,138 +0,0 @@
-Filename: 122-unnamed-flag.txt
-Title: Network status entries need a new Unnamed flag
-Version: $Revision$
-Last-Modified: $Date$
-Author: Roger Dingledine
-Created: 04-Oct-2007
-Status: Closed
-Implemented-In: 0.2.0.x
-
-1. Overview:
-
-  Tor's directory authorities can give certain servers a "Named" flag
-  in the network-status entry, when they want to bind that nickname to
-  that identity key. This allows clients to specify a nickname rather
-  than an identity fingerprint and still be certain they're getting the
-  "right" server. As dir-spec.txt describes it,
-
-    Name X is bound to identity Y if at least one binding directory lists
-    it, and no directory binds X to some other Y'.
-
-  In practice, clients can refer to servers by nickname whether they are
-  Named or not; if they refer to nicknames that aren't Named, a complaint
-  shows up in the log asking them to use the identity key in the future
-  --- but it still works.
-
-  The problem? Imagine a Tor server with nickname Bob. Bob and his
-  identity fingerprint are registered in tor26's approved-routers
-  file, but none of the other authorities registered him. Imagine
-  there are several other unregistered servers also with nickname Bob
-  ("the imposters").
-
-  While Bob is online, all is well: a) tor26 gives a Named flag to
-  the real one, and refuses to list the other ones; and b) the other
-  authorities list the imposters but don't give them a Named flag. Clients
-  who have all the network-statuses can compute which one is the real Bob.
-
-  But when the real Bob disappears and his descriptor expires? tor26
-  continues to refuse to list any of the imposters, and the other
-  authorities continue to list the imposters. Clients don't have any
-  idea that there exists a Named Bob, so they can ask for server Bob and
-  get one of the imposters. (A warning will also appear in their log,
-  but so what.)
-
-2. The stopgap solution:
-
-  tor26 should start accepting and listing the imposters, but it should
-  assign them a new flag: "Unnamed".
-
-  This would produce three cases in terms of assigning flags in the consensus
-  networkstatus:
-
-  i) a router gets the Named flag in the v3 networkstatus if
-    a) it's the only router with that nickname that has the Named flag
-       out of all the votes, and
-    b) no vote lists it as Unnamed
-  else,
-  ii) a router gets the Unnamed flag if
-    a) some vote lists a different router with that nickname as Named, or
-    b) at least one vote lists it as Unnamed, or
-    c) there are other routers with the same nickname that are Unnamed
-  else,
-  iii) the router neither gets a Named nor an Unnamed flag.
-
-  (This whole proposal is meant only for v3 dir flags; we shouldn't try
-  to backport it to the v2 dir world.)
-
-  Then client behavior is:
-
-  a) If there's a Bob with a Named flag, pick that one.
-  else b) If the Bobs don't have the Unnamed flag (notice that they should
-          either all have it, or none), pick one of them and warn.
-  else c) They all have the Unnamed flag -- no router found.
-
-3. Problems not solved by this stopgap:
-
-  3.1. Naming authorities can go offline.
-
-  If tor26 is the only authority that provides a binding for Bob, when
-  tor26 goes offline we're back in our previous situation -- the imposters
-  can be referenced with a mere ignorable warning in the client's log.
-
-  If some other authority Names a different Bob, and tor26 goes offline,
-  then that other Bob becomes the unique Named Bob.
-
-  So be it. We should try to solve these one day, but there's no clear way
-  to do it that doesn't destroy usability in other ways, and if we want
-  to get the Unnamed flag into v3 network statuses we should add it soon.
-
-  3.2. V3 dir spec magnifies brief discrepancies.
-
-  Another point to notice is if tor26 names Bob(1), doesn't know about
-  Bob(2), but moria lists Bob(2). Then Bob(2) doesn't get an Unnamed flag
-  even if it should (and Bob(1) is not around).
-
-  Right now, in v2 dirs, the case where an authority doesn't know about
-  a server but the other authorities do know is rare. That's because
-  authorities periodically ask for other networkstatuses and then fetch
-  descriptors that are missing.
-
-  With v3, if that window occurs at the wrong time, it is extended for the
-  entire period. We could solve this by making the voting more complex,
-  but that doesn't seem worth it.
-
-  [3.3. Tor26 is only one tor26.
-
-  We need more naming authorities, possibly with some kind of auto-naming
-  feature.  This is out-of-scope for this proposal -NM]
-
-4. Changes to the v2 directory
-
-  Previously, v2 authorities that had a binding for a server named Bob did
-  not list any other server named Bob.  This will change too:
-
-  Version 2 authorities will start listing all routers they know about,
-  whether they conflict with a name-binding or not:  Servers for which
-  this authority has a binding will continue to be marked Named,
-  additionally all other servers of that nickname will be listed without the
-  Named flag (i.e. there will be no Unnamed flag in v2 status documents).
-
-  Clients already should handle having a named Bob alongside unnamed
-  Bobs correctly, and having the unnamed Bobs in the status file even
-  without the named server is no worse than the current status quo where
-  clients learn about those servers from other authorities.
-
-  The benefit of this is that an authority's opinion on a server like
-  Guard, Stable, Fast etc. can now be learned by clients even if that
-  specific authority has reserved that server's name for somebody else.
-
-5. Other benefits:
-
-  This new flag will allow people to operate servers that happen to have
-  the same nickname as somebody who registered their server two years ago
-  and left soon after. Right now there are dozens of nicknames that are
-  registered on all three binding directory authorities, yet haven't been
-  running for years. While it's bad that these nicknames are effectively
-  blacklisted from the network, the really bad part is that this logic
-  is really unintuitive to prospective new server operators.
-
diff --git a/doc/spec/proposals/123-autonaming.txt b/doc/spec/proposals/123-autonaming.txt
deleted file mode 100644
index 6cd2532..0000000
--- a/doc/spec/proposals/123-autonaming.txt
+++ /dev/null
@@ -1,56 +0,0 @@
-Filename: 123-autonaming.txt
-Title: Naming authorities automatically create bindings
-Version: $Revision$
-Last-Modified: $Date$
-Author: Peter Palfrader
-Created: 2007-10-11
-Status: Closed
-Implemented-In: 0.2.0.x
-
-Overview:
-
-  Tor's directory authorities can give certain servers a "Named" flag
-  in the network-status entry, when they want to bind that nickname to
-  that identity key. This allows clients to specify a nickname rather
-  than an identity fingerprint and still be certain they're getting the
-  "right" server.
-
-  Authority operators name a server by adding their nickname and
-  identity fingerprint to the 'approved-routers' file.  Historically
-  being listed in the file was required for a router, at first for being
-  listed in the directory at all, and later in order to be used by
-  clients as a first or last hop of a circuit.
-
-  Adding identities to the list of named routers so far has been a
-  manual, time consuming, and boring job.  Given that and the fact that
-  the Tor network works just fine without named routers the last
-  authority to keep a current binding list stopped updating it well over
-  half a year ago.
-
-  Naming, if it were done, would serve a useful purpose however in that
-  users can have a reasonable expectation that the exit server Bob they
-  are using in their http://www.google.com.bob.exit/ URL is the same
-  Bob every time.
-
-Proposal:
-  I propose that identity<->name binding be completely automated:
-
-  New bindings should be added after the router has been around for a
-  bit and their name has not been used by other routers, similarly names
-  that have not appeared on the network for a long time should be freed
-  in case a new router wants to use it.
-
-  The following rules are suggested:
-  i) If a named router has not been online for half a year, the
-     identity<->name binding for that name is removed.  The nickname
-     is free to be taken by other routers now.
-  ii) If a router claims a certain nickname and
-       a) has been on the network for at least two weeks, and
-       b) that nickname is not yet linked to a different router, and
-       c) no other router has wanted that nickname in the last month,
-      a new binding should be created for this router and its desired
-      nickname.
-
- This automaton does not necessarily need to live in the Tor code, it
- can do its job just as well when it's an external tool.
-
diff --git a/doc/spec/proposals/124-tls-certificates.txt b/doc/spec/proposals/124-tls-certificates.txt
deleted file mode 100644
index 0a47772..0000000
--- a/doc/spec/proposals/124-tls-certificates.txt
+++ /dev/null
@@ -1,315 +0,0 @@
-Filename: 124-tls-certificates.txt
-Title: Blocking resistant TLS certificate usage
-Version: $Revision$
-Last-Modified: $Date$
-Author: Steven J. Murdoch
-Created: 2007-10-25
-Status: Superseded
-
-Overview:
-
-  To be less distinguishable from HTTPS web browsing, only Tor servers should
-  present TLS certificates. This should be done whilst maintaining backwards
-  compatibility with Tor nodes which present and expect client certificates, and
-  while preserving existing security properties. This specification describes
-  the negotiation protocol, what certificates should be presented during the TLS
-  negotiation, and how to move the client authentication within the encrypted
-  tunnel.
-
-Motivation:
-
-  In Tor's current TLS [1] handshake, both client and server present a
-  two-certificate chain. Since TLS performs authentication prior to establishing
-  the encrypted tunnel, the contents of these certificates are visible to an
-  eavesdropper. In contrast, during normal HTTPS web browsing, the server
-  presents a single certificate, signed by a root CA and the client presents no
-  certificate. Hence it is possible to distinguish Tor from HTTP by identifying
-  this pattern.
-
-  To resist blocking based on traffic identification, Tor should behave as close
-  to HTTPS as possible, i.e. servers should offer a single certificate and not
-  request a client certificate; clients should present no certificate. This
-  presents two difficulties: clients are no longer authenticated and servers are
-  authenticated by the connection key, rather than identity key. The link
-  protocol must thus be modified to preserve the old security semantics.
-
-  Finally, in order to maintain backwards compatibility, servers must correctly
-  identify whether the client supports the modified certificate handling. This
-  is achieved by modifying the cipher suites that clients advertise support
-  for. These cipher suites are selected to be similar to those chosen by web
-  browsers, in order to resist blocking based on client hello.
-
-Terminology:
-
-  Initiator: OP or OR which initiates a TLS connection ("client" in TLS
-   terminology)
-  
-  Responder: OR which receives an incoming TLS connection ("server" in TLS
-   terminology) 
-
-Version negotiation and cipher suite selection:
-
-  In the modified TLS handshake, the responder does not request a certificate
-  from the initiator. This request would normally occur immediately after the
-  responder receives the client hello (the first message in a TLS handshake) and
-  so the responder must decide whether to request a certificate based only on
-  the information in the client hello. This is achieved by examining the cipher
-  suites in the client hello.
-
-   List 1: cipher suites lists offered by version 0/1 Tor
-
-   From src/common/tortls.c, revision 12086:
-    TLS1_TXT_DHE_RSA_WITH_AES_128_SHA 
-    TLS1_TXT_DHE_RSA_WITH_AES_128_SHA : SSL3_TXT_EDH_RSA_DES_192_CBC3_SHA
-    SSL3_TXT_EDH_RSA_DES_192_CBC3_SHA
-
- Client hello sent by initiator:
-
-  Initiators supporting version 2 of the Tor connection protocol MUST
-  offer a different cipher suite list from those sent by pre-version 2
-  Tors, contained in List 1. To maintain compatibility with older Tor
-  versions and common browsers, the cipher suite list MUST include
-  support for:
-
-   TLS_DHE_RSA_WITH_AES_256_CBC_SHA
-   TLS_DHE_RSA_WITH_AES_128_CBC_SHA
-   SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
-   SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
-
- Client hello received by responder/server hello sent by responder:
-
-  Responders supporting version 2 of the Tor connection protocol should compare
-  the cipher suite list in the client hello with those in List 1. If it matches
-  any in the list then the responder should assume that the initiatior supports
-  version 1, and thus should maintain the version 1 behavior, i.e. send a
-  two-certificate chain, request a client certificate and do not send or expect
-  a VERSIONS cell [2].
-
-  Otherwise, the responder should assume version 2 behavior and select a cipher
-  suite following TLS [1] behavior, i.e. select the first entry from the client
-  hello cipher list which is acceptable. Responders MUST NOT select any suite
-  that lacks ephemeral keys, or whose symmetric keys are less then KEY_LEN bits,
-  or whose digests are less than HASH_LEN bits. Implementations SHOULD NOT
-  allow other SSLv3 ciphersuites. 
-
-  Should no mutually acceptable cipher suite be found, the connection MUST be
-  closed.
-
-  If the responder is implementing version 2 of the connection protocol it
-  SHOULD send a server certificate with random contents. The organizationName
-  field MUST NOT be "Tor", "TOR" or "t o r".
-
- Server certificate received by initiator:
-
-  If the server certificate has an organizationName of "Tor", "TOR" or "t o r",
-  the initiator should assume that the responder does not support version 2 of
-  the connection protocol. In which case the initiator should respond following
-  version 1, i.e. send a two-certificate client chain and do not send or expect
-  a VERSIONS cell.
-
-  [SJM: We could also use the fact that a client certificate request was sent]
-  
-  If the server hello contains a ciphersuite which does not comply with the key
-  length requirements above, even if it was one offered in the client hello, the
-  connection MUST be closed. This will only occur if the responder is not a Tor
-  server.
-
- Backward compatibility:
-
-  v1 Initiator, v1 Responder: No change
-  v1 Initiator, v2 Responder: Responder detects v1 initiator by client hello
-  v2 Initiator, v1 Responder: Responder accepts v2 client hello. Initiator
-   detects v1 server certificate and continues with v1 protocol
-  v2 Initiator, v2 Responder: Responder accepts v2 client hello. Initiator
-   detects v2 server certificate and continues with v2 protocol.
-
- Additional link authentication process:
-
-  Following VERSION and NETINFO negotiation, both responder and
-  initiator MUST send a certification chain in a CERT cell. If one
-  party does not have a certificate, the CERT cell MUST still be sent,
-  but with a length of zero.
-
-  A CERT cell is a variable length cell, of the format
-        CircID                                [2 bytes]
-        Command                               [1 byte]
-        Length                                [2 bytes]
-        Payload                               [<length> bytes]
-
-  CircID MUST set to be 0x0000
-  Command is [SJM: TODO]
-  Length is the length of the payload
-  Payload contains 0 or more certificates, each is of the format:
-        Cert_Length  [2 bytes]
-        Certificate  [<cert_length> bytes]
-
-  Each certificate MUST sign the one preceding it. The initator MUST
-  place its connection certificate first; the responder, having
-  already sent its connection certificate as part of the TLS handshake
-  MUST place its identity certificate first.
-
-  Initiators who send a CERT cell MUST follow that with an LINK_AUTH
-  cell to prove that they posess the corresponding private key.  
-
-  A LINK_AUTH cell is fixed-lenth, of the format:
-         CircID                                [2 bytes]
-         Command                               [1 byte]
-         Length                                [2 bytes]
-         Payload (padded with 0 bytes)         [PAYLOAD_LEN - 2 bytes]
-
-  CircID MUST set to be 0x0000
-  Command is [SJM: TODO]
-  Length is the valid portion of the payload
-  Payload is of the format:
-         Signature version                     [1 byte]
-         Signature                             [<length> - 1 bytes]
-         Padding                               [PAYLOAD_LEN - <length> - 2 bytes]
-
-  Signature version: Identifies the type of signature, currently 0x00
-  Signature: Digital signature under the initiator's connection key of the
-   following item, in PKCS #1 block type 1 [3] format:
-
-    HMAC-SHA1, using the TLS master secret as key, of the
-    following elements concatenated:
-     - The signature version (0x00)
-     - The NUL terminated ASCII string: "Tor initiator certificate verification"
-     - client_random, as sent in the Client Hello
-     - server_random, as sent in the Server Hello
-     - SHA-1 hash of the initiator connection certificate
-     - SHA-1 hash of the responder connection certificate
-
-  Security checks:
-
-    - Before sending a LINK_AUTH cell, a node MUST ensure that the TLS
-      connection is authenticated by the responder key.
-    - For the handshake to have succeeded, the initiator MUST confirm:
-       - That the TLS handshake was authenticated by the 
-         responder connection key
-       - That the responder connection key was signed by the first
-         certificate in the CERT cell
-       - That each certificate in the CERT cell was signed by the
-         following certificate, with the exception of the last
-       - That the last certificate in the CERT cell is the expected
-         identity certificate for the node being connected to
-    - For the handshake to have succeeded, the responder MUST confirm
-      either:
-       A) - A zero length CERT cell was sent and no LINK_AUTH cell was
-            sent
-          In which case the responder shall treat the identity of the
-          initiator as unknown
-        or
-       B) - That the LINK_AUTH MAC contains a signature by the first
-            certificate in the CERT cell
-          - That the MAC signed matches the expected value
-          - That each certificate in the CERT cell was signed by the
-            following certificate, with the exception of the last
-          In which case the responder shall treat the identity of the
-          initiator as that of the last certificate in the CERT cell
-
-  Protocol summary:
-
-  1. I(nitiator) <-> R(esponder): TLS handshake, including responder
-                               authentication under connection certificate R_c
-  2. I <->: VERSION and NETINFO negotiation
-  3. R -> I: CERT (Responder identity certificate R_i (which signs R_c))
-  4. I -> R: CERT (Initiator connection certificate I_c, 
-                   Initiator identity certificate I_i (which signs I_c)
-  5. I -> R: LINK_AUTH (Signature, under I_c of HMAC-SHA1(master_secret,
-                    "Tor initiator certificate verification" ||
-                    client_random || server_random ||
-                    I_c hash || R_c hash)
-
-  Notes: I -> R doesn't need to wait for R_i before sending its own
-   messages (reduces round-trips).
-   Certificate hash is calculated like identity hash in CREATE cells.
-   Initiator signature is calculated in a similar way to Certificate
-   Verify messages in TLS 1.1 (RFC4346, Sections 7.4.8 and 4.7).
-   If I is an OP, a zero length certificate chain may be sent in step 4;
-   In which case, step 5 is not performed
-
-  Rationale: 
-
-  - Version and netinfo negotiation before authentication: The version cell needs
-   to come before before the rest of the protocol, since we may choose to alter
-   the rest at some later point, e.g switch to a different MAC/signature scheme.
-   It is useful to keep the NETINFO and VERSION cells close to each other, since
-   the time between them is used to check if there is a delay-attack. Still, a
-   server might want to not act on NETINFO data from an initiator until the
-   authentication is complete.
-
-Appendix A: Cipher suite choices
-
-  This specification intentionally does not put any constraints on the
-  TLS ciphersuite lists presented by clients, other than a minimum
-  required for compatibility. However, to maximize blocking
-  resistance, ciphersuite lists should be carefully selected.
-
-   Recommended client ciphersuite list
-
-     Source: http://lxr.mozilla.org/security/source/security/nss/lib/ssl/sslproto.h
-
-     0xc00a: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA  
-     0xc014: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 
-     0x0039: TLS_DHE_RSA_WITH_AES_256_CBC_SHA 
-     0x0038: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
-     0xc00f: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA 
-     0xc005: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA 
-     0x0035: TLS_RSA_WITH_AES_256_CBC_SHA
-     0xc007: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA 
-     0xc009: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA 
-     0xc011: TLS_ECDHE_RSA_WITH_RC4_128_SHA
-     0xc013: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 
-     0x0033: TLS_DHE_RSA_WITH_AES_128_CBC_SHA 
-     0x0032: TLS_DHE_DSS_WITH_AES_128_CBC_SHA 
-     0xc00c: TLS_ECDH_RSA_WITH_RC4_128_SHA
-     0xc00e: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
-     0xc002: TLS_ECDH_ECDSA_WITH_RC4_128_SHA  
-     0xc004: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA 
-     0x0004: SSL_RSA_WITH_RC4_128_MD5 
-     0x0005: SSL_RSA_WITH_RC4_128_SHA 
-     0x002f: TLS_RSA_WITH_AES_128_CBC_SHA 
-     0xc008: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA 
-     0xc012: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
-     0x0016: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA  
-     0x0013: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA 
-     0xc00d: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA 
-     0xc003: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
-     0xfeff: SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA (168-bit Triple DES with RSA and a SHA1 MAC)
-     0x000a: SSL_RSA_WITH_3DES_EDE_CBC_SHA 
-
-     Order specified in:
-      http://lxr.mozilla.org/security/source/security/nss/lib/ssl/sslenum.c#47
-
-   Recommended options:
-      0x0000: Server Name Indication [4]
-      0x000a: Supported Elliptic Curves [5]
-      0x000b: Supported Point Formats [5]
-
-   Recommended compression:
-      0x00
-
-   Recommended server ciphersuite selection:
-
-     The responder should select the first entry in this list which is
-     listed in the client hello:
-
-     0x0039: TLS_DHE_RSA_WITH_AES_256_CBC_SHA  [ Common Firefox choice ]
-     0x0033: TLS_DHE_RSA_WITH_AES_128_CBC_SHA  [ Tor v1 default ] 
-     0x0016: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA [ Tor v1 fallback ]
-     0x0013: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA [ Valid IE option ]
-
-References:
-
-[1] The Transport Layer Security (TLS) Protocol, Version 1.1, RFC4346, IETF
-
-[2] Version negotiation for the Tor protocol, Tor proposal 105
-
-[3] B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1:
-    RSA Cryptography Specifications Version 1.5", RFC 2313,
-    March 1998.
-
-[4] TLS Extensions, RFC 3546
-
-[5] Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
-
-% <!-- Local IspellDict: american -->
diff --git a/doc/spec/proposals/125-bridges.txt b/doc/spec/proposals/125-bridges.txt
deleted file mode 100644
index 8bb3169..0000000
--- a/doc/spec/proposals/125-bridges.txt
+++ /dev/null
@@ -1,293 +0,0 @@
-Filename: 125-bridges.txt
-Title: Behavior for bridge users, bridge relays, and bridge authorities
-Version: $Revision$
-Last-Modified: $Date$
-Author: Roger Dingledine
-Created: 11-Nov-2007
-Status: Closed
-Implemented-In: 0.2.0.x
-
-0. Preface
-
-  This document describes the design decisions around support for bridge
-  users, bridge relays, and bridge authorities. It acts as an overview
-  of the bridge design and deployment for developers, and it also tries
-  to point out limitations in the current design and implementation.
-
-  For more details on what all of these mean, look at blocking.tex in
-  /doc/design-paper/
-
-1. Bridge relays
-
-  Bridge relays are just like normal Tor relays except they don't publish
-  their server descriptors to the main directory authorities.
-
-1.1. PublishServerDescriptor
-
-  To configure your relay to be a bridge relay, just add
-    BridgeRelay 1
-    PublishServerDescriptor bridge
-  to your torrc. This will cause your relay to publish its descriptor
-  to the bridge authorities rather than to the default authorities.
-
-  Alternatively, you can say
-    BridgeRelay 1
-    PublishServerDescriptor 0
-  which will cause your relay to not publish anywhere. This could be
-  useful for private bridges.
-
-1.2. Exit policy
-
-  Bridge relays should use an exit policy of "reject *:*". This is
-  because they only need to relay traffic between the bridge users
-  and the rest of the Tor network, so there's no need to let people
-  exit directly from them.
-
-1.3. RelayBandwidthRate / RelayBandwidthBurst
-
-  We invented the RelayBandwidth* options for this situation: Tor clients
-  who want to allow relaying too. See proposal 111 for details. Relay
-  operators should feel free to rate-limit their relayed traffic.
-
-1.4. Helping the user with port forwarding, NAT, etc.
-
-  Just as for operating normal relays, our documentation and hints for
-  how to make your ORPort reachable are inadequate for normal users.
-
-  We need to work harder on this step, perhaps in 0.2.2.x.
-
-1.5. Vidalia integration
-
-  Vidalia has turned its "Relay" settings page into a tri-state
-  "Don't relay" / "Relay for the Tor network" / "Help censored users".
-
-  If you click the third choice, it forces your exit policy to reject *:*.
-
-  If all the bridges end up on port 9001, that's not so good. On the
-  other hand, putting the bridges on a low-numbered port in the Unix
-  world requires jumping through extra hoops. The current compromise is
-  that Vidalia makes the ORPort default to 443 on Windows, and 9001 on
-  other platforms.
-
-  At the bottom of the relay config settings window, Vidalia displays
-  the bridge identifier to the operator (see Section 3.1) so he can pass
-  it on to bridge users.
-
-1.6. What if the default ORPort is already used?
-
-  If the user already has a webserver or some other application
-  bound to port 443, then Tor will fail to bind it and complain to the
-  user, probably in a cryptic way. Rather than just working on a better
-  error message (though we should do this), we should consider an
-  "ORPort auto" option that tells Tor to try to find something that's
-  bindable and reachable. This would also help us tolerate ISPs that
-  filter incoming connections on port 80 and port 443. But this should
-  be a different proposal, and can wait until 0.2.2.x.
-
-2. Bridge authorities.
-
-  Bridge authorities are like normal directory authorities, except they
-  don't create their own network-status documents or votes. So if you
-  ask an authority for a network-status document or consensus, they
-  behave like a directory mirror: they give you one from one of the main
-  authorities. But if you ask the bridge authority for the descriptor
-  corresponding to a particular identity fingerprint, it will happily
-  give you the latest descriptor for that fingerprint.
-
-  To become a bridge authority, add these lines to your torrc:
-    AuthoritativeDirectory 1
-    BridgeAuthoritativeDir 1
-
-  Right now there's one bridge authority, running on the Tonga relay.
-
-2.1. Exporting bridge-purpose descriptors
-
-  We've added a new purpose for server descriptors: the "bridge"
-  purpose. With the new router-descriptors file format that includes
-  annotations, it's easy to look through it and find the bridge-purpose
-  descriptors.
-
-  Currently we export the bridge descriptors from Tonga to the
-  BridgeDB server, so it can give them out according to the policies
-  in blocking.pdf.
-
-2.2. Reachability/uptime testing
-
-  Right now the bridge authorities do active reachability testing of
-  bridges, so we know which ones to recommend for users.
-
-  But in the design document, we suggested that bridges should publish
-  anonymously (i.e. via Tor) to the bridge authority, so somebody watching
-  the bridge authority can't just enumerate all the bridges. But if we're
-  doing active measurement, the game is up. Perhaps we should back off on
-  this goal, or perhaps we should do our active measurement anonymously?
-
-  Answering this issue is scheduled for 0.2.1.x.
-
-2.3. Migrating to multiple bridge authorities
-
-  Having only one bridge authority is both a trust bottleneck (if you
-  break into one place you learn about every single bridge we've got)
-  and a robustness bottleneck (when it's down, bridge users become sad).
-
-  Right now if we put up a second bridge authority, all the bridges would
-  publish to it, and (assuming the code works) bridge users would query
-  a random bridge authority. This resolves the robustness bottleneck,
-  but makes the trust bottleneck even worse.
-
-  In 0.2.2.x and later we should think about better ways to have multiple
-  bridge authorities.
-
-3. Bridge users.
-
-  Bridge users are like ordinary Tor users except they use encrypted
-  directory connections by default, and they use bridge relays as both
-  entry guards (their first hop) and directory guards (the source of
-  all their directory information).
-
-  To become a bridge user, add the following line to your torrc:
-
-    UseBridges 1
-
-  and then add at least one "Bridge" line to your torrc based on the
-  format below.
-
-3.1. Format of the bridge identifier.
-
-  The canonical format for a bridge identifier contains an IP address,
-  an ORPort, and an identity fingerprint:
-    bridge 128.31.0.34:9009 4C17 FB53 2E20 B2A8 AC19 9441 ECD2 B017 7B39 E4B1
-
-  However, the identity fingerprint can be left out, in which case the
-  bridge user will connect to that relay and use it as a bridge regardless
-  of what identity key it presents:
-    bridge 128.31.0.34:9009
-  This might be useful for cases where only short bridge identifiers
-  can be communicated to bridge users.
-
-  In a future version we may also support bridge identifiers that are
-  only a key fingerprint:
-    bridge 4C17 FB53 2E20 B2A8 AC19 9441 ECD2 B017 7B39 E4B1
-  and the bridge user can fetch the latest descriptor from the bridge
-  authority (see Section 3.4).
-
-3.2. Bridges as entry guards
-
-  For now, bridge users add their bridge relays to their list of "entry
-  guards" (see path-spec.txt for background on entry guards). They are
-  managed by the entry guard algorithms exactly as if they were a normal
-  entry guard -- their keys and timing get cached in the "state" file,
-  etc. This means that when the Tor user starts up with "UseBridges"
-  disabled, he will skip past the bridge entries since they won't be
-  listed as up and usable in his networkstatus consensus. But to be clear,
-  the "entry_guards" list doesn't currently distinguish guards by purpose.
-
-  Internally, each bridge user keeps a smartlist of "bridge_info_t"
-  that reflects the "bridge" lines from his torrc along with a download
-  schedule (see Section 3.5 below). When he starts Tor, he attempts
-  to fetch a descriptor for each configured bridge (see Section 3.4
-  below). When he succeeds at getting a descriptor for one of the bridges
-  in his list, he adds it directly to the entry guard list using the
-  normal add_an_entry_guard() interface. Once a bridge descriptor has
-  been added, should_delay_dir_fetches() will stop delaying further
-  directory fetches, and the user begins to bootstrap his directory
-  information from that bridge (see Section 3.3).
-
-  Currently bridge users cache their bridge descriptors to the
-  "cached-descriptors" file (annotated with purpose "bridge"), but
-  they don't make any attempt to reuse descriptors they find in this
-  file. The theory is that either the bridge is available now, in which
-  case you can get a fresh descriptor, or it's not, in which case an
-  old descriptor won't do you much good.
-
-  We could disable writing out the bridge lines to the state file, if
-  we think this is a problem.
-
-  As an exception, if we get an application request when we have one
-  or more bridge descriptors but we believe none of them are running,
-  we mark them all as running again. This is similar to the exception
-  already in place to help long-idle Tor clients realize they should
-  fetch fresh directory information rather than just refuse requests.
-
-3.3. Bridges as directory guards
-
-  In addition to using bridges as the first hop in their circuits, bridge
-  users also use them to fetch directory updates. Other than initial
-  bootstrapping to find a working bridge descriptor (see Section 3.4
-  below), all further non-anonymized directory fetches will be redirected
-  to the bridge.
-
-  This means that bridge relays need to have cached answers for all
-  questions the bridge user might ask. This makes the upgrade path
-  tricky --- for example, if we migrate to a v4 directory design, the
-  bridge user would need to keep using v3 so long as his bridge relays
-  only knew how to answer v3 queries.
-
-  In a future design, for cases where the user has enough information
-  to build circuits yet the chosen bridge doesn't know how to answer a
-  given query, we might teach bridge users to make an anonymized request
-  to a more suitable directory server.
-
-3.4. How bridge users get their bridge descriptor
-
-  Bridge users can fetch bridge descriptors in two ways: by going directly
-  to the bridge and asking for "/tor/server/authority", or by going to
-  the bridge authority and asking for "/tor/server/fp/ID". By default,
-  they will only try the direct queries. If the user sets
-    UpdateBridgesFromAuthority 1
-  in his config file, then he will try querying the bridge authority
-  first for bridges where he knows a digest (if he only knows an IP
-  address and ORPort, then his only option is a direct query).
-
-  If the user has at least one working bridge, then he will do further
-  queries to the bridge authority through a full three-hop Tor circuit.
-  But when bootstrapping, he will make a direct begin_dir-style connection
-  to the bridge authority.
-
-  As of Tor 0.2.0.10-alpha, if the user attempts to fetch a descriptor
-  from the bridge authority and it returns a 404 not found, the user
-  will automatically fall back to trying a direct query. Therefore it is
-  recommended that bridge users always set UpdateBridgesFromAuthority,
-  since at worst it will delay their fetches a little bit and notify
-  the bridge authority of the identity fingerprint (but not location)
-  of their intended bridges.
-
-3.5. Bridge descriptor retry schedule
-
-  Bridge users try to fetch a descriptor for each bridge (using the
-  steps in Section 3.4 above) on startup. Whenever they receive a
-  bridge descriptor, they reschedule a new descriptor download for 1
-  hour from then.
-
-  If on the other hand it fails, they try again after 15 minutes for the
-  first attempt, after 15 minutes for the second attempt, and after 60
-  minutes for subsequent attempts.
-
-  In 0.2.2.x we should come up with some smarter retry schedules.
-
-3.6. Vidalia integration
-
-  Vidalia 0.0.16 has a checkbox in its Network config window called
-  "My ISP blocks connections to the Tor network." Users who click that
-  box change their configuration to:
-    UseBridges 1
-    UpdateBridgesFromAuthority 1
-  and should specify at least one Bridge identifier.
-
-3.7. Do we need a second layer of entry guards?
-
-  If the bridge user uses the bridge as its entry guard, then the
-  triangulation attacks from Lasse and Paul's Oakland paper work to
-  locate the user's bridge(s).
-
-  Worse, this is another way to enumerate bridges: if the bridge users
-  keep rotating through second hops, then if you run a few fast servers
-  (and avoid getting considered an Exit or a Guard) you'll quickly get
-  a list of the bridges in active use.
-
-  That's probably the strongest reason why bridge users will need to
-  pick second-layer guards. Would this mean bridge users should switch
-  to four-hop circuits?
-
-  We should figure this out in the 0.2.1.x timeframe.
-
diff --git a/doc/spec/proposals/126-geoip-reporting.txt b/doc/spec/proposals/126-geoip-reporting.txt
deleted file mode 100644
index d48a08b..0000000
--- a/doc/spec/proposals/126-geoip-reporting.txt
+++ /dev/null
@@ -1,412 +0,0 @@
-Filename: 126-geoip-reporting.txt
-Title: Getting GeoIP data and publishing usage summaries
-Version: $Revision$
-Last-Modified: $Date$
-Author: Roger Dingledine
-Created: 2007-11-24
-Status: Closed
-Implemented-In: 0.2.0.x
-
-0. Status
-
-  In 0.2.0.x, this proposal is implemented to the extent needed to
-  address its motivations.  See notes below with the test "RESOLUTION"
-  for details.
-
-1. Background and motivation
-
-  Right now we can keep a rough count of Tor users, both total and by
-  country, by watching connections to a single directory mirror. Being
-  able to get usage estimates is useful both for our funders (to
-  demonstrate progress) and for our own development (so we know how
-  quickly we're scaling and can design accordingly, and so we know which
-  countries and communities to focus on more). This need for information
-  is the only reason we haven't deployed "directory guards" (think of
-  them like entry guards but for directory information; in practice,
-  it would seem that Tor clients should simply use their entry guards
-  as their directory guards; see also proposal 125).
-
-  With the move toward bridges, we will no longer be able to track Tor
-  clients that use bridges, since they use their bridges as directory
-  guards. Further, we need to be able to learn which bridges stop seeing
-  use from certain countries (and are thus likely blocked), so we can
-  avoid giving them out to other users in those countries.
-
-  Right now we already do GeoIP lookups in Vidalia: Vidalia draws relays
-  and circuits on its 'network map', and it performs anonymized GeoIP
-  lookups to its central servers to know where to put the dots. Vidalia
-  caches answers it gets -- to reduce delay, to reduce overhead on
-  the network, and to reduce anonymity issues where users reveal their
-  knowledge about the network through which IP addresses they ask about.
-
-  But with the advent of bridges, Tor clients are asking about IP
-  addresses that aren't in the main directory. In particular, bridge
-  users inform the central Vidalia servers about each bridge as they
-  discover it and their Vidalia tries to map it.
-
-  Also, we wouldn't mind letting Vidalia do a GeoIP lookup on the client's
-  own IP address, so it can provide a more useful map.
-
-  Finally, Vidalia's central servers leave users open to partitioning
-  attacks, even if they can't target specific users. Further, as we
-  start using GeoIP results for more operational or security-relevant
-  goals, such as avoiding or including particular countries in circuits,
-  it becomes more important that users can't be singled out in terms of
-  their IP-to-country mapping beliefs.
-
-2. The available GeoIP databases
-
-  There are at least two classes of GeoIP database out there: "IP to
-  country", which tells us the country code for the IP address but
-  no more details, and "IP to city", which tells us the country code,
-  the name of the city, and some basic latitude/longitude guesses.
-
-  A recent ip-to-country.csv is 3421362 bytes. Compressed, it is 564252
-  bytes. A typical line is:
-    "205500992","208605279","US","USA","UNITED STATES"
-  http://ip-to-country.webhosting.info/node/view/5
-
-  Similarly, the maxmind GeoLite Country database is also about 500KB
-  compressed.
-  http://www.maxmind.com/app/geolitecountry
-
-  The maxmind GeoLite City database gives more finegrained detail like
-  geo coordinates and city name. Vidalia currently makes use of this
-  information. On the other hand it's 16MB compressed. A typical line is:
-    206.124.149.146,Bellevue,WA,US,47.6051,-122.1134
-  http://www.maxmind.com/app/geolitecity
-
-  There are other databases out there, like
-  http://www.hostip.info/faq.html
-  http://www.webconfs.com/ip-to-city.php
-  that want more attention, but for now let's assume that all the db's
-  are around this size.
-
-3. What we'd like to solve
-
-  Goal #1a: Tor relays collect IP-to-country user stats and publish
-  sanitized versions.
-  Goal #1b: Tor bridges collect IP-to-country user stats and publish
-  sanitized versions.
-
-  Goal #2a: Vidalia learns IP-to-city stats for Tor relays, for better
-  mapping.
-  Goal #2b: Vidalia learns IP-to-country stats for Tor relays, so the user
-  can pick countries for her paths.
-
-  Goal #3: Vidalia doesn't do external lookups on bridge relay addresses.
-
-  Goal #4: Vidalia resolves the Tor client's IP-to-country or IP-to-city
-  for better mapping.
-
-  Goal #5: Reduce partitioning opportunities where Vidalia central
-  servers can give different (distinguishing) responses.
-
-4. Solution overview
-
-  Our goal is to allow Tor relays, bridges, and clients to learn enough
-  GeoIP information so they can do local private queries.
-
-4.1. The IP-to-country db
-
-  Directory authorities should publish a "geoip" file that contains
-  IP-to-country mappings. Directory caches will mirror it, and Tor clients
-  and relays (including bridge relays) will fetch it. Thus we can solve
-  goals 1a and 1b (publish sanitized usage info). Controllers could also
-  use this to solve goal 2b (choosing path by country attributes). It
-  also solves goal 4 (learning the Tor client's country), though for
-  huge countries like the US we'd still need to decide where the "middle"
-  should be when we're mapping that address.
-
-  The IP-to-country details are described further in Sections 5 and
-  6 below.
-
-  [RESOLUTION: The geoip file in 0.2.0.x is not distributed through
-  Tor.  Instead, it is shipped with the bundle.]
-
-4.2. The IP-to-city db
-
-  In an ideal world, the IP-to-city db would be small enough that we
-  could distribute it in the above manner too. But for now, it is too
-  large. Here's where the design choice forks.
-
-  Option A: Vidalia should continue doing its anonymized IP-to-city
-  queries. Thus we can achieve goals 2a and 2b. We would solve goal
-  3 by only doing lookups on descriptors that are purpose "general"
-  (see Section 4.2.1 for how). We would leave goal 5 unsolved.
-
-  Option B: Each directory authority should keep an IP-to-city db,
-  lookup the value for each router it lists, and include that line in
-  the router's network-status entry. The network-status consensus would
-  then use the line that appears in the majority of votes. This approach
-  also solves goals 2a and 2b, goal 3 (Vidalia doesn't do any lookups
-  at all now), and goal 5 (reduced partitioning risks).
-
-  Option B has the advantage that Vidalia can simplify its operation,
-  and the advantage that this consensus IP-to-city data is available to
-  other controllers besides just Vidalia. But it has the disadvantage
-  that the networkstatus consensus becomes larger, even though most of
-  the GeoIP information won't change from one consensus to the next. Is
-  there another reasonable location for it that can provide similar
-  consensus security properties?
-
-  [RESOLUTION: IP-to-city is not supported.]
-
-4.2.1. Controllers can query for router annotations
-
-  Vidalia needs to stop doing queries on bridge relay IP addresses.
-  It could do that by only doing lookups on descriptors that are in
-  the networkstatus consensus, but that precludes designs like Blossom
-  that might want to map its relay locations. The best answer is that it
-  should learn the router annotations, with a new controller 'getinfo'
-  command:
-    "GETINFO desc-annotations/id/<OR identity>"
-  which would respond with something like
-    @downloaded-at 2007-11-29 08:06:38
-    @source "128.31.0.34"
-    @purpose bridge
-
-  [We could also make the answer include the digest for the router in
-  question, which would enable us to ask GETINFO router-annotations/all.
-  Is this worth it? -RD]
-
-  Then Vidalia can avoid doing lookups on descriptors with purpose
-  "bridge". Even better would be to add a new annotation "@private true"
-  so Vidalia can know how to handle new purposes that we haven't created
-  yet. Vidalia could special-case "bridge" for now, for compatibility
-  with the current 0.2.0.x-alphas.
-
-4.3. Recommendation
-
-  My overall recommendation is that we should implement 4.1 soon
-  (e.g. early in 0.2.1.x), and we can go with 4.2 option A for now,
-  with the hope that later we discover a better way to distribute the
-  IP-to-city info and can switch to 4.2 option B.
-
-  Below we discuss more how to go about achieving 4.1.
-
-5. Publishing and caching the GeoIP (IP-to-country) database
-
-  Each v3 directory authority should put a copy of the "geoip" file in
-  its datadirectory. Then its network-status votes should include a hash
-  of this file (Recommended-geoip-hash: %s), and the resulting consensus
-  directory should specify the consensus hash.
-
-  There should be a new URL for fetching this geoip db (by "current.z"
-  for testing purposes, and by hash.z for typical downloads). Authorities
-  should fetch and serve the one listed in the consensus, even when they
-  vote for their own. This would argue for storing the cached version
-  in a better filename than "geoip".
-
-  Directory mirrors should keep a copy of this file available via the
-  same URLs.
-
-  We assume that the file would change at most a few times a month. Should
-  Tor ship with a bootstrap geoip file? An out-of-date geoip file may
-  open you up to partitioning attacks, but for the most part it won't
-  be that different.
-
-  There should be a config option to disable updating the geoip file,
-  in case users want to use their own file (e.g. they have a proprietary
-  GeoIP file they prefer to use). In that case we leave it up to the
-  user to update his geoip file out-of-band.
-
-  [XXX Should consider forward/backward compatibility, e.g. if we want
-  to move to a new geoip file format. -RD]
-
-  [RESOLUTION: Not done over Tor.]
-
-6. Controllers use the IP-to-country db for mapping and for path building
-
-  Down the road, Vidalia could use the IP-to-country mappings for placing
-  on its map:
-  - The location of the client
-  - The location of the bridges, or other relays not in the
-    networkstatus, on the map.
-  - Any relays that it doesn't yet have an IP-to-city answer for.
-
-  Other controllers can also use it to set EntryNodes, ExitNodes, etc
-  in a per-country way.
-
-  To support these features, we need to export the IP-to-country data
-  via the Tor controller protocol.
-
-  Is it sufficient just to add a new GETINFO command?
-    GETINFO ip-to-country/128.31.0.34
-    250+ip-to-country/128.31.0.34="US","USA","UNITED STATES"
-
-  [RESOLUTION: Not done now, except for the getinfo command.]
-
-6.1. Other interfaces
-
-  Robert Hogan has also suggested a
-
-    GETINFO relays-by-country/cn
-
-  as well as torrc options for ExitCountryCodes, EntryCountryCodes,
-  ExcludeCountryCodes, etc.
-
-  [RESOLUTION: Not implemented in 0.2.0.x.  Fodder for a future proposal.]
-
-7. Relays and bridges use the IP-to-country db for usage summaries
-
-  Once bridges have a GeoIP database locally, they can start to publish
-  sanitized summaries of client usage -- how many users they see and from
-  what countries. This might also be a more useful way for ordinary Tor
-  relays to convey the level of usage they see, which would allow us to
-  switch to using directory guards for all users by default.
-
-  But how to safely summarize this information without opening too many
-  anonymity leaks?
-
-7.1 Attacks to think about
-
-  First, note that we need to have a large enough time window that we're
-  not aiding correlation attacks much. I hope 24 hours is enough. So
-  that means no publishing stats until you've been up at least 24 hours.
-  And you can't publish follow-up stats more often than every 24 hours,
-  or people could look at the differential.
-
-  Second, note that we need to be sufficiently vague about the IP
-  addresses we're reporting. We are hoping that just specifying the
-  country will be vague enough. But a) what about active attacks where
-  we convince a bridge to use a GeoIP db that labels each suspect IP
-  address as a unique country? We have to assume that the consensus GeoIP
-  db won't be malicious in this way. And b) could such singling-out
-  attacks occur naturally, for example because of countries that have
-  a very small IP space? We should investigate that.
-
-7.2. Granularity of users
-
-  Do we only want to report countries that have a sufficient anonymity set
-  (that is, number of users) for the day? For example, we might avoid
-  listing any countries that have seen less than five addresses over
-  the 24 hour period. This approach would be helpful in reducing the
-  singling-out opportunities -- in the extreme case, we could imagine a
-  situation where one blogger from the Sudan used Tor on a given day, and
-  we can discover which entry guard she used.
-
-  But I fear that especially for bridges, seeing only one hit from a
-  given country in a given day may be quite common.
-
-  As a compromise, we should start out with an "Other" category in
-  the reported stats, which is the sum of unlisted countries; if that
-  category is consistently interesting, we can think harder about how
-  to get the right data from it safely.
-
-  But note that bridge summaries will not be made public individually,
-  since doing so would help people enumerate bridges. Whereas summaries
-  from normal relays will be public. So perhaps that means we can afford
-  to be more specific in bridge summaries? In particular, I'm thinking the
-  "other" category should be used by public relays but not for bridges
-  (or if it is, used with a lower threshold).
-
-  Even for countries that have many Tor users, we might not want to be
-  too specific about how many users we've seen. For example, we might
-  round down the number of users we report to the nearest multiple of 5.
-  My instinct for now is that this won't be that useful.
-
-7.3 Other issues
-
-  Another note: we'll likely be overreporting in the case of users with
-  dynamic IP addresses: if they rotate to a new address over the course
-  of the day, we'll count them twice. So be it.
-
-7.4. Where to publish the summaries?
-
-  We designed extrainfo documents for information like this. So they
-  should just be more entries in the extrainfo doc.
-
-  But if we want to publish summaries every 24 hours (no more often,
-  no less often), aren't we tried to the router descriptor publishing
-  schedule? That is, if we publish a new router descriptor at the 18
-  hour mark, and nothing much has changed at the 24 hour mark, won't
-  the new descriptor get dropped as being "cosmetically similar", and
-  then nobody will know to ask about the new extrainfo document?
-
-  One solution would be to make and remember the 24 hour summary at the
-  24 hour mark, but not actually publish it anywhere until we happen to
-  publish a new descriptor for other reasons. If we happen to go down
-  before publishing a new descriptor, then so be it, at least we tried.
-
-7.5. What if the relay is unreachable or goes to sleep?
-
-  Even if you've been up for 24 hours, if you were hibernating for 18
-  of them, then we're not getting as much fuzziness as we'd like. So
-  I guess that means that we need a 24-hour period of being "awake"
-  before we'll willing to publish a summary. A similar attack works if
-  you've been awake but unreachable for the first 18 of the 24 hours. As
-  another example, a bridge that's on a laptop might be suspended for
-  some of each day.
-
-  This implies that some relays and bridges will never publish summary
-  stats, because they're not ever reliably working for 24 hours in
-  a row. If a significant percentage of our reporters end up being in
-  this boat, we should investigate whether we can accumulate 24 hours of
-  "usefulness", even if there are holes in the middle, and publish based
-  on that.
-
-  What other issues are like this? It seems that just moving to a new
-  IP address shouldn't be a reason to cancel stats publishing, assuming
-  we were usable at each address.
-
-7.6. IP addresses that aren't in the geoip db
-
-  Some IP addresses aren't in the public geoip databases. In particular,
-  I've found that a lot of African countries are missing, but there
-  are also some common ones in the US that are missing, like parts of
-  Comcast. We could just lump unknown IP addresses into the "other"
-  category, but it might be useful to gather a general sense of how many
-  lookups are failing entirely, by adding a separate "Unknown" category.
-
-  We could also contribute back to the geoip db, by letting bridges set
-  a config option to report the actual IP addresses that failed their
-  lookup. Then the bridge authority operators can manually make sure
-  the correct answer will be in later geoip files. This config option
-  should be disabled by default.
-
-7.7 Bringing it all together
-
-  So here's the plan:
-
-  24 hours after starting up (modulo Section 7.5 above), bridges and
-  relays should construct a daily summary of client countries they've
-  seen, including the above "Unknown" category (Section 7.6) as well.
-
-  Non-bridge relays lump all countries with less than K (e.g. K=5) users
-  into the "Other" category (see Sec 7.2 above), whereas bridge relays are
-  willing to list a country even when it has only one user for the day.
-
-  Whenever we have a daily summary on record, we include it in our
-  extrainfo document whenever we publish one. The daily summary we
-  remember locally gets replaced with a newer one when another 24
-  hours pass.
-
-7.8. Some forward secrecy
-
-  How should we remember addresses locally? If we convert them into
-  country-codes immediately, we will count them again if we see them
-  again. On the other hand, we don't really want to keep a list hanging
-  around of all IP addresses we've seen in the past 24 hours.
-
-  Step one is that we should never write this stuff to disk. Keeping it
-  only in ram will make things somewhat better. Step two is to avoid
-  keeping any timestamps associated with it: rather than a rolling
-  24-hour window, which would require us to remember the various times
-  we've seen that address, we can instead just throw out the whole list
-  every 24 hours and start over.
-
-  We could hash the addresses, and then compare hashes when deciding if
-  we've seen a given address before. We could even do keyed hashes. Or
-  Bloom filters. But if our goal is to defend against an adversary
-  who steals a copy of our ram while we're running and then does
-  guess-and-check on whatever blob we're keeping, we're in bad shape.
-
-  We could drop the last octet of the IP address as soon as we see
-  it. That would cause us to undercount some users from cablemodem and
-  DSL networks that have a high density of Tor users. And it wouldn't
-  really help that much -- indeed, the extent to which it does help is
-  exactly the extent to which it makes our stats less useful.
-
-  Other ideas?
-
diff --git a/doc/spec/proposals/127-dirport-mirrors-downloads.txt b/doc/spec/proposals/127-dirport-mirrors-downloads.txt
deleted file mode 100644
index 1b55a02..0000000
--- a/doc/spec/proposals/127-dirport-mirrors-downloads.txt
+++ /dev/null
@@ -1,157 +0,0 @@
-Filename: 127-dirport-mirrors-downloads.txt
-Title: Relaying dirport requests to Tor download site / website
-Version: $Revision$
-Last-Modified: $Date$
-Author: Roger Dingledine
-Created: 2007-12-02
-Status: Draft
-
-1. Overview
-
-  Some countries and networks block connections to the Tor website. As
-  time goes by, this will remain a problem and it may even become worse.
-
-  We have a big pile of mirrors (google for "Tor mirrors"), but few of
-  our users think to try a search like that. Also, many of these mirrors
-  might be automatically blocked since their pages contain words that
-  might cause them to get banned. And lastly, we can imagine a future
-  where the blockers are aware of the mirror list too.
-
-  Here we describe a new set of URLs for Tor's DirPort that will relay
-  connections from users to the official Tor download site. Rather than
-  trying to cache a bunch of new Tor packages (which is a hassle in terms
-  of keeping them up to date, and a hassle in terms of drive space used),
-  we instead just proxy the requests directly to Tor's /dist page.
-
-  Specifically, we should support
-
-    GET /tor/dist/$1
-
-  and
-
-    GET /tor/website/$1
-
-2. Direct connections, one-hop circuits, or three-hop circuits?
-
-  We could relay the connections directly to the download site -- but
-  this produces recognizable outgoing traffic on the bridge or cache's
-  network, which will probably surprise our nice volunteers. (Is this
-  a good enough reason to discard the direct connection idea?)
-
-  Even if we don't do direct connections, should we do a one-hop
-  begindir-style connection to the mirror site (make a one-hop circuit
-  to it, then send a 'begindir' cell down the circuit), or should we do
-  a normal three-hop anonymized connection?
-
-  If these mirrors are mainly bridges, doing either a direct or a one-hop
-  connection creates another way to enumerate bridges. That would argue
-  for three-hop. On the other hand, downloading a 10+ megabyte installer
-  through a normal Tor circuit can't be fun. But if you're already getting
-  throttled a lot because you're in the "relayed traffic" bucket, you're
-  going to have to accept a slow transfer anyway. So three-hop it is.
-
-  Speaking of which, we would want to label this connection
-  as "relay" traffic for the purposes of rate limiting; see
-  connection_counts_as_relayed_traffic() and or_conn->client_used. This
-  will be a bit tricky though, because these connections will use the
-  bridge's guards.
-
-3. Scanning resistance
-
-  One other goal we'd like to achieve, or at least not hinder, is making
-  it hard to scan large swaths of the Internet to look for responses
-  that indicate a bridge.
-
-  In general this is a really hard problem, so we shouldn't demand to
-  solve it here. But we can note that some bridges should open their
-  DirPort (and offer this functionality), and others shouldn't. Then
-  some bridges provide a download mirror while others can remain
-  scanning-resistant.
-
-4. Integrity checking
-
-  If we serve this stuff in plaintext from the bridge, anybody in between
-  the user and the bridge can intercept and modify it. The bridge can too.
-
-  If we do an anonymized three-hop connection, the exit node can also
-  intercept and modify the exe it sends back.
-
-  Are we setting ourselves up for rogue exit relays, or rogue bridges,
-  that trojan our users?
-
-  Answer #1: Users need to do pgp signature checking. Not a very good
-  answer, a) because it's complex, and b) because they don't know the
-  right signing keys in the first place.
-
-  Answer #2: The mirrors could exit from a specific Tor relay, using the
-  '.exit' notation. This would make connections a bit more brittle, but
-  would resolve the rogue exit relay issue. We could even round-robin
-  among several, and the list could be dynamic -- for example, all the
-  relays with an Authority flag that allow exits to the Tor website.
-
-  Answer #3: The mirrors should connect to the main distribution site
-  via SSL. That way the exit relay can't influence anything.
-
-  Answer #4: We could suggest that users only use trusted bridges for
-  fetching a copy of Tor. Hopefully they heard about the bridge from a
-  trusted source rather than from the adversary.
-
-  Answer #5: What if the adversary is trawling for Tor downloads by
-  network signature -- either by looking for known bytes in the binary,
-  or by looking for "GET /tor/dist/"? It would be nice to encrypt the
-  connection from the bridge user to the bridge. And we can! The bridge
-  already supports TLS. Rather than initiating a TLS renegotiation after
-  connecting to the ORPort, the user should actually request a URL. Then
-  the ORPort can either pass the connection off as a linked conn to the
-  dirport, or renegotiate and become a Tor connection, depending on how
-  the client behaves.
-
-5. Linked connections: at what level should we proxy?
-
-  Check out the connection_ap_make_link() function, as called from
-  directory.c. Tor clients use this to create a "fake" socks connection
-  back to themselves, and then they attach a directory request to it,
-  so they can launch directory fetches via Tor. We can piggyback on
-  this feature.
-
-  We need to decide if we're going to be passing the bytes back and
-  forth between the web browser and the main distribution site, or if
-  we're going to be actually acting like a proxy (parsing out the file
-  they want, fetching that file, and serving it back).
-
-  Advantages of proxying without looking inside:
-    - We don't need to build any sort of http support (including
-      continues, partial fetches, etc etc).
-  Disadvantages:
-    - If the browser thinks it's speaking http, are there easy ways
-      to pass the bytes to an https server and have everything work
-      correctly? At the least, it would seem that the browser would
-      complain about the cert. More generally, ssl wants to be negotiated
-      before the URL and headers are sent, yet we need to read the URL
-      and headers to know that this is a mirror request; so we have an
-      ordering problem here.
-    - Makes it harder to do caching later on, if we don't look at what
-      we're relaying. (It might be useful down the road to cache the
-      answers to popular requests, so we don't have to keep getting
-      them again.)
-
-6. Outstanding problems
-
-  1) HTTP proxies already exist.  Why waste our time cloning one
-  badly? When we clone existing stuff, we usually regret it.
-
-  2) It's overbroad.  We only seem to need a secure get-a-tor feature,
-  and instead we're contemplating building a locked-down HTTP proxy.
-
-  3) It's going to add a fair bit of complexity to our code.  We do
-  not currently implement HTTPS.  We'd need to refactor lots of the
-  low-level connection stuff so that "SSL" and "Cell-based" were no
-  longer synonymous.
-
-  4) It's still unclear how effective this proposal would be in
-  practice. You need to know that this feature exists, which means
-  somebody needs to tell you about a bridge (mirror) address and tell
-  you how to use it. And if they're doing that, they could (e.g.) tell
-  you about a gmail autoresponder address just as easily, and then you'd
-  get better authentication of the Tor program to boot.
-
diff --git a/doc/spec/proposals/128-bridge-families.txt b/doc/spec/proposals/128-bridge-families.txt
deleted file mode 100644
index e8a0050..0000000
--- a/doc/spec/proposals/128-bridge-families.txt
+++ /dev/null
@@ -1,66 +0,0 @@
-Filename: 128-bridge-families.txt
-Title: Families of private bridges
-Version: $Revision$
-Last-Modified: $Date$
-Author: Roger Dingledine
-Created: 2007-12-xx
-Status: Dead
-
-1. Overview
-
-  Proposal 125 introduced the basic notion of how bridge authorities,
-  bridge relays, and bridge users should behave. But it doesn't get into
-  the various mechanisms of how to distribute bridge relay addresses to
-  bridge users.
-
-  One of the mechanisms we have in mind is called 'families of bridges'.
-  If a bridge user knows about only one private bridge, and that bridge
-  shuts off for the night or gets a new dynamic IP address, the bridge
-  user is out of luck and needs to re-bootstrap manually or wait and
-  hope it comes back. On the other hand, if the bridge user knows about
-  a family of bridges, then as long as one of those bridges is still
-  reachable his Tor client can automatically  learn about where the
-  other bridges have gone.
-
-  So in this design, a single volunteer could run multiple coordinated
-  bridges, or a group of volunteers could each run a bridge. We abstract
-  out the details of how these volunteers find each other and decide to
-  set up a family.
-
-2. Other notes.
-
-  somebody needs to run a bridge authority
-
-  it needs to have a torrc option to publish networkstatuses of its bridges
-
-  it should also do reachability testing just of those bridges
-
-  people ask for the bridge networkstatus by asking for a url that
-  contains a password. (it's safe to do this because of begin_dir.)
-
-  so the bridge users need to know a) a password, and b) a bridge
-  authority line.
-
-  the bridge users need to know the bridge authority line.
-
-  the bridge authority needs to know the password.
-
-3. Current state
-
-  I implemented a BridgePassword config option. Bridge authorities
-  should set it, and users who want to use those bridge authorities
-  should set it.
-
-  Now there is a new directory URL "/tor/networkstatus-bridges" that
-  directory mirrors serve if BridgeAuthoritativeDir is set and it's a
-  begin_dir connection. It looks for the header
-    Authorization: Basic %s
-  where %s is the base-64 bridge password.
-
-  I never got around to teaching clients how to set the header though,
-  so it may or may not, and may or may not do what we ultimate want.
-
-  I've marked this proposal dead; it really never should have left the
-  ideas/ directory. Somebody should pick it up sometime and finish the
-  design and implementation.
-
diff --git a/doc/spec/proposals/129-reject-plaintext-ports.txt b/doc/spec/proposals/129-reject-plaintext-ports.txt
deleted file mode 100644
index d4767d0..0000000
--- a/doc/spec/proposals/129-reject-plaintext-ports.txt
+++ /dev/null
@@ -1,116 +0,0 @@
-Filename: 129-reject-plaintext-ports.txt
-Title: Block Insecure Protocols by Default
-Version: $Revision$
-Last-Modified: $Date$
-Author: Kevin Bauer & Damon McCoy
-Created: 2008-01-15
-Status: Closed
-Implemented-In: 0.2.0.x
-
-Overview:
-
-  Below is a proposal to mitigate insecure protocol use over Tor.
-
-  This document 1) demonstrates the extent to which insecure protocols are
-  currently used within the Tor network, and 2) proposes a simple solution
-  to prevent users from unknowingly using these insecure protocols. By
-  insecure, we consider protocols that explicitly leak sensitive user names
-  and/or passwords, such as POP, IMAP, Telnet, and FTP.
-
-Motivation:
-
-  As part of a general study of Tor use in 2006/2007 [1], we attempted to
-  understand what types of protocols are used over Tor. While we observed a
-  enormous volume of Web and Peer-to-peer traffic, we were surprised by the
-  number of insecure protocols that were used over Tor. For example, over an
-  8 day observation period, we observed the following number of connections
-  over insecure protocols:
-
-    POP and IMAP:10,326 connections
-    Telnet: 8,401 connections
-    FTP: 3,788 connections
-
-  Each of the above listed protocols exchange user name and password
-  information in plain-text. As an upper bound, we could have observed
-  22,515 user names and passwords. This observation echos the reports of
-  a Tor router logging and posting e-mail passwords in August 2007 [2]. The
-  response from the Tor community has been to further educate users
-  about the dangers of using insecure protocols over Tor. However, we
-  recently repeated our Tor usage study from last year and noticed that the
-  trend in insecure protocol use has not declined. Therefore, we propose that
-  additional steps be taken to protect naive Tor users from inadvertently
-  exposing their identities (and even passwords) over Tor.
-
-Security Implications:
-
-  This proposal is intended to improve Tor's security by limiting the
-  use of insecure protocols.
-
-  Roger added: By adding these warnings for only some of the risky
-  behavior, users may do other risky behavior, not get a warning, and
-  believe that it is therefore safe. But overall, I think it's better
-  to warn for some of it than to warn for none of it.
-
-Specification:
-
-  As an initial step towards mitigating the use of the above-mentioned
-  insecure protocols, we propose that the default ports for each respective
-  insecure service be blocked at the Tor client's socks proxy. These default
-  ports include:
-
-    23 - Telnet
-    109 - POP2
-    110 - POP3
-    143 - IMAP
-
-  Notice that FTP is not included in the proposed list of ports to block. This
-  is because FTP is often used anonymously, i.e., without any identifying
-  user name or password.
-
-  This blocking scheme can be implemented as a set of flags in the client's
-  torrc configuration file:
-
-    BlockInsecureProtocols 0|1
-    WarnInsecureProtocols 0|1
-
-  When the warning flag is activated, a message should be displayed to
-  the user similar to the message given when Tor's socks proxy is given an IP
-  address rather than resolving a host name.
-
-  We recommend that the default torrc configuration file block insecure
-  protocols and provide a warning to the user to explain the behavior.
-
-  Finally, there are many popular web pages that do not offer secure
-  login features, such as MySpace, and it would be prudent to provide
-  additional rules to Privoxy to attempt to protect users from unknowingly
-  submitting their login credentials in plain-text.
-
-Compatibility:
-
-  None, as the proposed changes are to be implemented in the client.
-
-References:
-
-  [1] Shining Light in Dark Places: A Study of Anonymous Network Usage.
-      University of Colorado Technical Report CU-CS-1032-07. August 2007.
-
-  [2] Rogue Nodes Turn Tor Anonymizer Into Eavesdropper's Paradise.
-      http://www.wired.com/politics/security/news/2007/09/embassy_hacks.
-      Wired. September 10, 2007.
-
-Implementation:
-
-  Roger added this feature in
-  http://archives.seul.org/or/cvs/Jan-2008/msg00182.html
-  He also added a status event for Vidalia to recognize attempts to use
-  vulnerable-plaintext ports, so it can help the user understand what's
-  going on and how to fix it.
-
-Next steps:
-
-  a) Vidalia should learn to recognize this controller status event,
-  so we don't leave users out in the cold when we enable this feature.
-
-  b) We should decide which ports to reject by default. The current
-  consensus is 23,109,110,143 -- the same set that we warn for now.
-
diff --git a/doc/spec/proposals/130-v2-conn-protocol.txt b/doc/spec/proposals/130-v2-conn-protocol.txt
deleted file mode 100644
index 16f5bf2..0000000
--- a/doc/spec/proposals/130-v2-conn-protocol.txt
+++ /dev/null
@@ -1,186 +0,0 @@
-Filename: 130-v2-conn-protocol.txt
-Title: Version 2 Tor connection protocol
-Version: $Revision$
-Last-Modified: $Date$
-Author: Nick Mathewson
-Created: 2007-10-25
-Status: Closed
-Implemented-In: 0.2.0.x
-
-Overview:
-
-  This proposal describes the significant changes to be made in the v2
-  Tor connection protocol.
-
-  This proposal relates to other proposals as follows:
-
-    It refers to and supersedes:
-       Proposal 124: Blocking resistant TLS certificate usage
-    It refers to aspects of:
-       Proposal 105: Version negotiation for the Tor protocol
-
-
-  In summary, The Tor connection protocol has been in need of a redesign
-  for a while.  This proposal describes how we can add to the Tor
-  protocol:
-
-     - A new TLS handshake (to achieve blocking resistance without
-       breaking backward compatibility)
-     - Version negotiation (so that future connection protocol changes
-       can happen without breaking compatibility)
-     - The actual changes in the v2 Tor connection protocol.
-
-Motivation:
-
-  For motivation, see proposal 124.
-
-Proposal:
-
-0. Terminology
-
-  The version of the Tor connection protocol implemented up to now is
-  "version 1".  This proposal describes "version 2".
-
-  "Old" or "Older" versions of Tor are ones not aware that version 2
-  of this protocol exists;
-  "New" or "Newer" versions are ones that are.
-
-  The connection initiator is referred to below as the Client; the
-  connection responder is referred to below as the Server.
-
-1. The revised TLS handshake.
-
-  For motivation, see proposal 124.  This is a simplified version of the
-  handshake that uses TLS's renegotiation capability in order to avoid
-  some of the extraneous steps in proposal 124.
-
-  The Client connects to the Server and, as in ordinary TLS, sends a
-  list of ciphers.  Older versions of Tor will send only ciphers from
-  the list:
-    TLS_DHE_RSA_WITH_AES_256_CBC_SHA
-    TLS_DHE_RSA_WITH_AES_128_CBC_SHA
-    SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
-    SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
-  Clients that support the revised handshake will send the recommended
-  list of ciphers from proposal 124, in order to emulate the behavior of
-  a web browser.
-
-  If the server notices that the list of ciphers contains only ciphers
-  from this list, it proceeds with Tor's version 1 TLS handshake as
-  documented in tor-spec.txt.
-
-  (The server may also notice cipher lists used by other implementations
-  of the Tor protocol (in particular, the BouncyCastle default cipher
-  list as used by some Java-based implementations), and whitelist them.)
-
-  On the other hand, if the server sees a list of ciphers that could not
-  have been sent from an older implementation (because it includes other
-  ciphers, and does not match any known-old list), the server sends a
-  reply containing a single connection certificate, constructed as for
-  the link certificate in the v1 Tor protocol.  The subject names in
-  this certificate SHOULD NOT have any strings to identify them as
-  coming from a Tor server.  The server does not ask the client for
-  certificates.
-
-  Old Servers will (mostly) ignore the cipher list and respond as in the v1
-  protocol, sending back a two-certificate chain.
-
-  After the Client gets a response from the server, it checks for the
-  number of certificates it received.  If there are two certificates,
-  the client assumes a V1 connection and proceeds as in tor-spec.txt.
-  But if there is only one certificate, the client assumes a V2 or later
-  protocol and continues.
-
-  At this point, the client has established a TLS connection with the
-  server, but the parties have not been authenticated: the server hasn't
-  sent its identity certificate, and the client hasn't sent any
-  certificates at all.  To fix this, the client begins a TLS session
-  renegotiation.  This time, the server continues with two certificates
-  as usual, and asks for certificates so that the client will send
-  certificates of its own.  Because the TLS connection has been
-  established, all of this is encrypted.  (The certificate sent by the
-  server in the renegotiated connection need not be the same that
-  as sentin the original connection.)
-
-  The server MUST NOT write any data until the client has renegotiated.
-
-  Once the renegotiation is finished, the server and client check one
-  another's certificates as in V1.  Now they are mutually authenticated.
-
-1.1. Revised TLS handshake: implementation notes.
-
-  It isn't so easy to adjust server behavior based on the client's
-  ciphersuite list.  Here's how we can do it using OpenSSL.  This is a
-  bit of an abuse of the OpenSSL APIs, but it's the best we can do, and
-  we won't have to do it forever.
-
-  We can use OpenSSL's SSL_set_info_callback() to register a function to
-  be called when the state changes.  The type/state tuple of
-     SSL_CB_ACCEPT_LOOP/SSL3_ST_SW_SRVR_HELLO_A
-  happens when we have completely parsed the client hello, and are about
-  to send a response.  From this callback, we can check the cipherlist
-  and act accordingly:
-
-     * If the ciphersuite list indicates a v1 protocol, we set the
-       verify mode to SSL_VERIFY_NONE with a callback (so we get
-       certificates).
-
-     * If the ciphersuite list indicates a v2 protocol, we set the
-       verify mode to SSL_VERIFY_NONE with no callback (so we get
-       no certificates) and set the SSL_MODE_NO_AUTO_CHAIN flag (so that
-       we send only 1 certificate in the response.
-
-  Once the handshake is done, the server clears the
-  SSL_MODE_NO_AUTO_CHAIN flag and sets the callback as for the V1
-  protocol.  It then starts reading.
-
-  The other problem to take care of is missing ciphers and OpenSSL's
-  cipher sorting algorithms. The two main issues are a) OpenSSL doesn't
-  support some of the default ciphers that Firefox advertises, and b)
-  OpenSSL sorts the list of ciphers it offers in a different way than
-  Firefox sorts them, so unless we fix that Tor will still look different
-  than Firefox.
-  [XXXX more on this.]
-
-
-1.2. Compatibility for clients using libraries less hackable than OpenSSL.
-
-  As discussed in proposal 105, servers advertise which protocol
-  versions they support in their router descriptors.  Clients can simply
-  behave as v1 clients when connecting to servers that do not support
-  link version 2 or higher, and as v2 clients when connecting to servers
-  that do support link version 2 or higher.
-
-  (Servers can't use this strategy because we do not assume that servers
-  know one another's capabilities when connecting.)
-
-2. Version negotiation.
-
-  Version negotiation proceeds as described in proposal 105, except as
-  follows:
-
-   * Version negotiation only happens if the TLS handshake as described
-     above completes.
-
-   * The TLS renegotiation must be finished before the client sends a
-     VERSIONS cell; the server sends its VERSIONS cell in response.
-
-   * The VERSIONS cell uses the following variable-width format:
-         Circuit  [2 octets; set to 0]
-         Command  [1 octet; set to 7 for VERSIONS]
-         Length   [2 octets; big-endian]
-         Data     [Length bytes]
-
-     The Data in the cell is a series of big-endian two-byte integers.
-
-   * It is not allowed to negotiate V1 conections once the v2 protocol
-     has been used.  If this happens, Tor instances should close the
-     connection.
-
-3. The rest of the "v2" protocol
-
-   Once a v2 protocol has been negotiated, NETINFO cells are exchanged
-   as in proposal 105, and communications begin as per tor-spec.txt.
-   Until NETINFO cells have been exchanged, the connection is not open.
-
-
diff --git a/doc/spec/proposals/131-verify-tor-usage.txt b/doc/spec/proposals/131-verify-tor-usage.txt
deleted file mode 100644
index 2687139..0000000
--- a/doc/spec/proposals/131-verify-tor-usage.txt
+++ /dev/null
@@ -1,150 +0,0 @@
-Filename: 131-verify-tor-usage.txt
-Title: Help users to verify they are using Tor
-Version: $Revision$
-Last-Modified: $Date$
-Author: Steven J. Murdoch
-Created: 2008-01-25
-Status: Needs-Revision
-
-Overview:
-
-  Websites for checking whether a user is accessing them via Tor are a
-  very helpful aid to configuring web browsers correctly. Existing
-  solutions have both false positives and false negatives when
-  checking if Tor is being used. This proposal will discuss how to
-  modify Tor so as to make testing more reliable.
-
-Motivation:
-
-  Currently deployed websites for detecting Tor use work by comparing
-  the client IP address for a request with a list of known Tor nodes.
-  This approach is generally effective, but suffers from both false
-  positives and false negatives. 
-
-  If a user has a Tor exit node installed, or just happens to have
-  been allocated an IP address previously used by a Tor exit node, any
-  web requests will be incorrectly flagged as coming from Tor. If any
-  customer of an ISP which implements a transparent proxy runs an exit
-  node, all other users of the ISP will be flagged as Tor users.
-
-  Conversely, if the exit node chosen by a Tor user has not yet been
-  recorded by the Tor checking website, requests will be incorrectly
-  flagged as not coming via Tor.
-  
-  The only reliable way to tell whether Tor is being used or not is for
-  the Tor client to flag this to the browser.
-
-Proposal:
-
-  A DNS name should be registered and point to an IP address 
-  controlled by the Tor project and likely to remain so for the
-  useful lifetime of a Tor client. A web server should be placed
-  at this IP address.
-  
-  Tor should be modified to treat requests to port 80, at the
-  specified DNS name or IP address specially. Instead of opening a
-  circuit, it should respond to a HTTP request with a helpful web
-  page:
-
-  - If the request to open a connection was to the domain name, the web
-    page should state that Tor is working properly.
-  - If the request was to the IP address, the web page should state
-    that there is a DNS-leakage vulnerability.
-
-  If the request goes through to the real web server, the page
-  should state that Tor has not been set up properly.
-
-Extensions:
-
-  Identifying proxy server:
-
-  If needed, other applications between the web browser and Tor (e.g.
-  Polipo and Privoxy) could piggyback on the same mechanism to flag
-  whether they are in use. All three possible web pages should include
-  a machine-readable placeholder, into which another program could
-  insert their own message.
-
-  For example, the webpage returned by Tor to indicate a successful
-  configuration could include the following HTML:
-   <h2>Connection chain</h2>
-   <ul>
-   <li>Tor 0.1.2.14-alpha</li>
-   <!-- Tor Connectivity Check: success -->
-   </ul>
-
-  When the proxy server observes this string, in response to a request
-  for the Tor connectivity check web page, it would prepend it's own
-  message, resulting in the following being returned to the web
-  browser:
-   <h2>Connection chain
-   <ul>
-   <li>Tor 0.1.2.14-alpha</li>
-   <li>Polipo version 1.0.4</li>
-   <!-- Tor Connectivity Check: success -->
-   </ul>
-
-  Checking external connectivity:
-
-  If Tor intercepts a request, and returns a response itself, the user
-  will not actually confirm whether Tor is able to build a successful
-  circuit. It may then be advantageous to include an image in the web
-  page which is loaded from a different domain. If this is able to be
-  loaded then the user will know that external connectivity through
-  Tor works.
-
-  Automatic Firefox Notification:
-
-  All forms of the website should return valid XHTML and have a
-  hidden link with an id attribute "TorCheckResult" and a target
-  property that can be queried to determine the result. For example,   
-  a hidden link would convey success like this: 
-
-  <a id="TorCheckResult" target="success" href="/"></a>
-
-  failure like this:
-
-  <a id="TorCheckResult" target="failure" href="/"></a>
-
-  and DNS leaks like this:
-
-  <a id="TorCheckResult" target="dnsleak" href="/"></a>
-
-  Firefox extensions such as Torbutton would then be able to 
-  issue an XMLHttpRequest for the page and query the result
-  with resultXML.getElementById("TorCheckResult").target
-  to automatically report the Tor status to the user when
-  they first attempt to enable Tor activity, or whenever
-  they request a check from the extension preferences window.
-
-  If the check website is to be themed with heavy graphics and/or
-  extensive documentation, the check result itself should be
-  contained in a seperate lightweight iframe that extensions can
-  request via an alternate url.
-
-Security and resiliency implications:
-
-  What attacks are possible?
-
-  If the IP address used for this feature moves there will be two
-  consequences:
-   - A new website at this IP address will remain inaccessible over
-     Tor
-   - Tor users who are leaking DNS will be informed that Tor is not
-     working, rather than that it is active but leaking DNS
-  We should thus attempt to find an IP address which we reasonably
-  believe can remain static.
-
-Open issues:
-
-  If a Tor version which does not support this extra feature is used,
-  the webpage returned will indicate that Tor is not being used. Can
-  this be safely fixed?
-
-Related work:
-
-  The proposed mechanism is very similar to config.privoxy.org. The
-  most significant difference is that if the web browser is
-  misconfigured, Tor will only get an IP address. Even in this case,
-  Tor should be able to respond with a webpage to notify the user of how
-  to fix the problem. This also implies that Tor must be told of the
-  special IP address, and so must be effectively permanent.
diff --git a/doc/spec/proposals/132-browser-check-tor-service.txt b/doc/spec/proposals/132-browser-check-tor-service.txt
deleted file mode 100644
index d07a10d..0000000
--- a/doc/spec/proposals/132-browser-check-tor-service.txt
+++ /dev/null
@@ -1,147 +0,0 @@
-Filename: 132-browser-check-tor-service.txt
-Title: A Tor Web Service For Verifying Correct Browser Configuration
-Version: $Revision$
-Last-Modified: $Date$
-Author: Robert Hogan
-Created: 2008-03-08
-Status: Draft
-
-Overview:
-
-  Tor should operate a primitive web service on the loopback network device
-  that tests the operation of user's browser, privacy proxy and Tor client.
-  The tests are performed by serving unique, randomly generated elements in
-  image URLs embedded in static HTML. The images are only displayed if the DNS
-  and HTTP requests for them are routed through Tor, otherwise the 'alt' text
-  may be displayed. The proposal assumes that 'alt' text is not displayed on
-  all browsers so suggests that text and links should accompany each image
-  advising the user on next steps in case the test fails.
-
-  The service is primarily for the use of controllers, since presumably users
-  aren't going to want to edit text files and then type something exotic like
-  127.0.0.1:9999 into their address bar. In the main use case the controller
-  will have configured the actual port for the webservice so will know where
-  to direct the request. It would also be the responsibility of the controller
-  to ensure the webservice is available, and tor is running, before allowing
-  the user to access the page through their browser.
-
-Motivation:
-
-  This is a complementary approach to proposal 131. It overcomes some of the
-  limitations of the approach described in proposal 131: reliance
-  on a permanent, real IP address and compatibility with older versions of
-  Tor. Unlike 131, it is not as useful to Tor users who are not running a
-  controller.
-
-Objective:
-
-  Provide a reliable means of helping users to determine if their Tor
-  installation, privacy proxy and browser are properly configured for
-  anonymous browsing.
-
-Proposal:
-
-  When configured to do so, Tor should run a basic web service available
-  on a configured port on 127.0.0.1. The purpose of this web service is to
-  serve a number of basic test images that will allow the user to determine
-  if their browser is properly configured and that Tor is working normally.
-
-  The service can consist of a single web page with two columns. The left
-  column contains images, the right column contains advice on what the
-  display/non-display of the column means.
-
-  The rest of this proposal assumes that the service is running on port
-  9999. The port should be configurable, and configuring the port enables the
-  service. The service must run on 127.0.0.1.
-
-  In all the examples below [uniquesessionid] refers to a random, base64
-  encoded string that is unique to the URL it is contained in. Tor only ever
-  stores the most recently generated [uniquesessionid] for each URL, storing 3
-  in total. Tor should generate a [uniquesessionid] for each of the test URLs
-  below every time a HTTP GET is received at 127.0.0.1:9999 for index.htm.
-
-  The most suitable image for each test case is an implementation decision.
-  Tor will need to store and serve images for the first and second test
-  images, and possibly the third (see 'Open Issues').
-
-  1. DNS Request Test Image
-  
-  This is a HTML element embedded in the page served by Tor at
-  http://127.0.0.1:9999:
-
-  <IMG src="http://[uniquesessionid]:9999/torlogo.jpg"; alt="If you can see
-  this text, your browser's DNS requests are not being routed through Tor."
-  width="200" height="200" align="middle" border="2">
-
-  If the browser's DNS request for [uniquesessionid] is routed through Tor,
-  Tor will intercept the request and return 127.0.0.1 as the resolved IP
-  address. This will shortly be followed by a HTTP request from the browser
-  for http://127.0.0.1:9999/torlogo.jpg. This request should be served with
-  the appropriate image.
-
-  If the browser's DNS request for [uniquesessionid] is not routed through Tor
-  the browser may display the 'alt' text specified in the html element. The
-  HTML served by Tor should also contain text accompanying the image to advise
-  users what it means if they do not see an image. It should also provide a
-  link to click that provides information on how to remedy the problem. This
-  behaviour also applies to the images described in 2. and 3. below, so should
-  be assumed there as well.
-
-
-  2. Proxy Configuration Test Image
-
-  This is a HTML element embedded in the page served by Tor at
-  http://127.0.0.1:9999:
-
-  <IMG src="http://torproject.org/[uniquesessionid].jpg"; alt="If you can see
-  this text, your browser is not configured to work with Tor." width="200"
-  height="200" align="middle" border="2">
-
-  If the HTTP request for the resource [uniquesessionid].jpg is received by
-  Tor it will serve the appropriate image in response. It should serve this
-  image itself, without attempting to retrieve anything from the Internet.
-
-  If Tor can identify the name of the proxy application requesting the
-  resource then it could store and serve an image identifying the proxy to the
-  user.
-
-  3. Tor Connectivity Test Image
-
-  This is a HTML element embedded in the page served by Tor at
-  http://127.0.0.1:9999:
-
-  <IMG src="http://torproject.org/[uniquesessionid]-torlogo.jpg"; alt="If you
-  can see this text, your Tor installation cannot connect to the Internet."
-  width="200" height="200" align="middle" border="2">
-
-  The referenced image should actually exist on the Tor project website. If
-  Tor receives the request for the above resource it should remove the random
-  base64 encoded digest from the request (i.e. [uniquesessionid]-) and attempt
-  to retrieve the real image.
-
-  Even on a fully operational Tor client this test may not always succeed. The
-  user should be advised that one or more attempts to retrieve this image may
-  be necessary to confirm a genuine problem.
-
-Open Issues:
-
-  The final connectivity test relies on an externally maintained resource, if
-  this resource becomes unavailable the connectivity test will always fail.
-  Either the text accompanying the test should advise of this possibility or
-  Tor clients should be advised of the location of the test resource in the
-  main network directory listings.
-
-  Any number of misconfigurations may make the web service unreachable, it is
-  the responsibility of the user's controller to recognize these and assist
-  the user in eliminating them. Tor can mitigate against the specific
-  misconfiguration of routing HTTP traffic to 127.0.0.1 to Tor itself by
-  serving such requests through the SOCKS port as well as the configured web
-  service report.
-
-  Now Tor is inspecting the URLs requested on its SOCKS port and 'dropping'
-  them. It already inspects for raw IP addresses (to warn of DNS leaks) but
-  maybe the behaviour proposed here is qualitatively different. Maybe this is
-  an unwelcome precedent that can be used to beat the project over the head in
-  future. Or maybe it's not such a bad thing, Tor is merely attempting to make
-  normally invalid resource requests valid for a given purpose.
-
diff --git a/doc/spec/proposals/133-unreachable-ors.txt b/doc/spec/proposals/133-unreachable-ors.txt
deleted file mode 100644
index a1c2dd8..0000000
--- a/doc/spec/proposals/133-unreachable-ors.txt
+++ /dev/null
@@ -1,128 +0,0 @@
-Filename: 133-unreachable-ors.txt
-Title: Incorporate Unreachable ORs into the Tor Network
-Author: Robert Hogan
-Created: 2008-03-08
-Status: Draft
-
-Overview:
-
-  Propose a scheme for harnessing the bandwidth of ORs who cannot currently
-  participate in the Tor network because they can only make outbound
-  TCP connections.
-
-Motivation: 
-
-  Restrictive local and remote firewalls are preventing many willing
-  candidates from becoming ORs on the Tor network.These
-  ORs have a casual interest in joining the network but their operator is not
-  sufficiently motivated or adept to complete the necessary router or firewall
-  configuration. The Tor network is losing out on their bandwidth. At the
-  moment we don't even know how many such 'candidate' ORs there are.
-
-
-Objective:
-
-  1. Establish how many ORs are unable to qualify for publication because
-     they cannot establish that their ORPort is reachable.
-
-  2. Devise a method for making such ORs available to clients for circuit
-     building without prejudicing their anonymity.
-
-Proposal:
-
-  ORs whose ORPort reachability testing fails a specified number of
-  consecutive times should:
-  1. Enlist themselves with the authorities setting a 'Fallback' flag. This
-      flag indicates that the OR is up and running but cannot connect to
-      itself.
-  2. Open an orconn with all ORs whose fingerprint begins with the same
-      byte as their own. The management of this orconn will be transferred
-      entirely to the OR at the other end.
-  2. The fallback OR should update it's router status to contain the
-      'Running' flag if it has managed to open an orconn with 3/4 of the ORs
-      with an FP beginning with the same byte as its own.
-
-  Tor ORs who are contacted by fallback ORs requesting an orconn should:
-   1. Accept the orconn until they have reached a defined limit of orconn
-      connections with fallback ORs.
-   2. Should only accept such orconn requests from listed fallback ORs who
-      have an FP beginning with the same byte as its own.
-
-  Tor clients can include fallback ORs in the network by doing the
-  following:
-   1. When building a circuit, observe the fingerprint of each node they
-      wish to connect to.
-   2. When randomly selecting a node from the set of all eligible nodes,
-      add all published, running fallback nodes to the set where the first
-      byte of the fingerprint matches the previous node in the circuit.
-
-Anonymity Implications:
-
-  At least some, and possibly all, nodes on the network will have a set
-  of nodes that only they and a few others can build circuits on.
-
-    1. This means that fallback ORs might be unsuitable for use as middlemen
-       nodes, because if the exit node is the attacker it knows that the
-       number of nodes that could be the entry guard in the circuit is
-       reduced to roughly 1/256th of the network, or worse 1/256th of all
-       nodes listed as Guards. For the same reason, fallback nodes would
-       appear to be unsuitable for two-hop circuits.
-
-    2. This is not a problem if fallback ORs are always exit nodes. If
-       the fallback OR is an attacker it will not be able to reduce the
-       set of possible nodes for the entry guard any further than a normal,
-       published OR.
-
-Possible Attacks/Open Issues:
-
-  1. Gaming Node Selection
-    Does running a fallback OR customized for a specific set of published ORs
-    improve an attacker's chances of seeing traffic from that set of published
-    ORs? Would such a strategy be any more effective than running published
-    ORs with other 'attractive' properties?
-
-  2. DOS Attack
-    An attacker could prevent all other legitimate fallback ORs with a
-    given byte-1 in their FP from functioning by running 20 or 30 fallback ORs
-    and monopolizing all available fallback slots on the published ORs. 
-    This same attacker would then be in a position to monopolize all the
-    traffic of the fallback ORs on that byte-1 network segment. I'm not sure
-    what this would allow such an attacker to do.
-
-  4. Circuit-Sniffing
-    An observer watching exit traffic from a fallback server will know that the
-    previous node in the circuit is one of a  very small, identifiable
-    subset of the total ORs in the network. To establish the full path of the
-    circuit they would only have to watch the exit traffic from the fallback
-    OR and all the traffic from the 20 or 30 ORs it is likely to be connected
-    to. This means it is substantially easier to establish all members of a
-    circuit which has a fallback OR as an exit (sniff and analyse 10-50 (i.e.
-    1/256 varying) + 1 ORs) rather than a normal published OR (sniff all 2560
-    or so ORs on the network). The same mechanism that allows the client to
-    expect a specific fallback OR to be available from a specific published OR
-    allows an attacker to prepare his ground.
-
-    Mitigant:
-    In terms of the resources and access required to monitor 2000 to 3000
-    nodes, the effort of the adversary is not significantly diminished when he
-    is only interested in 20 or 30. It is hard to see how an adversary who can
-    obtain access to a randomly selected portion of the Tor network would face
-    any new or qualitatively different obstacles in attempting to access much
-    of the rest of it.
-
-
-Implementation Issues:
-
-  The number of ORs this proposal would add to the Tor network is not known.
-  This is because there is no mechanism at present for recording unsuccessful
-  attempts to become an OR. If the proposal is considered promising it may be
-  worthwhile to issue an alpha series release where candidate ORs post a
-  primitive fallback descriptor to the authority directories. This fallback
-  descriptor would not contain any other flag that would make it eligible for
-  selection by clients. It would act solely as a means of sizing the number of
-  Tor instances that try and fail to become ORs.
-
-  The upper limit on the number of orconns from fallback ORs a normal,
-  published OR should be willing to accept is an open question. Is one
-  hundred, mostly idle, such orconns too onerous?
-
diff --git a/doc/spec/proposals/134-robust-voting.txt b/doc/spec/proposals/134-robust-voting.txt
deleted file mode 100644
index 5d5e77f..0000000
--- a/doc/spec/proposals/134-robust-voting.txt
+++ /dev/null
@@ -1,105 +0,0 @@
-Filename: 134-robust-voting.txt
-Title: More robust consensus voting with diverse authority sets
-Author: Peter Palfrader
-Created: 2008-04-01
-Status: Accepted
-Target: 0.2.2.x
-
-Overview:
-
-  A means to arrive at a valid directory consensus even when voters
-  disagree on who is an authority.
-
-
-Motivation:
-
-  Right now there are about five authoritative directory servers in the
-  Tor network, tho this number is expected to rise to about 15 eventually.
-
-  Adding a new authority requires synchronized action from all operators of
-  directory authorities so that at any time during the update at least half of
-  all authorities are running and agree on who is an authority.  The latter
-  requirement is there so that the authorities can arrive at a common
-  consensus:  Each authority builds the consensus based on the votes from
-  all authorities it recognizes, and so a different set of recognized
-  authorities will lead to a different consensus document.
-
-
-Objective:
-
-  The modified voting procedure outlined in this proposal obsoletes the
-  requirement for most authorities to exactly agree on the list of
-  authorities.
-
-
-Proposal:
-
-  The vote document each authority generates contains a list of 
-  authorities recognized by the generating authority.  This will be 
-  a list of authority identity fingerprints.
-
-  Authorities will accept votes from and serve/mirror votes also for
-  authorities they do not recognize.  (Votes contain the signing,
-  authority key, and the certificate linking them so they can be 
-  verified even without knowing the authority beforehand.)
-
-  Before building the consensus we will check which votes to use for
-  building:
-
-   1) We build a directed graph of which authority/vote recognizes
-      whom.
-   2) (Parts of the graph that aren't reachable, directly or
-      indirectly, from any authorities we recognize can be discarded
-      immediately.)
-   3) We find the largest fully connected subgraph.
-      (Should there be more than one subgraph of the same size there
-      needs to be some arbitrary ordering so we always pick the same.
-      E.g. pick the one who has the smaller (XOR of all votes' digests)
-      or something.)
-   4) If we are part of that subgraph, great.  This is the list of 
-      votes we build our consensus with.
-   5) If we are not part of that subgraph, remove all the nodes that
-      are part of it and go to 3.
-
-  Using this procedure authorities that are updated to recognize a
-  new authority will continue voting with the old group until a
-  sufficient number has been updated to arrive at a consensus with
-  the recently added authority.
-
-  In fact, the old set of authorities will probably be voting among
-  themselves until all but one has been updated to recognize the
-  new authority.  Then which set of votes is used for consensus 
-  building depends on which of the two equally large sets gets 
-  ordered before the other in step (3) above.
-
-  It is necessary to continue with the process in (5) even if we
-  are not in the largest subgraph.  Otherwise one rogue authority
-  could create a number of extra votes (by new authorities) so that
-  everybody stops at 5 and no consensus is built, even tho it would
-  be trusted by all clients.
-
-
-Anonymity Implications:
-
-  The author does not believe this proposal to have anonymity
-  implications.
-
-
-Possible Attacks/Open Issues/Some thinking required:
-
- Q: Can a number (less or exactly half) of the authorities cause an honest
-    authority to vote for "their" consensus rather than the one that would
-    result were all authorities taken into account?
-
-
- Q: Can a set of votes from external authorities, i.e of whom we trust either
-    none or at least not all, cause us to change the set of consensus makers we
-    pick?
- A: Yes, if other authorities decide they rather build a consensus with them
-    then they'll be thrown out in step 3.  But that's ok since those other
-    authorities will never vote with us anyway.
-    If we trust none of them then we throw them out even sooner, so no harm done.
-
- Q: Can this ever force us to build a consensus with authorities we do not
-    recognize?
- A: No, we can never build a fully connected set with them in step 3.
diff --git a/doc/spec/proposals/135-private-tor-networks.txt b/doc/spec/proposals/135-private-tor-networks.txt
deleted file mode 100644
index 131bbb9..0000000
--- a/doc/spec/proposals/135-private-tor-networks.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-Filename: 135-private-tor-networks.txt
-Title: Simplify Configuration of Private Tor Networks
-Version: $Revision$
-Last-Modified: $Date$
-Author: Karsten Loesing
-Created: 29-Apr-2008
-Status: Closed
-Target: 0.2.1.x
-Implemented-In: 0.2.1.2-alpha
-
-Change history:
-
-  29-Apr-2008  Initial proposal for or-dev
-  19-May-2008  Included changes based on comments by Nick to or-dev and
-               added a section for test cases.
-  18-Jun-2008  Changed testing-network-only configuration option names.
-
-Overview:
-
-  Configuring a private Tor network has become a time-consuming and
-  error-prone task with the introduction of the v3 directory protocol. In
-  addition to that, operators of private Tor networks need to set an
-  increasing number of non-trivial configuration options, and it is hard
-  to keep FAQ entries describing this task up-to-date. In this proposal we
-  (1) suggest to (optionally) accelerate timing of the v3 directory voting
-  process and (2) introduce an umbrella config option specifically aimed at
-  creating private Tor networks.
-
-Design:
-
-  1. Accelerate Timing of v3 Directory Voting Process
-
-  Tor has reasonable defaults for setting up a large, Internet-scale
-  network with comparably high latencies and possibly wrong server clocks.
-  However, those defaults are bad when it comes to quickly setting up a
-  private Tor network for testing, either on a single node or LAN (things
-  might be different when creating a test network on PlanetLab or
-  something). Some time constraints should be made configurable for private
-  networks. The general idea is to accelerate everything that has to do
-  with propagation of directory information, but nothing else, so that a
-  private network is available as soon as possible. (As a possible
-  safeguard, changing these configuration values could be made dependent on
-  the umbrella configuration option introduced in 2.)
-
-  1.1. Initial Voting Schedule
-
-  When a v3 directory does not know any consensus, it assumes an initial,
-  hard-coded VotingInterval of 30 minutes, VoteDelay of 5 minutes, and
-  DistDelay of 5 minutes. This is important for multiple, simultaneously
-  restarted directory authorities to meet at a common time and create an
-  initial consensus. Unfortunately, this means that it may take up to half
-  an hour (or even more) for a private Tor network to bootstrap.
-
-  We propose to make these three time constants configurable (note that
-  V3AuthVotingInterval, V3AuthVoteDelay, and V3AuthDistDelay do not have an
-  effect on the _initial_ voting schedule, but only on the schedule that a
-  directory authority votes for). This can be achieved by introducing three
-  new configuration options: TestingV3AuthInitialVotingInterval,
-  TestingV3AuthInitialVoteDelay, and TestingV3AuthInitialDistDelay.
-
-  As first safeguards, Tor should only accept configuration values for
-  TestingV3AuthInitialVotingInterval that divide evenly into the default
-  value of 30 minutes. The effect is that even if people misconfigured
-  their directory authorities, they would meet at the default values at the
-  latest. The second safeguard is to allow configuration only when the
-  umbrella configuration option TestingTorNetwork is set.
-
-  1.2. Immediately Provide Reachability Information (Running flag)
-
-  The default behavior of a directory authority is to provide the Running
-  flag only after the authority is available for at least 30 minutes. The
-  rationale is that before that time, an authority simply cannot deliver
-  useful information about other running nodes. But for private Tor
-  networks this may be different. This is currently implemented in the code
-  as:
-
-  /** If we've been around for less than this amount of time, our
-   * reachability information is not accurate. */
-  #define DIRSERV_TIME_TO_GET_REACHABILITY_INFO (30*60)
-
-  There should be another configuration option
-  TestingAuthDirTimeToLearnReachability with a default value of 30 minutes
-  that can be changed when running testing Tor networks, e.g. to 0 minutes.
-  The configuration value would simply replace the quoted constant. Again,
-  changing this option could be safeguarded by requiring the umbrella
-  configuration option TestingTorNetwork to be set.
-
-  1.3. Reduce Estimated Descriptor Propagation Time
-
-  Tor currently assumes that it takes up to 10 minutes until router
-  descriptors are propagated from the authorities to directory caches.
-  This is not very useful for private Tor networks, and we want to be able
-  to reduce this time, so that clients can download router descriptors in a
-  timely manner.
-
-  /** Clients don't download any descriptor this recent, since it will
-   * probably not have propagated to enough caches. */
-  #define ESTIMATED_PROPAGATION_TIME (10*60)
-
-  We suggest to introduce a new config option
-  TestingEstimatedDescriptorPropagationTime which defaults to 10 minutes,
-  but that can be set to any lower non-negative value, e.g. 0 minutes. The
-  same safeguards as in 1.2 could be used here, too.
-
-  2. Umbrella Option for Setting Up Private Tor Networks
-
-  Setting up a private Tor network requires a number of specific settings
-  that are not required or useful when running Tor in the public Tor
-  network. Instead of writing down these options in a FAQ entry, there
-  should be a single configuration option, e.g. TestingTorNetwork, that
-  changes all required settings at once. Newer Tor versions would keep the
-  set of configuration options up-to-date. It should still remain possible
-  to manually overwrite the settings that the umbrella configuration option
-  affects.
-
-  The following configuration options are set by TestingTorNetwork:
-
-  - ServerDNSAllowBrokenResolvConf 1
-      Ignore the situation that private relays are not aware of any name
-      servers.
-
-  - DirAllowPrivateAddresses 1
-      Allow router descriptors containing private IP addresses.
-
-  - EnforceDistinctSubnets 0
-      Permit building circuits with relays in the same subnet.
-
-  - AssumeReachable 1
-      Omit self-testing for reachability.
-
-  - AuthDirMaxServersPerAddr 0
-  - AuthDirMaxServersPerAuthAddr 0
-      Permit an unlimited number of nodes on the same IP address.
-
-  - ClientDNSRejectInternalAddresses 0
-      Believe in DNS responses resolving to private IP addresses.
-
-  - ExitPolicyRejectPrivate 0
-      Allow exiting to private IP addresses. (This one is a matter of
-      taste---it might be dangerous to make this a default in a private
-      network, although people setting up private Tor networks should know
-      what they are doing.)
-
-  - V3AuthVotingInterval 5 minutes
-  - V3AuthVoteDelay 20 seconds
-  - V3AuthDistDelay 20 seconds
-      Accelerate voting schedule after first consensus has been reached.
-
-  - TestingV3AuthInitialVotingInterval 5 minutes
-  - TestingV3AuthInitialVoteDelay 20 seconds
-  - TestingV3AuthInitialDistDelay 20 seconds
-      Accelerate initial voting schedule until first consensus is reached.
-
-  - TestingAuthDirTimeToLearnReachability 0 minutes
-      Consider routers as Running from the start of running an authority.
-
-  - TestingEstimatedDescriptorPropagationTime 0 minutes
-      Clients try downloading router descriptors from directory caches,
-      even when they are not 10 minutes old.
-
-  In addition to changing the defaults for these configuration options,
-  TestingTorNetwork can only be set when a user has manually configured
-  DirServer lines.
-
-Test:
-
-  The implementation of this proposal must pass the following tests:
-
-  1. Set TestingTorNetwork and see if dependent configuration options are
-     correctly changed.
-
-     tor DataDirectory . ControlPort 9051 TestingTorNetwork 1 DirServer \
-       "mydir 127.0.0.1:1234 0000000000000000000000000000000000000000"
-     telnet 127.0.0.1 9051
-     AUTHENTICATE
-     GETCONF TestingTorNetwork TestingAuthDirTimeToLearnReachability
-     250-TestingTorNetwork=1
-     250 TestingAuthDirTimeToLearnReachability=0
-     QUIT
-
-  2. Set TestingTorNetwork and a dependent configuration value to see if
-     the provided value is used for the dependent option.
-
-     tor DataDirectory . ControlPort 9051 TestingTorNetwork 1 DirServer \
-       "mydir 127.0.0.1:1234 0000000000000000000000000000000000000000" \
-       TestingAuthDirTimeToLearnReachability 5
-     telnet 127.0.0.1 9051
-     AUTHENTICATE
-     GETCONF TestingTorNetwork TestingAuthDirTimeToLearnReachability
-     250-TestingTorNetwork=1
-     250 TestingAuthDirTimeToLearnReachability=5
-     QUIT
-
-  3. Start with TestingTorNetwork set and change a dependent configuration
-     option later on.
-
-     tor DataDirectory . ControlPort 9051 TestingTorNetwork 1 DirServer \
-       "mydir 127.0.0.1:1234 0000000000000000000000000000000000000000"
-     telnet 127.0.0.1 9051
-     AUTHENTICATE
-     SETCONF TestingAuthDirTimeToLearnReachability=5
-     GETCONF TestingAuthDirTimeToLearnReachability
-     250 TestingAuthDirTimeToLearnReachability=5
-     QUIT
-
-  4. Start with TestingTorNetwork set and a dependent configuration value,
-     and reset that dependent configuration value. The result should be
-     the testing-network specific default value.
-
-     tor DataDirectory . ControlPort 9051 TestingTorNetwork 1 DirServer \
-       "mydir 127.0.0.1:1234 0000000000000000000000000000000000000000" \
-       TestingAuthDirTimeToLearnReachability 5
-     telnet 127.0.0.1 9051
-     AUTHENTICATE
-     GETCONF TestingAuthDirTimeToLearnReachability
-     250 TestingAuthDirTimeToLearnReachability=5
-     RESETCONF TestingAuthDirTimeToLearnReachability
-     GETCONF TestingAuthDirTimeToLearnReachability
-     250 TestingAuthDirTimeToLearnReachability=0
-     QUIT
-
-  5. Leave TestingTorNetwork unset and check if dependent configuration
-     options are left unchanged.
-
-     tor DataDirectory . ControlPort 9051 DirServer \
-       "mydir 127.0.0.1:1234 0000000000000000000000000000000000000000"
-     telnet 127.0.0.1 9051
-     AUTHENTICATE
-     GETCONF TestingTorNetwork TestingAuthDirTimeToLearnReachability
-     250-TestingTorNetwork=0
-     250 TestingAuthDirTimeToLearnReachability=1800
-     QUIT
-
-  6. Leave TestingTorNetwork unset, but set dependent configuration option
-     which should fail.
-
-     tor DataDirectory . ControlPort 9051 DirServer \
-       "mydir 127.0.0.1:1234 0000000000000000000000000000000000000000" \
-       TestingAuthDirTimeToLearnReachability 0
-     [warn] Failed to parse/validate config:
-     TestingAuthDirTimeToLearnReachability may only be changed in testing
-     Tor networks!
-
-  7. Start with TestingTorNetwork unset and change dependent configuration
-     option later on which should fail.
-
-     tor DataDirectory . ControlPort 9051 DirServer \
-       "mydir 127.0.0.1:1234 0000000000000000000000000000000000000000"
-     telnet 127.0.0.1 9051
-     AUTHENTICATE
-     SETCONF TestingAuthDirTimeToLearnReachability=0
-     513 Unacceptable option value: TestingAuthDirTimeToLearnReachability
-     may only be changed in testing Tor networks!
-
-  8. Start with TestingTorNetwork unset and set it later on which should
-     fail.
-
-     tor DataDirectory . ControlPort 9051 DirServer \
-       "mydir 127.0.0.1:1234 0000000000000000000000000000000000000000"
-     telnet 127.0.0.1 9051
-     AUTHENTICATE
-     SETCONF TestingTorNetwork=1
-     553 Transition not allowed: While Tor is running, changing
-     TestingTorNetwork is not allowed.
-
-  9. Start with TestingTorNetwork set and unset it later on which should
-     fail.
-
-     tor DataDirectory . ControlPort 9051 TestingTorNetwork 1 DirServer \
-       "mydir 127.0.0.1:1234 0000000000000000000000000000000000000000"
-     telnet 127.0.0.1 9051
-     AUTHENTICATE
-     RESETCONF TestingTorNetwork
-     513 Unacceptable option value: TestingV3AuthInitialVotingInterval may
-     only be changed in testing Tor networks!
-
- 10. Set TestingTorNetwork, but do not provide an alternate DirServer
-     which should fail.
-
-     tor DataDirectory . ControlPort 9051 TestingTorNetwork 1
-     [warn] Failed to parse/validate config: TestingTorNetwork may only be
-     configured in combination with a non-default set of DirServers.
-
diff --git a/doc/spec/proposals/136-legacy-keys.txt b/doc/spec/proposals/136-legacy-keys.txt
deleted file mode 100644
index f2b1b5c..0000000
--- a/doc/spec/proposals/136-legacy-keys.txt
+++ /dev/null
@@ -1,100 +0,0 @@
-Filename: 136-legacy-keys.txt
-Title: Mass authority migration with legacy keys
-Author: Nick Mathewson
-Created: 13-May-2008
-Status: Closed
-Implemented-In: 0.2.0.x
-
-Overview:
-
-  This document describes a mechanism to change the keys of more than
-  half of the directory servers at once without breaking old clients
-  and caches immediately.
-
-Motivation:
-
-  If a single authority's identity key is believed to be compromised,
-  the solution is obvious: remove that authority from the list,
-  generate a new certificate, and treat the new cert as belonging to a
-  new authority.  This approach works fine so long as less than 1/2 of
-  the authority identity keys are bad.
-
-  Unfortunately, the mass-compromise case is possible if there is a
-  sufficiently bad bug in Tor or in any OS used by a majority of v3
-  authorities.  Let's be prepared for it!
-
-  We could simply stop using the old keys and start using new ones,
-  and tell all clients running insecure versions to upgrade.
-  Unfortunately, this breaks our cacheing system pretty badly, since
-  caches won't cache a consensus that they don't believe in.  It would
-  be nice to have everybody become secure the moment they upgrade to a
-  version listing the new authority keys, _without_ breaking upgraded
-  clients until the caches upgrade.
-
-  So, let's come up with a way to provide a time window where the
-  consensuses are signed with the new keys and with the old.
-
-Design:
-
-  We allow directory authorities to list a single "legacy key"
-  fingerprint in their votes.  Each authority may add a single legacy
-  key.  The format for this line is:
-
-     legacy-dir-key FINGERPRINT
-
-  We describe a new consensus method for generating directory
-  consensuses.  This method is consensus method "3".
-
-  When the authorities decide to use method "3" (as described in 3.4.1
-  of dir-spec.txt), for every included vote with a legacy-dir-key line,
-  the consensus includes an extra dir-source line.  The fingerprint in
-  this extra line is as in the legacy-dir-key line.  The ports and
-  addresses are in the dir-source line.  The nickname is as in the
-  dir-source line, with the string "-legacy" appended.
-
-      [We need to include this new dir-source line because the code
-      won't accept or preserve signatures from authorities not listed
-      as contributing to the consensus.]
-
-  Authorities using legacy dir keys include two signatures on their
-  consensuses: one generated with a signing key signed with their real
-  signing key, and another generated with a signing key signed with
-  another signing key attested to by their identity key.  These
-  signing keys MUST be different.  Authorities MUST serve both
-  certificates if asked.
-
-Process:
-
-  In the event of a mass key failure, we'll follow the following
-  (ugly) procedure:
-     - All affected authorities generate new certificates and identity
-       keys, and circulate their new dirserver lines.  They copy their old
-       certificates and old broken keys, but put them in new "legacy
-       key files".
-     - At the earliest time that can be arranged, the authorities
-       replace their signing keys, identity keys, and certificates
-       with the new uncompromised versions, and update to the new list
-       of dirserer lines.
-     - They add an "V3DirAdvertiseLegacyKey 1" option to their torrc.
-     - Now, new consensuses will be generated using the new keys, but
-       the results will also be signed with the old keys.
-     - Clients and caches are told they need to upgrade, and given a
-       time window to do so.
-     - At the end of the time window, authorities remove the
-       V3DirAdvertiseLegacyKey option.
-
-Notes:
-
-  It might be good to get caches to cache consensuses that they do not
-  believe in.  I'm not sure the best way of how to do this.
-
-  It's a superficially neat idea to have new signing keys and have
-  them signed by the new and by the old authority identity keys.  This
-  breaks some code, though, and doesn't actually gain us anything,
-  since we'd still need to include each signature twice.
-
-  It's also a superficially neat idea, if identity keys and signing
-  keys are compromised, to at least replace all the signing keys.
-  I don't think this achieves us anything either, though.
-
-
diff --git a/doc/spec/proposals/137-bootstrap-phases.txt b/doc/spec/proposals/137-bootstrap-phases.txt
deleted file mode 100644
index 18d3dfa..0000000
--- a/doc/spec/proposals/137-bootstrap-phases.txt
+++ /dev/null
@@ -1,237 +0,0 @@
-Filename: 137-bootstrap-phases.txt
-Title: Keep controllers informed as Tor bootstraps
-Version: $Revision$
-Last-Modified: $Date$
-Author: Roger Dingledine
-Created: 07-Jun-2008
-Status: Closed
-Implemented-In: 0.2.1.x
-
-1. Overview.
-
-  Tor has many steps to bootstrapping directory information and
-  initial circuits, but from the controller's perspective we just have
-  a coarse-grained "CIRCUIT_ESTABLISHED" status event. Tor users with
-  slow connections or with connectivity problems can wait a long time
-  staring at the yellow onion, wondering if it will ever change color.
-
-  This proposal describes a new client status event so Tor can give
-  more details to the controller. Section 2 describes the changes to the
-  controller protocol; Section 3 describes Tor's internal bootstrapping
-  phases when everything is going correctly; Section 4 describes when
-  Tor detects a problem and issues a bootstrap warning; Section 5 covers
-  suggestions for how controllers should display the results.
-
-2. Controller event syntax.
-
-  The generic status event is:
-
-    "650" SP StatusType SP StatusSeverity SP StatusAction
-                                        [SP StatusArguments] CRLF
-
-  So in this case we send
-  650 STATUS_CLIENT NOTICE/WARN BOOTSTRAP \
-  PROGRESS=num TAG=Keyword SUMMARY=String \
-  [WARNING=String REASON=Keyword COUNT=num RECOMMENDATION=Keyword]
-
-  The arguments MAY appear in any order. Controllers MUST accept unrecognized
-  arguments.
-
-  "Progress" gives a number between 0 and 100 for how far through
-  the bootstrapping process we are. "Summary" is a string that can be
-  displayed to the user to describe the *next* task that Tor will tackle,
-  i.e., the task it is working on after sending the status event. "Tag"
-  is an optional string that controllers can use to recognize bootstrap
-  phases from Section 3, if they want to do something smarter than just
-  blindly displaying the summary string.
-
-  The severity describes whether this is a normal bootstrap phase
-  (severity notice) or an indication of a bootstrapping problem
-  (severity warn). If severity warn, it should also include a "warning"
-  argument string with any hints Tor has to offer about why it's having
-  troubles bootstrapping, a "reason" string that lists one of the reasons
-  allowed in the ORConn event, a "count" number that tells how many
-  bootstrap problems there have been so far at this phase, and a
-  "recommendation" keyword to indicate how the controller ought to react.
-
-3. The bootstrap phases.
-
-  This section describes the various phases currently reported by
-  Tor. Controllers should not assume that the percentages and tags listed
-  here will continue to match up, or even that the tags will stay in
-  the same order. Some phases might also be skipped (not reported) if the
-  associated bootstrap step is already complete, or if the phase no longer
-  is necessary.  Only "starting" and "done" are guaranteed to exist in all
-  future versions.
-
-  Current Tor versions enter these phases in order, monotonically;
-  future Tors MAY revisit earlier stages.
-
-  Phase 0:
-  tag=starting summary="starting"
-
-  Tor starts out in this phase.
-
-  Phase 5:
-  tag=conn_dir summary="Connecting to directory mirror"
-
-  Tor sends this event as soon as Tor has chosen a directory mirror ---
-  one of the authorities if bootstrapping for the first time or after
-  a long downtime, or one of the relays listed in its cached directory
-  information otherwise.
-
-  Tor will stay at this phase until it has successfully established
-  a TCP connection with some directory mirror. Problems in this phase
-  generally happen because Tor doesn't have a network connection, or
-  because the local firewall is dropping SYN packets.
-
-  Phase 10
-  tag=handshake_dir summary="Finishing handshake with directory mirror"
-
-  This event occurs when Tor establishes a TCP connection with a relay used
-  as a directory mirror (or its https proxy if it's using one). Tor remains
-  in this phase until the TLS handshake with the relay is finished.
-
-  Problems in this phase generally happen because Tor's firewall is
-  doing more sophisticated MITM attacks on it, or doing packet-level
-  keyword recognition of Tor's handshake.
-
-  Phase 15:
-  tag=onehop_create summary="Establishing one-hop circuit for dir info"
-
-  Once TLS is finished with a relay, Tor will send a CREATE_FAST cell
-  to establish a one-hop circuit for retrieving directory information.
-  It will remain in this phase until it receives the CREATED_FAST cell
-  back, indicating that the circuit is ready.
-
-  Phase 20:
-  tag=requesting_status summary="Asking for networkstatus consensus"
-
-  Once we've finished our one-hop circuit, we will start a new stream
-  for fetching the networkstatus consensus. We'll stay in this phase
-  until we get the 'connected' relay cell back, indicating that we've
-  established a directory connection.
-
-  Phase 25:
-  tag=loading_status summary="Loading networkstatus consensus"
-
-  Once we've established a directory connection, we will start fetching
-  the networkstatus consensus document. This could take a while; this
-  phase is a good opportunity for using the "progress" keyword to indicate
-  partial progress.
-
-  This phase could stall if the directory mirror we picked doesn't
-  have a copy of the networkstatus consensus so we have to ask another,
-  or it does give us a copy but we don't find it valid.
-
-  Phase 40:
-  tag=loading_keys summary="Loading authority key certs"
-
-  Sometimes when we've finished loading the networkstatus consensus,
-  we find that we don't have all the authority key certificates for the
-  keys that signed the consensus. At that point we put the consensus we
-  fetched on hold and fetch the keys so we can verify the signatures.
-
-  Phase 45
-  tag=requesting_descriptors summary="Asking for relay descriptors"
-
-  Once we have a valid networkstatus consensus and we've checked all
-  its signatures, we start asking for relay descriptors. We stay in this
-  phase until we have received a 'connected' relay cell in response to
-  a request for descriptors.
-
-  Phase 50:
-  tag=loading_descriptors summary="Loading relay descriptors"
-
-  We will ask for relay descriptors from several different locations,
-  so this step will probably make up the bulk of the bootstrapping,
-  especially for users with slow connections. We stay in this phase until
-  we have descriptors for at least 1/4 of the usable relays listed in
-  the networkstatus consensus. This phase is also a good opportunity to
-  use the "progress" keyword to indicate partial steps.
-
-  Phase 80:
-  tag=conn_or summary="Connecting to entry guard"
-
-  Once we have a valid consensus and enough relay descriptors, we choose
-  some entry guards and start trying to build some circuits. This step
-  is similar to the "conn_dir" phase above; the only difference is
-  the context.
-
-  If a Tor starts with enough recent cached directory information,
-  its first bootstrap status event will be for the conn_or phase.
-
-  Phase 85:
-  tag=handshake_or summary="Finishing handshake with entry guard"
-
-  This phase is similar to the "handshake_dir" phase, but it gets reached
-  if we finish a TCP connection to a Tor relay and we have already reached
-  the "conn_or" phase. We'll stay in this phase until we complete a TLS
-  handshake with a Tor relay.
-
-  Phase 90:
-  tag=circuit_create "Establishing circuits"
-
-  Once we've finished our TLS handshake with an entry guard, we will
-  set about trying to make some 3-hop circuits in case we need them soon.
-
-  Phase 100:
-  tag=done summary="Done"
-
-  A full 3-hop circuit has been established. Tor is ready to handle
-  application connections now.
-
-4. Bootstrap problem events.
-
-  When an OR Conn fails, we send a "bootstrap problem" status event, which
-  is like the standard bootstrap status event except with severity warn.
-  We include the same progress, tag, and summary values as we would for
-  a normal bootstrap event, but we also include "warning", "reason",
-  "count", and "recommendation" key/value combos.
-
-  The "reason" values are long-term-stable controller-facing tags to
-  identify particular issues in a bootstrapping step.  The warning
-  strings, on the other hand, are human-readable. Controllers SHOULD
-  NOT rely on the format of any warning string. Currently the possible
-  values for "recommendation" are either "ignore" or "warn" -- if ignore,
-  the controller can accumulate the string in a pile of problems to show
-  the user if the user asks; if warn, the controller should alert the
-  user that Tor is pretty sure there's a bootstrapping problem.
-
-  Currently Tor uses recommendation=ignore for the first nine bootstrap
-  problem reports for a given phase, and then uses recommendation=warn
-  for subsequent problems at that phase. Hopefully this is a good
-  balance between tolerating occasional errors and reporting serious
-  problems quickly.
-
-5. Suggested controller behavior.
-
-  Controllers should start out with a yellow onion or the equivalent
-  ("starting"), and then watch for either a bootstrap status event
-  (meaning the Tor they're using is sufficiently new to produce them,
-  and they should load up the progress bar or whatever they plan to use
-  to indicate progress) or a circuit_established status event (meaning
-  bootstrapping is finished).
-
-  In addition to a progress bar in the display, controllers should also
-  have some way to indicate progress even when no controller window is
-  open. For example, folks using Tor Browser Bundle in hostile Internet
-  cafes don't want a big splashy screen up. One way to let the user keep
-  informed of progress in a more subtle way is to change the task tray
-  icon and/or tooltip string as more bootstrap events come in.
-
-  Controllers should also have some mechanism to alert their user when
-  bootstrapping problems are reported. Perhaps we should gather a set of
-  help texts and the controller can send the user to the right anchor in a
-  "bootstrapping problems" page in the controller's help subsystem?
-
-6. Getting up to speed when the controller connects.
-
-  There's a new "GETINFO /status/bootstrap-phase" option, which returns
-  the most recent bootstrap phase status event sent. Specifically,
-  it returns a string starting with either "NOTICE BOOTSTRAP ..." or
-  "WARN BOOTSTRAP ...".
-
-  Controllers should use this getinfo when they connect or attach to
-  Tor to learn its current state.
-
diff --git a/doc/spec/proposals/138-remove-down-routers-from-consensus.txt b/doc/spec/proposals/138-remove-down-routers-from-consensus.txt
deleted file mode 100644
index a07764d..0000000
--- a/doc/spec/proposals/138-remove-down-routers-from-consensus.txt
+++ /dev/null
@@ -1,51 +0,0 @@
-Filename: 138-remove-down-routers-from-consensus.txt
-Title: Remove routers that are not Running from consensus documents
-Version: $Revision$
-Last-Modified: $Date$
-Author: Peter Palfrader
-Created: 11-Jun-2008
-Status: Closed
-Implemented-In: 0.2.1.2-alpha
-
-1. Overview.
-
-  Tor directory authorities hourly vote and agree on a consensus document
-  which lists all the routers on the network together with some of their
-  basic properties, like if a router is an exit node, whether it is
-  stable or whether it is a version 2 directory mirror.
-
-  One of the properties given with each router is the 'Running' flag.
-  Clients do not use routers that are not listed as running.
-
-  This proposal suggests that routers without the Running flag are not
-  listed at all.
-
-2. Current status
-
-  At a typical bootstrap a client downloads a 140KB consensus, about
-  10KB of certificates to verify that consensus, and about 1.6MB of
-  server descriptors, about 1/4 of which it requires before it will
-  start building circuits.
-
-  Another proposal deals with how to get that huge 1.6MB fraction to
-  effectively zero (by downloading only individual descriptors, on
-  demand).  Should that get successfully implemented that will leave the
-  140KB compressed consensus as a large fraction of what a client needs
-  to get in order to work.
-
-  About one third of the routers listed in a consensus are not running
-  and will therefore never be used by clients who use this consensus.
-  Not listing those routers will save about 30% to 40% in size.
-
-3. Proposed change
-
-  Authority directory servers produce vote documents that include all
-  the servers they know about, running or not, like they currently
-  do.  In addition these vote documents also state that the authority
-  supports a new consensus forming method (method number 4).
-
-  If more than two thirds of votes that an authority has received claim
-  they support method 4 then this new method will be used:  The
-  consensus document is formed like before but a new last step removes
-  all routers from the listing that are not marked as Running.
-
diff --git a/doc/spec/proposals/139-conditional-consensus-download.txt b/doc/spec/proposals/139-conditional-consensus-download.txt
deleted file mode 100644
index 941f5ad..0000000
--- a/doc/spec/proposals/139-conditional-consensus-download.txt
+++ /dev/null
@@ -1,94 +0,0 @@
-Filename: 139-conditional-consensus-download.txt
-Title: Download consensus documents only when it will be trusted
-Author: Peter Palfrader
-Created: 2008-04-13
-Status: Closed
-Implemented-In: 0.2.1.x
-
-Overview:
-
-  Servers only provide consensus documents to clients when it is known that
-  the client will trust it.
-
-Motivation:
-
-  When clients[1] want a new network status consensus they request it
-  from a Tor server using the URL path /tor/status-vote/current/consensus.
-  Then after downloading the client checks if this consensus can be
-  trusted.  Whether the client trusts the consensus depends on the
-  authorities that the client trusts and how many of those
-  authorities signed the consensus document.
-
-  If the client cannot trust the consensus document it is disregarded
-  and a new download is tried at a later time.  Several hundred
-  kilobytes of server bandwidth were wasted by this single client's
-  request.
-
-  With hundreds of thousands of clients this will have undesirable
-  consequences when the list of authorities has changed so much that a
-  large number of established clients no longer can trust any consensus
-  document formed.
-
-Objective:
-
-  The objective of this proposal is to make clients not download
-  consensuses they will not trust.
-
-Proposal:
-
-  The list of authorities that are trusted by a client are encoded in
-  the URL they send to the directory server when requesting a consensus
-  document.
-
-  The directory server then only sends back the consensus when more than
-  half of the authorities listed in the request have signed the
-  consensus.  If it is known that the consensus will not be trusted
-  a 404 error code is sent back to the client.
-
-  This proposal does not require directory caches to keep more than one
-  consensus document.  This proposal also does not require authorities
-  to verify the signature on the consensus document of authorities they
-  do not recognize.
-
-  The new URL scheme to download a consensus is
-  /tor/status-vote/current/consensus/<F> where F is a list of
-  fingerprints, sorted in ascending order, and concatenated using a +
-  sign.
-
-  Fingerprints are uppercase hexadecimal encodings of the authority
-  identity key's digest.  Servers should also accept requests that
-  use lower case or mixed case hexadecimal encodings.
-
-  A .z URL for compressed versions of the consensus will be provided
-  similarly to existing resources and is the URL that usually should
-  be used by clients.
-
-Migration:
-
-  The old location of the consensus should continue to work
-  indefinitely.  Not only is it used by old clients, but it is a useful
-  resource for automated tools that do not particularly care which
-  authorities have signed the consensus.
-
-  Authorities that are known to the client a priori by being shipped
-  with the Tor code are assumed to handle this format.
-
-  When downloading a consensus document from caches that do not support this
-  new format they fall back to the old download location.
-
-  Caches support the new format starting with Tor version 0.2.1.1-alpha.
-
-Anonymity Implications:
-
-  By supplying the list of authorities a client trusts to the directory
-  server we leak information (like likely version of Tor client) to the
-  directory server.  In the current system we also leak that we are
-  very old - by re-downloading the consensus over and over again, but
-  only when we are so old that we no longer can trust the consensus.
-
-
-
-Footnotes:
- 1. For the purpose of this proposal a client can be any Tor instance
-    that downloads a consensus document.  This includes relays,
-    directory caches as well as end users.
diff --git a/doc/spec/proposals/140-consensus-diffs.txt b/doc/spec/proposals/140-consensus-diffs.txt
deleted file mode 100644
index da63bfe..0000000
--- a/doc/spec/proposals/140-consensus-diffs.txt
+++ /dev/null
@@ -1,149 +0,0 @@
-Filename: 140-consensus-diffs.txt
-Title: Provide diffs between consensuses
-Version: $Revision$
-Last-Modified: $Date$
-Author: Peter Palfrader
-Created: 13-Jun-2008
-Status: Accepted
-Target: 0.2.2.x
-
-1. Overview.
-
-  Tor clients and servers need a list of which relays are on the
-  network.  This list, the consensus, is created by authorities
-  hourly and clients fetch a copy of it, with some delay, hourly.
-
-  This proposal suggests that clients download diffs of consensuses
-  once they have a consensus instead of hourly downloading a full
-  consensus.
-
-2. Numbers
-
-  After implementing proposal 138 which removes nodes that are not
-  running from the list a consensus document is about 92 kilobytes
-  in size after compression.
-
-  The diff between two consecutive consensus, in ed format, is on
-  average 13 kilobytes compressed.
-
-3. Proposal
-
-3.1 Clients
-
-  If a client has a consensus that is recent enough it SHOULD
-  try to download a diff to get the latest consensus rather than
-  fetching a full one.
-
-  [XXX: what is recent enough?
-	time delta in hours / size of compressed diff
-	 0	20
-	 1	9650
-	 2	17011
-	 3	23150
-	 4	29813
-	 5	36079
-	 6	39455
-	 7	43903
-	 8	48907
-	 9	54549
-	10	60057
-	11	67810
-	12	71171
-	13	73863
-	14	76048
-	15	80031
-	16	84686
-	17	89862
-	18	94760
-	19	94868
-	20	94223
-	21	93921
-	22	92144
-	23	90228
-	[ size of gzip compressed "diff -e" between the consensus on
-	  2008-06-01-00:00:00 and the following consensuses that day.
-	  Consensuses have been modified to exclude down routers per
-	  proposal 138. ]
-
-   Data suggests that for the first few hours diffs are very useful,
-   saving about 60% for the first three hours, 30% for the first 10,
-   and almost nothing once we are past 16 hours.
-  ]
-
-3.2 Servers
-
-  Directory authorities and servers need to keep up to X [XXX: depends
-  on how long clients try to download diffs per above] old consensus
-  documents so they can build diffs.  They should offer a diff to the
-  most recent consensus at the URL
-
-  http://tor.noreply.org/tor/status-vote/current/consensus/diff/<HASH>/<FPRLIST>
-
-  where hash is the full digest of the consensus the client currently
-  has, and FPRLIST is a list of (abbreviated) fingerprints of
-  authorities the client trusts.
-
-  Servers will only return a consensus if more than half of the requested
-  authorities have signed the document, otherwise a 404 error will be sent
-  back.  The fingerprints can be shortened to a length of any multiple of
-  two, using only the leftmost part of the encoded fingerprint.  Tor uses
-  3 bytes (6 hex characters) of the fingerprint.  (This is just like the
-  conditional consensus downloads that Tor supports starting with
-  0.1.2.1-alpha.)
-
-  If a server cannot offer a diff from the consensus identified by the
-  hash but has a current consensus it MUST return the full consensus.
-
-  [XXX: what should we do when the client already has the latest
-  consensus?  I can think of the following options:
-    - send back 3xx not modified
-    - send back 200 ok and an empty diff
-    - send back 404 nothing newer here.
-
-    I currently lean towards the empty diff.]
-
-4. Diff Format
-
-  Diffs start with the token "network-status-diff-version" followed by a
-  space and the version number, currently "1".
-
-  If a document does not start with network-status-diff it is assumed
-  to be a full consensus download and would therefore currently start
-  with "network-status-version 3".
-
-  Following the network-status-diff header line is a diff, or patch, in
-  limited ed format.  We choose this format because it is easy to create
-  and process with standard tools (patch, diff -e, ed).  This will help
-  us in developing and testing this proposal and it should make future
-  debugging easier.
-
-  [ If at one point in the future we decide that the space benefits from
-    a custom diff format outweighs these benefits we can always
-    introduce a new diff format and offer it at for instance
-    ../diff2/... ]
-
-  We support the following ed commands, each on a line by itself:
-   - "<n1>d"          Delete line n1
-   - "<n1>,<n2>d"     Delete lines n1 through n2, including
-   - "<n1>c"          Replace line n1 with the following block
-   - "<n1>,<n2>c"     Replace lines n1 through n2, including, with the
-                      following block.
-   - "<n1>a"          Append the following block after line n1.
-   - "a"              Append the following block after the current line.
-   - "s/.//"          Remove the first character in the current line.
-
-  Note that line numbers always apply to the file after all previous
-  commands have already been applied.
-
-  The "current line" is either the first line of the file, if this is
-  the first command, the last line of a block we added in an append or
-  change command, or the line immediate following a set of lines we just
-  deleted (or the last line of the file if there are no lines after
-  that).
-
-  The replace and append command take blocks.  These blocks are simply
-  appended to the diff after the line with the command.  A line with
-  just a period (".") ends the block (and is not part of the lines
-  to add).  Note that it is impossible to insert a line with just
-  a single dot.  Recommended procedure is to insert a line with
-  two dots, then remove the first character of that line using s/.//.
diff --git a/doc/spec/proposals/141-jit-sd-downloads.txt b/doc/spec/proposals/141-jit-sd-downloads.txt
deleted file mode 100644
index b0c2b2c..0000000
--- a/doc/spec/proposals/141-jit-sd-downloads.txt
+++ /dev/null
@@ -1,325 +0,0 @@
-Filename: 141-jit-sd-downloads.txt
-Title: Download server descriptors on demand
-Version: $Revision$
-Last-Modified: $Date$
-Author: Peter Palfrader
-Created: 15-Jun-2008
-Status: Draft
-
-1. Overview
-
-  Downloading all server descriptors is the most expensive part
-  of bootstrapping a Tor client.  These server descriptors currently
-  amount to about 1.5 Megabytes of data, and this size will grow
-  linearly with network size.
-
-  Fetching all these server descriptors takes a long while for people
-  behind slow network connections.  It is also a considerable load on
-  our network of directory mirrors.
-
-  This document describes proposed changes to the Tor network and
-  directory protocol so that clients will no longer need to download
-  all server descriptors.
-
-  These changes consist of moving load balancing information into
-  network status documents, implementing a means to download server
-  descriptors on demand in an anonymity-preserving way, and dealing
-  with exit node selection.
-
-2. What is in a server descriptor
-
-  When a Tor client starts the first thing it will try to get is a
-  current network status document: a consensus signed by a majority
-  of directory authorities.  This document is currently about 100
-  Kilobytes in size, tho it will grow linearly with network size.
-  This document lists all servers currently running on the network.
-  The Tor client will then try to get a server descriptor for each
-  of the running servers.  All server descriptors currently amount
-  to about 1.5 Megabytes of downloads.
-
-  A Tor client learns several things about a server from its descriptor.
-  Some of these it already learned from the network status document
-  published by the authorities, but the server descriptor contains it
-  again in a single statement signed by the server itself, not just by
-  the directory authorities.
-
-  Tor clients use the information from server descriptors for
-  different purposes, which are considered in the following sections.
-
-  #three ways:  One, to determine if a server will be able to handle
-  #this client's request; two, to actually communicate or use the server;
-  #three, for load balancing decisions.
-  #
-  #These three points are considered in the following subsections.
-
-2.1 Load balancing
-
-  The Tor load balancing mechanism is quite complex in its details, but
-  it has a simple goal: The more traffic a server can handle the more
-  traffic it should get.  That means the more traffic a server can
-  handle the more likely a client will use it.
-
-  For this purpose each server descriptor has bandwidth information
-  which tries to convey a server's capacity to clients.
-
-  Currently we weigh servers differently for different purposes.  There
-  is a weigh for when we use a server as a guard node (our entry to the
-  Tor network), there is one weigh we assign servers for exit duties,
-  and a third for when we need intermediate (middle) nodes.
-
-2.2 Exit information
-
-  When a Tor wants to exit to some resource on the internet it will
-  build a circuit to an exit node that allows access to that resource's
-  IP address and TCP Port.
-
-  When building that circuit the client can make sure that the circuit
-  ends at a server that will be able to fulfill the request because the
-  client already learned of all the servers' exit policies from their
-  descriptors.
-
-2.3 Capability information
-
-  Server descriptors contain information about the specific version or
-  the Tor protocol they understand [proposal 105].
-
-  Furthermore the server descriptor also contains the exact version of
-  the Tor software that the server is running and some decisions are
-  made based on the server version number (for instance a Tor client
-  will only make conditional consensus requests [proposal 139] when
-  talking to Tor servers version 0.2.1.1-alpha or later).
-
-2.4 Contact/key information
-
-  A server descriptor lists a server's IP address and TCP ports on which
-  it accepts onion and directory connections.  Furthermore it contains
-  the onion key (a short lived RSA key to which clients encrypt CREATE
-  cells).
-
-2.5 Identity information
-
-  A Tor client learns the digest of a server's key from the network
-  status document.  Once it has a server descriptor this descriptor
-  contains the full RSA identity key of the server.  Clients verify
-  that 1) the digest of the identity key matches the expected digest
-  it got from the consensus, and 2) that the signature on the descriptor
-  from that key is valid.
-
-
-3. No longer require clients to have copies of all SDs
-
-3.1 Load balancing info in consensus documents
-
-  One of the reasons why clients download all server descriptors is for
-  doing load proper load balancing as described in 2.1.  In order for
-  clients to not require all server descriptors this information will
-  have to move into the network status document.
-
-  Consensus documents will have a new line per router similar
-  to the "r", "s", and "v" lines that already exist.  This line
-  will convey weight information to clients.
-
-   "w Bandwidth=193"
-
-  The bandwidth number is the lesser of observed bandwidth and bandwidth
-  rate limit from the server descriptor that the "r" line referenced by
-  digest (1st and 3rd field of the bandwidth line in the descriptor).
-  It is given in kilobytes per second so the byte value in the
-  descriptor has to be divided by 1024 (and is then truncated, i.e.
-  rounded down).
-
-  Authorities will cap the bandwidth number at some arbitrary value,
-  currently 10MB/sec.  If a router claims a larger bandwidth an
-  authority's vote will still only show Bandwidth=10240.
-
-  The consensus value for bandwidth is the median of all bandwidth
-  numbers given in votes.  In case of an even number of votes we use
-  the lower median.  (Using this procedure allows us to change the
-  cap value more easily.)
-
-  Clients should believe the bandwidth as presented in the consensus,
-  not capping it again.
-
-3.2 Fetching descriptors on demand
-
-  As described in 2.4 a descriptor lists IP address, OR- and Dir-Port,
-  and the onion key for a server.
-
-  A client already knows the IP address and the ports from the consensus
-  documents, but without the onion key it will not be able to send
-  CREATE/EXTEND cells for that server.  Since the client needs the onion
-  key it needs the descriptor.
-
-  If a client only downloaded a few descriptors in an observable manner
-  then that would leak which nodes it was going to use.
-
-  This proposal suggests the following:
-
-  1) when connecting to a guard node for which the client does not
-     yet have a cached descriptor it requests the descriptor it
-     expects by hash.  (The consensus document that the client holds
-     has a hash for the descriptor of this server.  We want exactly
-     that descriptor, not a different one.)
-
-     It does that by sending a RELAY_REQUEST_SD cell.
-
-     A client MAY cache the descriptor of the guard node so that it does
-     not need to request it every single time it contacts the guard.
-
-  2) when a client wants to extend a circuit that currently ends in
-     server B to a new next server C, the client will send a
-     RELAY_REQUEST_SD cell to server B.  This cell contains in its
-     payload the hash of a server descriptor the client would like
-     to obtain (C's server descriptor).  The server sends back the
-     descriptor and the client can now form a valid EXTEND/CREATE cell
-     encrypted to C's onion key.
-
-     Clients MUST NOT cache such descriptors.  If they did they might
-     leak that they already extended to that server at least once
-     before.
-
-  Replies to RELAY_REQUEST_SD requests need to be padded to some
-  constant upper limit in order to conceal a client's destination
-  from anybody who might be counting cells/bytes.
-
-  RELAY_REQUEST_SD cells contain the following information:
-    - hash of the server descriptor requested
-    - hash of the identity digest of the server for which we want the SD
-    - IP address and OR-port or the server for which we want the SD
-    - padding factor - the number of cells we want the answer
-      padded to.
-      [XXX this just occured to me and it might be smart.  or it might
-       be stupid.  clients would learn the padding factor they want
-       to use from the consensus document.  This allows us to grow
-       the replies later on should SDs become larger.]
-  [XXX: figure out a decent padding size]
-
-3.3 Protocol versions
-
-  Server descriptors contain optional information of supported
-  link-level and circuit-level protocols in the form of
-  "opt protocols Link 1 2 Circuit 1".  These are not currently needed
-  and will probably eventually move into the "v" (version) line in
-  the consensus.  This proposal does not deal with them.
-
-  Similarly a server descriptor contains the version number of
-  a Tor node.  This information is already present in the consensus
-  and is thus available to all clients immediately.
-
-3.4 Exit selection
-
-  Currently finding an appropriate exit node for a user's request is
-  easy for a client because it has complete knowledge of all the exit
-  policies of all servers on the network.
-
-  The consensus document will once again be extended to contain the
-  information required by clients.  This information will be a summary
-  of each node's exit policy.  The exit policy summary will only contain
-  the list of ports to which a node exits to most destination IP
-  addresses.
-
-  A summary should claim a router exits to a specific TCP port if,
-  ignoring private IP addresses, the exit policy indicates that the
-  router would exit to this port to most IP address.  either two /8
-  netblocks, or one /8 and a couple of /12s or any other combination).
-  The exact algorith used is this:  Going through all exit policy items
-   - ignore any accept that is not for all IP addresses ("*"),
-   - ignore rejects for these netblocks (exactly, no subnetting):
-     0.0.0.0/8, 169.254.0.0/16, 127.0.0.0/8, 192.168.0.0/16, 10.0.0.0/8,
-     and 172.16.0.0/12m
-   - for each reject count the number of IP addresses rejected against
-     the affected ports,
-   - once we hit an accept for all IP addresses ("*") add the ports in
-     that policy item to the list of accepted ports, if they don't have
-     more than 2^25 IP addresses (that's two /8 networks) counted
-     against them (i.e. if the router exits to a port to everywhere but
-     at most two /8 networks).
-
-  An exit policy summary will be included in votes and consensus as a
-  new line attached to each exit node.  The line will have the format
-   "p" <space> "accept"|"reject" <portlist>
-  where portlist is a comma seperated list of single port numbers or
-  portranges (e.g.  "22,80-88,1024-6000,6667").
-
-  Whether the summary shows the list of accepted ports or the list of
-  rejected ports depends on which list is shorter (has a shorter string
-  representation).  In case of ties we choose the list of accepted
-  ports.  As an exception to this rule an allow-all policy is
-  represented as "accept 1-65535" instead of "reject " and a reject-all
-  policy is similarly given as "reject 1-65535".
-
-  Summary items are compressed, that is instead of "80-88,89-100" there
-  only is a single item of "80-100", similarly instead of "20,21" a
-  summary will say "20-21".
-
-  Port lists are sorted in ascending order.
-
-  The maximum allowed length of a policy summary (including the "accept "
-  or "reject ") is 1000 characters.  If a summary exceeds that length we
-  use an accept-style summary and list as much of the port list as is
-  possible within these 1000 bytes.
-
-3.4.1 Consensus selection
-
-  When building a consensus, authorities have to agree on a digest of
-  the server descriptor to list in the router line for each router.
-  This is documented in dir-spec section 3.4.
-
-  All authorities that listed that agreed upon descriptor digest in
-  their vote should also list the same exit policy summary - or list
-  none at all if the authority has not been upgraded to list that
-  information in their vote.
-
-  If we have votes with matching server descriptor digest of which at
-  least one of them has an exit policy then we differ between two cases:
-   a) all authorities agree (or abstained) on the policy summary, and we
-      use the exit policy summary that they all listed in their vote,
-   b) something went wrong (or some authority is playing foul) and we
-      have different policy summaries.  In that case we pick the one
-      that is most commonly listed in votes with the matching
-      descriptor.  We break ties in favour of the lexigraphically larger
-      vote.
-
-  If none one of the votes with a matching server descriptor digest has
-  an exit policy summary we use the most commonly listed one in all
-  votes, breaking ties like in case b above.
-
-3.4.2 Client behaviour
-
-  When choosing an exit node for a specific request a Tor client will
-  choose from the list of nodes that exit to the requested port as given
-  by the consensus document.  If a client has additional knowledge (like
-  cached full descriptors) that indicates the so chosen exit node will
-  reject the request then it MAY use that knowledge (or not include such
-  nodes in the selection to begin with).  However, clients MUST NOT use
-  nodes that do not list the port as accepted in the summary (but for
-  which they know that the node would exit to that address from other
-  sources, like a cached descriptor).
-
-  An exception to this is exit enclave behaviour: A client MAY use the
-  node at a specific IP address to exit to any port on the same address
-  even if that node is not listed as exiting to the port in the summary.
-
-4. Migration
-
-4.1 Consensus document changes.
-
-  The consensus will need to include
-    - bandwidth information (see 3.1)
-    - exit policy summaries (3.4)
-
-  A new consensus method (number TBD) will be chosen for this.
-
-5. Future possibilities
-
-  This proposal still requires that all servers have the descriptors of
-  every other node in the network in order to answer RELAY_REQUEST_SD
-  cells.  These cells are sent when a circuit is extended from ending at
-  node B to a new node C.  In that case B would have to answer a
-  RELAY_REQUEST_SD cell that asks for C's server descriptor (by SD digest).
-
-  In order to answer that request B obviously needs a copy of C's server
-  descriptor.  The RELAY_REQUEST_SD cell already has all the info that
-  B needs to contact C so it can ask about the descriptor before passing it
-  back to the client.
-
diff --git a/doc/spec/proposals/142-combine-intro-and-rend-points.txt b/doc/spec/proposals/142-combine-intro-and-rend-points.txt
deleted file mode 100644
index 3456b28..0000000
--- a/doc/spec/proposals/142-combine-intro-and-rend-points.txt
+++ /dev/null
@@ -1,279 +0,0 @@
-Filename: 142-combine-intro-and-rend-points.txt
-Title: Combine Introduction and Rendezvous Points
-Version: $Revision$
-Last-Modified: $Date$
-Author: Karsten Loesing, Christian Wilms
-Created: 27-Jun-2008
-Status: Dead
-
-Change history:
-
-  27-Jun-2008  Initial proposal for or-dev
-  04-Jul-2008  Give first security property the new name "Responsibility"
-               and change new cell formats according to rendezvous protocol
-               version 3 draft.
-  19-Jul-2008  Added comment by Nick (but no solution, yet) that sharing of
-               circuits between multiple clients is not supported by Tor.
-
-Overview:
-
-  Establishing a connection to a hidden service currently involves two Tor
-  relays, introduction and rendezvous point, and 10 more relays distributed
-  over four circuits to connect to them. The introduction point is
-  established in the mid-term by a hidden service to transfer introduction
-  requests from client to the hidden service. The rendezvous point is set
-  up by the client for a single hidden service request and actually
-  transfers end-to-end encrypted application data between client and hidden
-  service.
-
-  There are some reasons for separating the two roles of introduction and
-  rendezvous point: (1) Responsibility: A relay shall not be made
-  responsible that it relays data for a certain hidden service; in the
-  original design as described in [1] an introduction point relays no
-  application data, and a rendezvous points neither knows the hidden
-  service nor can it decrypt the data. (2) Scalability: The hidden service
-  shall not have to maintain a number of open circuits proportional to the
-  expected number of client requests. (3) Attack resistance: The effect of
-  an attack on the only visible parts of a hidden service, its introduction
-  points, shall be as small as possible.
-
-  However, elimination of a separate rendezvous connection as proposed by
-  Ã?verlier and Syverson [2] is the most promising approach to improve the
-  delay in connection establishment. From all substeps of connection
-  establishment extending a circuit by only a single hop is responsible for
-  a major part of delay. Reducing on-demand circuit extensions from two to
-  one results in a decrease of mean connection establishment times from 39
-  to 29 seconds [3]. Particularly, eliminating the delay on hidden-service
-  side allows the client to better observe progress of connection
-  establishment, thus allowing it to use smaller timeouts. Proposal 114
-  introduced new introduction keys for introduction points and provides for
-  user authorization data in hidden service descriptors; it will be shown
-  in this proposal that introduction keys in combination with new
-  introduction cookies provide for the first security property
-  responsibility. Further, eliminating the need for a separate introduction
-  connection benefits the overall network load by decreasing the number of
-  circuit extensions. After all, having only one connection between client
-  and hidden service reduces the overall protocol complexity.
-
-Design:
-
-  1. Hidden Service Configuration
-
-  Hidden services should be able to choose whether they would like to use
-  this protocol. This might be opt-in for 0.2.1.x and opt-out for later
-  major releases.
-
-  2. Contact Point Establishment
-
-  When preparing a hidden service, a Tor client selects a set of relays to
-  act as contact points instead of introduction points. The contact point
-  combines both roles of introduction and rendezvous point as proposed in
-  [2]. The only requirement for a relay to be picked as contact point is
-  its capability of performing this role. This can be determined from the
-  Tor version number that needs to be equal or higher than the first
-  version that implements this proposal.
-
-  The easiest way to implement establishment of contact points is to
-  introduce v2 ESTABLISH_INTRO cells. By convention, the relay recognizes
-  version 2 ESTABLISH_INTRO cells as requests to establish a contact point
-  rather than an introduction point.
-
-     V      Format byte: set to 255               [1 octet]
-     V      Version byte: set to 2                [1 octet]
-     KLEN   Key length                           [2 octets]
-     PK     Public introduction key           [KLEN octets]
-     HS     Hash of session info                [20 octets]
-     SIG    Signature of above information       [variable]
-
-  The hidden service does not create a fixed number of contact points, like
-  3 in the current protocol. It uses a minimum of 3 contact points, but
-  increases this number depending on the history of client requests within
-  the last hour. The hidden service also increases this number depending on
-  the frequency of failing contact points in order to defend against
-  attacks on its contact points. When client authorization as described in
-  proposal 121 is used, a hidden service can also use the number of
-  authorized clients as first estimate for the required number of contact
-  points.
-
-  3. Hidden Service Descriptor Creation
-
-  A hidden service needs to issue a fresh introduction cookie for each
-  established introduction point. By requiring clients to use this cookie
-  in a later connection establishment, an introduction point cannot access
-  the hidden service that it works for. Together with the fresh
-  introduction key that was introduced in proposal 114, this reduces
-  responsibility of a contact point for a specific hidden service.
-
-  The v2 hidden service descriptor format contains an
-  "intro-authentication" field that may contain introduction-point specific
-  keys. The hidden service creates a random string, comparable to the
-  rendezvous cookie, and includes it in the descriptor as introduction
-  cookie for auth-type "1". By convention, clients recognize existence of
-  auth-type 1 as possibility to connect to a hidden service via a contact
-  point rather than an introduction point. Older clients that do not
-  understand this new protocol simply ignore that cookie.
-
-  4. Connection Establishment
-
-  When establishing a connection to a hidden service a client learns about
-  the capability of using the new protocol from the hidden service
-  descriptor. It may choose whether to use this new protocol or not,
-  whereas older clients cannot understand the new capability and can only
-  use the current protocol. Client using version 0.2.1.x should be able to
-  opt-in for using the new protocol, which should change to opt-out for
-  later major releases.
-
-  When using the new capability the client creates a v2 INTRODUCE1 cell
-  that extends an unversioned INTRODUCE1 cell by adding the content of an
-  ESTABLISH_RENDEZVOUS cell. Further, the client sends this cell using the
-  new cell type 41 RELAY_INTRODUCE1_VERSIONED to the introduction point,
-  because unversioned and versioned INTRODUCE1 cells are indistinguishable:
-
-  Cleartext
-     V      Version byte: set to 2                [1 octet]
-     PK_ID  Identifier for Bob's PK             [20 octets]
-     RC     Rendezvous cookie                   [20 octets]
-  Encrypted to introduction key:
-     VER    Version byte: set to 3.               [1 octet]
-     AUTHT  The auth type that is supported       [1 octet]
-     AUTHL  Length of auth data                  [2 octets]
-     AUTHD  Auth data                            [variable]
-     RC     Rendezvous cookie                   [20 octets]
-     g^x    Diffie-Hellman data, part 1        [128 octets]
-
-  The cleartext part contains the rendezvous cookie that the contact point
-  remembers just as a rendezvous point would do.
-
-  The encrypted part contains the introduction cookie as auth data for the
-  auth type 1. The rendezvous cookie is contained as before, but there is
-  no further rendezvous point information, as there is no separate
-  rendezvous point.
-
-  5. Rendezvous Establishment
-
-  The contact point recognizes a v2 INTRODUCE1 cell with auth type 1 as a
-  request to be used in the new protocol. It remembers the contained
-  rendezvous cookie, replies to the client with an INTRODUCE_ACK cell
-  (omitting the RENDEZVOUS_ESTABLISHED cell), and forwards the encrypted
-  part of the INTRODUCE1 cell as INTRODUCE2 cell to the hidden service.
-
-  6. Introduction at Hidden Service
-
-  The hidden services recognizes an INTRODUCE2 cell containing an
-  introduction cookie as authorization data. In this case, it does not
-  extend a circuit to a rendezvous point, but sends a RENDEZVOUS1 cell
-  directly back to its contact point as usual.
-
-  7. Rendezvous at Contact Point
-
-  The contact point processes a RENDEZVOUS1 cell just as a rendezvous point
-  does. The only difference is that the hidden-service-side circuit is not
-  exclusive for the client connection, but shared among multiple client
-  connections.
-
-  [Tor does not allow sharing of a single circuit among multiple client
-   connections easily. We need to think about a smart and efficient way to
-   implement this. Comment by Nick. -KL]
-
-Security Implications:
-
-  (1) Responsibility
-
-  One of the original reasons for the separation of introduction and
-  rendezvous points is that a relay shall not be made responsible that it
-  relays data for a certain hidden service. In the current design an
-  introduction point relays no application data and a rendezvous points
-  neither knows the hidden service nor can it decrypt the data.
-
-  This property is also fulfilled in this new design. A contact point only
-  learns a fresh introduction key instead of the hidden service key, so
-  that it cannot recognize a hidden service. Further, the introduction
-  cookie, which is unknown to the contact point, prevents it from accessing
-  the hidden service itself. The only way for a contact point to access a
-  hidden service is to look up whether it is contained in the descriptors
-  of known hidden services. A contact point cannot directly be made
-  responsible for which hidden service it is working. In addition to that,
-  it cannot learn the data that it transfers, because all communication
-  between client and hidden service are end-to-end encrypted.
-
-  (2) Scalability
-
-  Another goal of the existing hidden service protocol is that a hidden
-  service does not have to maintain a number of open circuits proportional
-  to the expected number of client requests. The rationale behind this is
-  better scalability.
-
-  The new protocol eliminates the need for a hidden service to extend
-  circuits on demand, which has a positive effect on circuits establishment
-  times and overall network load. The solution presented here to establish
-  a number of contact points proportional to the history of connection
-  requests reduces the number of circuits to a minimum number that fits the
-  hidden service's needs.
-
-  (3) Attack resistance
-
-  The third goal of separating introduction and rendezvous points is to
-  limit the effect of an attack on the only visible parts of a hidden
-  service which are the contact points in this protocol.
-
-  In theory, the new protocol is more vulnerable to this attack. An
-  attacker who can take down a contact point does not only eliminate an
-  access point to the hidden service, but also breaks current client
-  connections to the hidden service using that contact point.
-
-  Ã?verlier and Syverson proposed the concept of valet nodes as additional
-  safeguard for introduction/contact points [4]. Unfortunately, this
-  increases hidden service protocol complexity conceptually and from an
-  implementation point of view. Therefore, it is not included in this
-  proposal.
-
-  However, in practice attacking a contact point (or introduction point) is
-  not as rewarding as it might appear. The cost for a hidden service to set
-  up a new contact point and publish a new hidden service descriptor is
-  minimal compared to the efforts necessary for an attacker to take a Tor
-  relay down. As a countermeasure to further frustrate this attack, the
-  hidden service raises the number of contact points as a function of
-  previous contact point failures.
-
-  Further, the probability of breaking client connections due to attacking
-  a contact point is minimal. It can be assumed that the probability of one
-  of the other five involved relays in a hidden service connection failing
-  or being shut down is higher than that of a successful attack on a
-  contact point.
-
-  (4) Resistance against Locating Attacks
-
-  Clients are no longer able to force a hidden service to create or extend
-  circuits. This further reduces an attacker's capabilities of locating a
-  hidden server as described by Ã?verlier and Syverson [5].
-
-Compatibility:
-
-  The presented protocol does not raise compatibility issues with current
-  Tor versions. New relay versions support both, the existing and the
-  proposed protocol as introduction/rendezvous/contact points. A contact
-  point acts as introduction point simultaneously. Hidden services and
-  clients can opt-in to use the new protocol which might change to opt-out
-  some time in the future.
-
-References:
-
-  [1] Roger Dingledine, Nick Mathewson, and Paul Syverson, Tor: The
-  Second-Generation Onion Router. In the Proceedings of the 13th USENIX
-  Security Symposium, August 2004.
-
-  [2] Lasse Ã?verlier and Paul Syverson, Improving Efficiency and Simplicity
-  of Tor Circuit Establishment and Hidden Services. In the Proceedings of
-  the Seventh Workshop on Privacy Enhancing Technologies (PET 2007),
-  Ottawa, Canada, June 2007.
-
-  [3] Christian Wilms, Improving the Tor Hidden Service Protocol Aiming at
-  Better Performance, diploma thesis, June 2008, University of Bamberg.
-
-  [4] Lasse Ã?verlier and Paul Syverson, Valet Services: Improving Hidden
-  Servers with a Personal Touch. In the Proceedings of the Sixth Workshop
-  on Privacy Enhancing Technologies (PET 2006), Cambridge, UK, June 2006.
-
-  [5] Lasse Ã?verlier and Paul Syverson, Locating Hidden Servers. In the
-  Proceedings of the 2006 IEEE Symposium on Security and Privacy, May 2006.
-
diff --git a/doc/spec/proposals/143-distributed-storage-improvements.txt b/doc/spec/proposals/143-distributed-storage-improvements.txt
deleted file mode 100644
index 8789d84..0000000
--- a/doc/spec/proposals/143-distributed-storage-improvements.txt
+++ /dev/null
@@ -1,196 +0,0 @@
-Filename: 143-distributed-storage-improvements.txt
-Title: Improvements of Distributed Storage for Tor Hidden Service Descriptors
-Version: $Revision$
-Last-Modified: $Date$
-Author: Karsten Loesing
-Created: 28-Jun-2008
-Status: Open
-Target: 0.2.1.x
-
-Change history:
-
-  28-Jun-2008  Initial proposal for or-dev
-
-Overview:
-
-  An evaluation of the distributed storage for Tor hidden service
-  descriptors and subsequent discussions have brought up a few improvements
-  to proposal 114. All improvements are backwards compatible to the
-  implementation of proposal 114.
-
-Design:
-
-  1. Report Bad Directory Nodes
-
-  Bad hidden service directory nodes could deny existence of previously
-  stored descriptors. A bad directory node that does this with all stored
-  descriptors causes harm to the distributed storage in general, but
-  replication will cope with this problem in most cases. However, an
-  adversary that attempts to make a specific hidden service unavailable by
-  running relays that become responsible for all of a service's
-  descriptors poses a more serious threat. The distributed storage needs to
-  defend against this attack by detecting and removing bad directory nodes.
-
-  As a countermeasure hidden services try to download their descriptors
-  every hour at random times from the hidden service directories that are
-  responsible for storing it. If a directory node replies with 404 (Not
-  found), the hidden service reports the supposedly bad directory node to
-  a random selection of half of the directory authorities (with version
-  numbers equal to or higher than the first version that implements this
-  proposal). The hidden service posts a complaint message using HTTP 'POST'
-  to a URL "/tor/rendezvous/complain" with the following message format:
-
-    "hidden-service-directory-complaint" identifier NL
-
-      [At start, exactly once]
-
-      The identifier of the hidden service directory node to be
-      investigated.
-
-    "rendezvous-service-descriptor" descriptor NL
-
-      [At end, Excatly once]
-
-      The hidden service descriptor that the supposedly bad directory node
-      does not serve.
-
-  The directory authority checks if the descriptor is valid and the hidden
-  service directory responsible for storing it. It waits for a random time
-  of up to 30 minutes before posting the descriptor to the hidden service
-  directory. If the publication is acknowledged, the directory authority
-  waits another random time of up to 30 minutes before attempting to
-  request the descriptor that it has posted. If the directory node replies
-  with 404 (Not found), it will be blacklisted for being a hidden service
-  directory node for the next 48 hours.
-
-  A blacklisted hidden service directory is assigned the new flag BadHSDir
-  instead of the HSDir flag in the vote that a directory authority creates.
-  In a consensus a relay is only assigned a HSDir flag if the majority of
-  votes contains a HSDir flag and no more than one third of votes contains
-  a BadHSDir flag. As a result, clients do not have to learn about the
-  BadHSDir flag. A blacklisted directory node will simply not be assigned
-  the HSDir flag in the consensus.
-
-  In order to prevent an attacker from setting up new nodes as replacement
-  for blacklisted directory nodes, all directory nodes in the same /24
-  subnet are blacklisted, too. Furthermore, if two or more directory nodes
-  are blacklisted in the same /16 subnet concurrently, all other directory
-  nodes in that /16 subnet are blacklisted, too. Blacklisting holds for at
-  most 48 hours.
-
-  2. Publish Fewer Replicas
-
-  The evaluation has shown that the probability of a directory node to
-  serve a previously stored descriptor is 85.7% (more precisely, this is
-  the 0.001-quantile of the empirical distribution with the rationale that
-  it holds for 99.9% of all empirical cases). If descriptors are replicated
-  to x directory nodes, the probability of at least one of the replicas to
-  be available for clients is 1 - (1 - 85.7%) ^ x. In order to achieve an
-  overall availability of 99.9%, x = 3.55 replicas need to be stored. From
-  this follows that 4 replicas are sufficient, rather than the currently
-  stored 6 replicas.
-
-  Further, the current design stores 2 sets of descriptors on 3 directory
-  nodes with consecutive identities. Originally, this was meant to
-  facilitate replication between directory nodes, which has not been and
-  will not be implemented (the selection criterion of 24 hours uptime does
-  not make it necessary). As a result, storing descriptors on directory
-  nodes with consecutive identities is not required. In fact it should be
-  avoided to enable an attacker to create "black holes" in the identifier
-  ring.
-
-  Hidden services should store their descriptors on 4 non-consecutive
-  directory nodes, and clients should request descriptors from these
-  directory nodes only. For compatibility reasons, hidden services also
-  store their descriptors on 2 consecutive directory nodes. Hence, 0.2.0.x
-  clients will be able to retrieve 4 out of 6 descriptors, but will fail
-  for the remaining 2 descriptors, which is sufficient for reliability. As
-  soon as 0.2.0.x is deprecated, hidden services can stop publishing the
-  additional 2 replicas.
-
-  3. Change Default Value of Being Hidden Service Directory
-
-  The requirements for becoming a hidden service directory node are an open
-  directory port and an uptime of at least 24 hours. The evaluation has
-  shown that there are 300 hidden service directory candidates in the mean,
-  but only 6 of them are configured to act as hidden service directories.
-  This is bad, because those 6 nodes need to serve a large share of all
-  hidden service descriptors. Optimally, there should be hundreds of hidden
-  service directories. Having a large number of 0.2.1.x directory nodes
-  also has a positive effect on 0.2.0.x hidden services and clients.
-
-  Therefore, the new default of HidServDirectoryV2 should be 1, so that a
-  Tor relay that has an open directory port automatically accepts and
-  serves v2 hidden service descriptors. A relay operator can still opt-out
-  running a hidden service directory by changing HidServDirectoryV2 to 0.
-  The additional bandwidth requirements for running a hidden service
-  directory node in addition to being a directory cache are negligible.
-
-  4. Make Descriptors Persistent on Directory Nodes
-
-  Hidden service directories that are restarted by their operators or after
-  a failure will not be selected as hidden service directories within the
-  next 24 hours. However, some clients might still think that these nodes
-  are responsible for certain descriptors, because they work on the basis
-  of network consensuses that are up to three hours old. The directory
-  nodes should be able to serve the previously received descriptors to
-  these clients. Therefore, directory nodes make all received descriptors
-  persistent and load previously received descriptors on startup.
-
-  5. Store and Serve Descriptors Regardless of Responsibility
-
-  Currently, directory nodes only accept descriptors for which they think
-  they are responsible. This may lead to problems when a directory node
-  uses an older or newer network consensus than hidden service or client
-  or when a directory node has been restarted recently. In fact, there are
-  no security issues in storing or serving descriptors for which a
-  directory node thinks it is not responsible. To the contrary, doing so
-  may improve reliability in border cases. As a result, a directory node
-  does not pay attention to responsibilty when receiving a publication or
-  fetch request, but stores or serves the requested descriptor. Likewise,
-  the directory node does not remove descriptors when it thinks it is not
-  responsible for them any more.
-
-  6. Avoid Periodic Descriptor Re-Publication
-
-  In the current implementation a hidden service re-publishes its
-  descriptor either when its content changes or an hour elapses. However,
-  the evaluation has shown that failures of hidden service directory nodes,
-  i.e. of nodes that have not failed within the last 24 hours, are very
-  rare. Together with making descriptors persistent on directory nodes,
-  there is no necessity to re-publish descriptors hourly.
-
-  The only two events leading to descriptor re-publication should be a
-  change of the descriptor content and a new directory node becoming
-  responsible for the descriptor. Hidden services should therefore consider
-  re-publication every time they learn about a new network consensus
-  instead of hourly.
-
-  7. Discard Expired Descriptors
-
-  The current implementation lets directory nodes keep a descriptor for two
-  days before discarding it. However, with the v2 design, descriptors are
-  only valid for at most one day. Directory nodes should determine the
-  validity of stored descriptors and discard them one hour after they have
-  expired (to compensate wrong clocks on clients).
-
-  8. Shorten Client-Side Descriptor Fetch History
-
-  When clients try to download a hidden service descriptor, they memorize
-  fetch requests to directory nodes for up to 15 minutes. This allows them
-  to request all replicas of a descriptor to avoid bad or failing directory
-  nodes, but without querying the same directory node twice.
-
-  The downside is that a client that has requested a descriptor without
-  success, will not be able to find a hidden service that has been started
-  during the following 15 minutes after the client's last request.
-
-  This can be improved by shortening the fetch history to only 5 minutes.
-  This time should be sufficient to complete requests for all replicas of a
-  descriptor, but without ending in an infinite request loop.
-
-Compatibility:
-
-  All proposed improvements are compatible to the currently implemented
-  design as described in proposal 114.
-
diff --git a/doc/spec/proposals/144-enforce-distinct-providers.txt b/doc/spec/proposals/144-enforce-distinct-providers.txt
deleted file mode 100644
index aa46048..0000000
--- a/doc/spec/proposals/144-enforce-distinct-providers.txt
+++ /dev/null
@@ -1,165 +0,0 @@
-Filename: 144-enforce-distinct-providers.txt
-Title: Increase the diversity of circuits by detecting nodes belonging the
-   same provider
-Author: Mfr
-Created: 2008-06-15
-Status: Draft
-
-Overview:
-
-  Increase network security by reducing the capacity of the relay or
-  ISPs monitoring personally or requisition, a large part of traffic
-  Tor trying to break circuits privacy.  A way to increase the
-  diversity of circuits without killing the network performance.
-
-Motivation:
-
-  Since 2004, Roger an Nick publication about diversity [1], very fast
-  relays Tor running are focused among an half dozen of providers,
-  controlling traffic of some dozens of routers [2].
-
-  In the same way the generalization of VMs clonables paid by hour,
-  allowing starting in few minutes and for a small cost, a set of very
-  high-speed relay whose in a few hours can attract a big traffic that
-  can be analyzed, increasing the vulnerability of the network.
-
-  Whether ISPs or domU providers, these usually have several groups of
-  IP Class B.  Also the restriction in place EnforceDistinctSubnets
-  automatically excluding IP subnet class B is only partially
-  effective. By contrast a restriction at the class A will be too
-  restrictive.
-
- Therefore it seems necessary to consider another approach.
-
-Proposal:
-
-  Add a provider control based on AS number added by the router on is
-  descriptor, controlled by Directories Authorities, and used like the
-  declarative family field for circuit creating.
-
-Design:
-
-Step 1 :
-
- Add to the router descriptor a provider information get request [4]
-  by the router itself.
-
-         "provider" name NL
-
-            'names' is the AS number of the router formated like this:
-            'ASxxxxxx' where AS is fixed and xxxxxx is the AS number,
-            left aligned ( ex: AS98304 , AS4096,AS1 ) or if AS number
-            is missing the network A class number is used like that:
-            'ANxxx' where AN is fixed and xxx is the first 3 digits of
-            the IP (ex: for the IP 1.1.1.2 AN1) or an 'L' value is set
-            if it's a local network IP.
-
-            If two ORs list one another in their "provider" entries,
-            then OPs should treat them as a single OR for the purpose
-            of path selection.
-
-            For example, if node A's descriptor contains "provider B",
-            and node B's descriptor contains "provider A", then node A
-            and node B should never be used on the same circuit.
-
-    Add the regarding config option in torrc
-
-            EnforceDistinctProviders set to 1 by default.
-            Permit building circuits with relays in the same provider
-            if set to 0.
-            Regarding to proposal 135 if TestingTorNetwork is set
-            need to be EnforceDistinctProviders is unset.
-
-    Control by Authorities Directories of the AS numbers
-
-         The Directories Authority control the AS numbers of the new node
-         descriptor uploaded.
-
-            If an old version is operated by the node this test is
-            bypassed.
-
-            If AS number get by request is different from the
-            description, router is flagged as non-Valid by the testing
-            Authority for the voting process.
-
-Step 2     When a ' significant number of nodes' of valid routers are
-generating descriptor with provider information.
-
-        Add missing provider information get by DNS request
-functionality for the circuit user:
-
-                During circuit building, computing, OP apply first
-                family check and EnforceDistinctSubnets directives for
-                performance, then if provider info is needed and
-                missing in router descriptor try to get AS provider
-                info by DNS request [4].  This information could be
-                DNS cached.  AN ( class A number) is never generated
-                during this process to prevent DNS block problems.  If
-                DNS request fails ignore and continue building
-                circuit.
-
-Step 3 When the 'whole majority' of valid Tor clients are providing
-DNS request.
-
-        Older versions are deprecated and mark as no-Valid.
-
-  EnforceDistinctProviders replace EnforceDistinctSubnets functionnality.
-
-        EnforceDistinctSubnets is removed.
-
-        Functionalities deployed in step 2 are removed.
-
-Security implications:
-
-      This providermeasure will increase the number of providers
-      addresses that an attacker must use in order to carry out
-      traffic analysis.
-
-Compatibility:
-
-        The presented protocol does not raise compatibility issues
-        with current Tor versions. The compatibility is preserved by
-        implementing this functionality in 3 steps, giving time to
-        network users to upgrade clients and routers.
-
-Performance and scalability notes:
-
-        Provider change for all routers could reduce a little
-        performance if the circuit to long.
-
-        During step 2 Get missing provider information could increase
-        building path time and should have a time out.
-
-Possible Attacks/Open Issues/Some thinking required:
-
-        These proposal seems be compatible with proposal 135 Simplify
-        Configuration of Private Tor Networks.
-
-        This proposal does not resolve multiples AS owners and top
-        providers traffic monitoring attacks [5].
-
-        Unresolved AS number are treated as a Class A network. Perhaps
-        should be marked as invalid.  But there's only fives items on
-        last check see [2].
-
-        Need to define what's a 'significant number of nodes' and
-        'whole majority' ;-)
-
-References:
-[1] Location Diversity in Anonymity Networks by Nick Feamster and Roger
-Dingledine.
-In the Proceedings of the Workshop on Privacy in the Electronic Society
-(WPES 2004), Washington, DC, USA, October 2004
-http://freehaven.net/anonbib/#feamster:wpes2004
-[2] http://as4jtw5gc6efb267.onion/IPListbyAS.txt
-[3] see Goodell Tor Exit Page
-http://cassandra.eecs.harvard.edu/cgi-bin/exit.py
-[4] see the great IP to ASN DNS Tool
-http://www.team-cymru.org/Services/ip-to-asn.html
-[5] Sampled Traffic Analysis by Internet-Exchange-Level Adversaries by
-Steven J. Murdoch and Piotr Zielinski.
-In the Proceedings of the Seventh Workshop on Privacy Enhancing Technologies
-
-(PET 2007), Ottawa, Canada, June 2007.
-http://freehaven.net/anonbib/#murdoch-pet2007
-[5] http://bugs.noreply.org/flyspray/index.php?do=details&id=690
diff --git a/doc/spec/proposals/145-newguard-flag.txt b/doc/spec/proposals/145-newguard-flag.txt
deleted file mode 100644
index 31d707d..0000000
--- a/doc/spec/proposals/145-newguard-flag.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-Filename: 145-newguard-flag.txt
-Title: Separate "suitable as a guard" from "suitable as a new guard"
-Version: $Revision$
-Last-Modified: $Date$
-Author: Nick Mathewson
-Created: 1-Jul-2008
-Status: Open
-Target: 0.2.1.x
-
-[This could be obsoleted by proposal 141, which could replace NewGuard
-with a Guard weight.]
-
-Overview
-
-   Right now, Tor has one flag that clients use both to tell which
-   nodes should be kept as guards, and which nodes should be picked
-   when choosing new guards.  This proposal separates this flag into
-   two.
-
-Motivation
-
-   Balancing clients amoung guards is not done well by our current
-   algorithm.  When a new guard appears, it is chosen by clients
-   looking for a new guard with the same probability as all existing
-   guards... but new guards are likelier to be under capacity, whereas
-   old guards are likelier to be under more use.
-
-Implementation
-
-   We add a new flag, NewGuard.  Clients will change so that when they
-   are choosing new guards, they only consider nodes with the NewGuard
-   flag set.
-
-   For now, authorities will always set NewGuard if they are setting
-   the Guard flag.  Later, it will be easy to migrate authorities to
-   set NewGuard for underused guards.
-
-Alternatives
-
-   We might instead have authorities list weights with which nodes
-   should be picked as guards.
diff --git a/doc/spec/proposals/146-long-term-stability.txt b/doc/spec/proposals/146-long-term-stability.txt
deleted file mode 100644
index 7cfd58f..0000000
--- a/doc/spec/proposals/146-long-term-stability.txt
+++ /dev/null
@@ -1,86 +0,0 @@
-Filename: 146-long-term-stability.txt
-Title: Add new flag to reflect long-term stability
-Version: $Revision$
-Last-Modified: $Date$
-Author: Nick Mathewson
-Created: 19-Jun-2008
-Status: Open
-Target: 0.2.1.x
-
-Overview
-
-  This document proposes a new flag to indicate that a router has
-  existed at the same address for a long time, describes how to
-  implement it, and explains what it's good for.
-
-Motivation
-
-  Tor has had three notions of "stability" for servers.  Older
-  directory protocols based a server's stability on its
-  (self-reported) uptime: a server that had been running for a day was
-  more stable than a server that had been running for five minutes,
-  regardless of their past history.  Current directory protocols track
-  weighted mean time between failure (WMTBF) and weighted fractional
-  uptime (WFU).  WFU is computed as the fraction of time for which the
-  server is running, with measurements weighted to exponentially
-  decay such that old days count less.  WMTBF is computed as the
-  average length of intervals for which the server runs between
-  downtime, with old intervals weighted to count less.
-
-  WMTBF is useful in answering the question: "If a server is running
-  now, how long is it likely to stay running?"  This makes it a good
-  choice for picking servers for streams that need to be long-lived.
-  WFU is useful in answering the question: "If I try connecting to
-  this server at an arbitrary time, is it likely to be running?"  This
-  makes it an important factor for picking guard nodes, since we want
-  guard nodes to be usually-up.
-
-  There are other questions that clients want to answer, however, for
-  which the current flags aren't very useful.   The one that this
-  proposal addresses is,
-
-       "If I found this server in an old consensus, is it likely to
-       still be running at the same address?"
-
-  This one is useful when we're trying to find directory mirrors in a
-  fallback-consensus file.  This property is equivalent to,
-
-       "If I find this server in a current consensus, how long is it
-       likely to exist on the network?"
-
-  This one is useful if we're trying to pick introduction points or
-  something and care more about churn rate than about whether every IP
-  will be up all the time.
-
-Implementation:
-
-  I propose we add a new flag, called "Longterm."  Authorities should
-  set this flag for routers if their Longevity is in the upper
-  quartile of all routers.  A router's Longevity is computed as the
-  total amount of days in the last year or so[*] for which the router has
-  been Running at least once at its current IP:orport pair.
-
-  Clients should use directory servers from a fallback-consensus only
-  if they have the Longterm flag set.
-
-  Authority ops should be able to mark particular routers as not
-  Longterm, regardless of history.  (For instance, it makes sense to
-  remove the Longterm flag from a router whose op says that it will
-  need to shutdown in a month.)
-
-  [*] This is deliberately vague, to permit efficient implementations.
-
-Compatibility and migration issues:
-
-  The voting protocol already acts gracefully when new flags are
-  added, so no change to the voting protocol is needed.
-
-  Tor won't have collected this data, however.  It might be desirable
-  to bootstrap it from historical consensuses.  Alternatively, we can
-  just let the algorithm run for a month or two.
-
-Issues and future possibilities:
-
-  Longterm is a really awkward name.
-
-
diff --git a/doc/spec/proposals/147-prevoting-opinions.txt b/doc/spec/proposals/147-prevoting-opinions.txt
deleted file mode 100644
index 2b8cf30..0000000
--- a/doc/spec/proposals/147-prevoting-opinions.txt
+++ /dev/null
@@ -1,60 +0,0 @@
-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: Accepted
-Target: 0.2.1.x
-
-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 generate opinions earlier than they generate 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.
-
-  Additionally, authories make their opinions available at
-     http://<hostname>/tor/status-vote/next/opinion.z
-  and download opinions from authorities they haven't heard from in a
-  while.
-
-  Authorities MAY generate opinions on demand.
-
-  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.
-
diff --git a/doc/spec/proposals/148-uniform-client-end-reason.txt b/doc/spec/proposals/148-uniform-client-end-reason.txt
deleted file mode 100644
index cec8125..0000000
--- a/doc/spec/proposals/148-uniform-client-end-reason.txt
+++ /dev/null
@@ -1,59 +0,0 @@
-Filename: 148-uniform-client-end-reason.txt
-Title: Stream end reasons from the client side should be uniform
-Version: $Revision$
-Last-Modified: $Date$
-Author: Roger Dingledine
-Created: 2-Jul-2008
-Status: Closed
-Implemented-In: 0.2.1.9-alpha
-
-Overview
-
-  When a stream closes before it's finished, the end relay cell that's
-  sent includes an "end stream reason" to tell the other end why it
-  closed. It's useful for the exit relay to send a reason to the client,
-  so the client can choose a different circuit, inform the user, etc. But
-  there's no reason to include it from the client to the exit relay,
-  and in some cases it can even harm anonymity.
-
-  We should pick a single reason for the client-to-exit-relay direction
-  and always just send that.
-
-Motivation
-
-  Back when I first deployed the Tor network, it was useful to have
-  the Tor relays learn why a stream closed, so I could debug both ends
-  of the stream at once. Now that streams have worked for many years,
-  there's no need to continue telling the exit relay whether the client
-  gave up on a stream because of "timeout" or "misc" or what.
-
-  Then in Tor 0.2.0.28-rc, I fixed this bug:
-    - Fix a bug where, when we were choosing the 'end stream reason' to
-      put in our relay end cell that we send to the exit relay, Tor
-      clients on Windows were sometimes sending the wrong 'reason'. The
-      anonymity problem is that exit relays may be able to guess whether
-      the client is running Windows, thus helping partition the anonymity
-      set. Down the road we should stop sending reasons to exit relays,
-      or otherwise prevent future versions of this bug.
-
-  It turned out that non-Windows clients were choosing their reason
-  correctly, whereas Windows clients were potentially looking at errno
-  wrong and so always choosing 'misc'.
-
-  I fixed that particular bug, but I think we should prevent future
-  versions of the bug too.
-
-  (We already fixed it so *circuit* end reasons don't get sent from
-  the client to the exit relay. But we appear to be have skipped over
-  stream end reasons thus far.)
-
-Design:
-
-  One option would be to no longer include any 'reason' field in end
-  relay cells. But that would introduce a partitioning attack ("users
-  running the old version" vs "users running the new version").
-
-  Instead I suggest that clients all switch to sending the "misc" reason,
-  like most of the Windows clients currently do and like the non-Windows
-  clients already do sometimes.
-
diff --git a/doc/spec/proposals/149-using-netinfo-data.txt b/doc/spec/proposals/149-using-netinfo-data.txt
deleted file mode 100644
index 4919514..0000000
--- a/doc/spec/proposals/149-using-netinfo-data.txt
+++ /dev/null
@@ -1,44 +0,0 @@
-Filename: 149-using-netinfo-data.txt
-Title: Using data from NETINFO cells
-Version: $Revision$
-Last-Modified: $Date$
-Author: Nick Mathewson
-Created: 2-Jul-2008
-Status: Open
-Target: 0.2.1.x
-
-Overview
-
-   Current Tor versions send signed IP and timestamp information in
-   NETINFO cells, but don't use them to their fullest.  This proposal
-   describes how they should start using this info in 0.2.1.x.
-
-Motivation
-
-   Our directory system relies on clients and routers having
-   reasonably accurate clocks to detect replayed directory info, and
-   to set accurate timestamps on directory info they publish
-   themselves.  NETINFO cells contain timestamps.
-
-   Also, the directory system relies on routers having a reasonable
-   idea of their own IP addresses, so they can publish correct
-   descriptors.  This is also in NETINFO cells.
-
-Learning the time and IP
-
-   We need to think about attackers here.  Just because a router tells
-   us that we have a given IP or a given clock skew doesn't mean that
-   it's true.  We believe this information only if we've heard it from
-   a majority of the routers we've connected to recently, including at
-   least 3 routers.  Routers only believe this information if the
-   majority inclues at least one authority.
-
-Avoiding MITM attacks
-
-   Current Tors use the IP addresses published in the other router's
-   NETINFO cells to see whether the connection is "canonical".  Right
-   now, we prefer to extend circuits over "canonical" connections.  In
-   0.2.1.x, we should refuse to extend circuits over non-canonical
-   connections without first trying to build a canonical one.
-
-
diff --git a/doc/spec/proposals/150-exclude-exit-nodes.txt b/doc/spec/proposals/150-exclude-exit-nodes.txt
deleted file mode 100644
index b73a9cc..0000000
--- a/doc/spec/proposals/150-exclude-exit-nodes.txt
+++ /dev/null
@@ -1,48 +0,0 @@
-Filename: 150-exclude-exit-nodes.txt
-Title: Exclude Exit Nodes from a circuit
-Version: $Revision$
-Author: Mfr
-Created: 2008-06-15
-Status: Closed
-Implemented-In: 0.2.1.3-alpha
-
-Overview
-
-   Right now, Tor users can manually exclude a node from all positions
-   in their circuits created using the directive ExcludeNodes.
-   This proposal makes this exclusion less restrictive, allowing users to
-   exclude a node only from the exit part of a circuit.
-
-Motivation
-
-   This feature would Help the integration into vidalia (tor exit
-   branch) or other tools, of features to exclude a country for exit
-   without reducing circuits possibilities, and privacy.  This feature
-   could help people from a country were many sites are blocked to
-   exclude this country for browsing, giving them a more stable
-   navigation.  It could also add the possibility for the user to
-   exclude a currently used exit node.
-
-Implementation
-
-   ExcludeExitNodes is similar to ExcludeNodes except it's only
-   the exit node which is excluded for circuit build.
-
-   Tor doesn't warn if node from this list is not an exit node.
-
-Security implications:
-
-   Open also possibilities for a future user bad exit reporting
-
-Risks:
-
-   Use of this option can make users partitionable under certain attack
-   assumptions.  However, ExitNodes already creates this possibility,
-   so there isn't much increased risk in ExcludeExitNodes.
-
-   We should still encourage people who exclude an exit node because
-   of bad behavior to report it instead of just adding it to their
-   ExcludeExit list.  It would be unfortunate if we didn't find out
-   about broken exits because of this option.  This issue can probably
-   be addressed sufficiently with documentation.
-
diff --git a/doc/spec/proposals/151-path-selection-improvements.txt b/doc/spec/proposals/151-path-selection-improvements.txt
deleted file mode 100644
index e3c8f35..0000000
--- a/doc/spec/proposals/151-path-selection-improvements.txt
+++ /dev/null
@@ -1,147 +0,0 @@
-Filename: 151-path-selection-improvements.txt
-Title: Improving Tor Path Selection
-Version:
-Last-Modified:
-Author: Fallon Chen, Mike Perry
-Created: 5-Jul-2008
-Status: Draft
-
-Overview
-
-  The performance of paths selected can be improved by adjusting the
-  CircuitBuildTimeout and avoiding failing guard nodes. This proposal
-  describes a method of tracking buildtime statistics at the client, and 
-  using those statistics to adjust the CircuitBuildTimeout.
-
-Motivation
-
-  Tor's performance can be improved by excluding those circuits that
-  have long buildtimes (and by extension, high latency). For those Tor
-  users who require better performance and have lower requirements for
-  anonymity, this would be a very useful option to have.
-
-Implementation
-
-  Storing Build Times
-
-    Circuit build times will be stored in the circular array
-    'circuit_build_times' consisting of uint16_t elements as milliseconds.
-    The total size of this array will be based on the number of circuits
-    it takes to converge on a good fit of the long term distribution of
-    the circuit builds for a fixed link. We do not want this value to be
-    too large, because it will make it difficult for clients to adapt to
-    moving between different links.
-
-    From our initial observations, this value appears to be on the order 
-    of 1000, but will be configurable in a #define NCIRCUITS_TO_OBSERVE.
-    The exact value for this #define will be determined by performing
-    goodness of fit tests using measurments obtained from the shufflebt.py
-    script from TorFlow.
- 
-  Long Term Storage
-
-    The long-term storage representation will be implemented by storing a 
-    histogram with BUILDTIME_BIN_WIDTH millisecond buckets (default 50) when 
-    writing out the statistics to disk. The format of this histogram on disk 
-    is yet to be finalized, but it will likely be of the format 
-    'CircuitBuildTime <bin> <count>', with the total specified as 
-    'TotalBuildTimes <total>'
-    Example:
-
-    TotalBuildTimes 100
-    CircuitBuildTimeBin 1 50
-    CircuitBuildTimeBin 2 25
-    CircuitBuildTimeBin 3 13
-    ...
-
-    Reading the histogram in will entail multiplying each bin by the 
-    BUILDTIME_BIN_WIDTH and then inserting <count> values into the 
-    circuit_build_times array each with the value of
-    <bin>*BUILDTIME_BIN_WIDTH. In order to evenly distribute the 
-    values in the circular array, a form of index skipping must
-    be employed. Values from bin #N with bin count C and total T
-    will occupy indexes specified by N+((T/C)*k)-1, where k is the
-    set of integers ranging from 0 to C-1.
-
-    For example, this would mean that the values from bin 1 would
-    occupy indexes 1+(100/50)*k-1, or 0, 2, 4, 6, 8, 10 and so on.
-    The values for bin 2 would occupy positions 1, 5, 9, 13. Collisions
-    will be inserted at the first empty position in the array greater 
-    than the selected index (which may requiring looping around the 
-    array back to index 0).
-
-  Learning the CircuitBuildTimeout
-
-    Based on studies of build times, we found that the distribution of
-    circuit buildtimes appears to be a Pareto distribution. 
-
-    We will calculate the parameters for a Pareto distribution
-    fitting the data using the estimators at
-    http://en.wikipedia.org/wiki/Pareto_distribution#Parameter_estimation.
-
-    The timeout itself will be calculated by solving the CDF for the 
-    a percentile cutoff BUILDTIME_PERCENT_CUTOFF. This value
-    represents the percentage of paths the Tor client will accept out of
-    the total number of paths. We have not yet determined a good
-    cutoff for this mathematically, but 85% seems a good choice for now.
-
-    From http://en.wikipedia.org/wiki/Pareto_distribution#Definition,
-    the calculation we need is pow(BUILDTIME_PERCENT_CUTOFF/100.0, k)/Xm. 
-
-  Testing
-
-    After circuit build times, storage, and learning are implemented,
-    the resulting histogram should be checked for consistency by
-    verifying it persists across successive Tor invocations where 
-    no circuits are built. In addition, we can also use the existing
-    buildtime scripts to record build times, and verify that the histogram 
-    the python produces matches that which is output to the state file in Tor,
-    and verify that the Pareto parameters and cutoff points also match.
-  
-  Soft timeout vs Hard Timeout
-   
-    At some point, it may be desirable to change the cutoff from a 
-    single hard cutoff that destroys the circuit to a soft cutoff and
-    a hard cutoff, where the soft cutoff merely triggers the building
-    of a new circuit, and the hard cutoff triggers destruction of the 
-    circuit.
-
-    Good values for hard and soft cutoffs seem to be 85% and 65% 
-    respectively, but we should eventually justify this with observation.
-
-  When to Begin Calculation
-
-    The number of circuits to observe (NCIRCUITS_TO_CUTOFF) before 
-    changing the CircuitBuildTimeout will be tunable via a #define. From 
-    our measurements, a good value for NCIRCUITS_TO_CUTOFF appears to be 
-    on the order of 100.
-
-  Dealing with Timeouts
-
-    Timeouts should be counted as the expectation of the region of 
-    of the Pareto distribution beyond the cutoff. The proposal will
-    be updated with this value soon.
-
-    Also, in the event of network failure, the observation mechanism 
-    should stop collecting timeout data.
-
-  Client Hints
-
-    Some research still needs to be done to provide initial values
-    for CircuitBuildTimeout based on values learned from modem
-    users, DSL users, Cable Modem users, and dedicated links. A 
-    radiobutton in Vidalia should eventually be provided that
-    sets CircuitBuildTimeout to one of these values and also 
-    provide the option of purging all learned data, should any exist.
-
-    These values can either be published in the directory, or
-    shipped hardcoded for a particular Tor version.
-    
-Issues
-
-  Impact on anonymity
-
-    Since this follows a Pareto distribution, large reductions on the
-    timeout can be achieved without cutting off a great number of the
-    total paths. This will eliminate a great deal of the performance
-    variation of Tor usage.
diff --git a/doc/spec/proposals/152-single-hop-circuits.txt b/doc/spec/proposals/152-single-hop-circuits.txt
deleted file mode 100644
index e49a425..0000000
--- a/doc/spec/proposals/152-single-hop-circuits.txt
+++ /dev/null
@@ -1,64 +0,0 @@
-Filename: 152-single-hop-circuits.txt
-Title: Optionally allow exit from single-hop circuits 
-Version:
-Last-Modified:
-Author: Geoff Goodell
-Created: 13-Jul-2008
-Status: Closed
-Implemented-In: 0.2.1.6-alpha
-
-Overview
-
-    Provide a special configuration option that adds a line to descriptors
-    indicating that a router can be used as an exit for one-hop circuits,
-    and allow clients to attach streams to one-hop circuits provided
-    that the descriptor for the router in the circuit includes this
-    configuration option.
-
-Motivation
-
-    At some point, code was added to restrict the attachment of streams
-    to one-hop circuits.
-
-    The idea seems to be that we can use the cost of forking and
-    maintaining a patch as a lever to prevent people from writing
-    controllers that jeopardize the operational security of routers
-    and the anonymity properties of the Tor network by creating and
-    using one-hop circuits rather than the standard three-hop circuits.
-    It may be, for example, that some users do not actually seek true
-    anonymity but simply reachability through network perspectives
-    afforded by the Tor network, and since anonymity is stronger in
-    numbers, forcing users to contribute to anonymity and decrease the
-    risk to server operators by using full-length paths may be reasonable.
-
-    As presently implemented, the sweeping restriction of one-hop circuits
-    for all routers limits the usefulness of Tor as a general-purpose
-    technology for building circuits.  In particular, we should allow
-    for controllers, such as Blossom, that create and use single-hop
-    circuits involving routers that are not part of the Tor network.
-
-Design
-
-    Introduce a configuration option for Tor servers that, when set,
-    indicates that a router is willing to provide exit from one-hop
-    circuits.  Routers with this policy will not require that a circuit
-    has at least two hops when it is used as an exit.
-
-    In addition, routers for which this configuration option
-    has been set will have a line in their descriptors, "opt
-    exit-from-single-hop-circuits".  Clients will keep track of which
-    routers have this option and allow streams to be attached to
-    single-hop circuits that include such routers.
-
-Security Considerations
-
-    This approach seems to eliminate the worry about operational router
-    security, since server operators will not set the configuraiton
-    option unless they are willing to take on such risk.
-
-    To reduce the impact on anonymity of the network resulting
-    from including such "risky" routers in regular Tor path
-    selection, clients may systematically exclude routers with "opt
-    exit-from-single-hop-circuits" when choosing random paths through
-    the Tor network.
-
diff --git a/doc/spec/proposals/153-automatic-software-update-protocol.txt b/doc/spec/proposals/153-automatic-software-update-protocol.txt
deleted file mode 100644
index 7bc809d..0000000
--- a/doc/spec/proposals/153-automatic-software-update-protocol.txt
+++ /dev/null
@@ -1,177 +0,0 @@
-Filename: 153-automatic-software-update-protocol.txt
-Title: Automatic software update protocol
-Version: $Revision$
-Last-Modified: $Date$
-Author: Jacob Appelbaum 
-Created: 14-July-2008
-Status: Superseded
-
-[Superseded by thandy-spec.txt]
-
-
-                      Automatic Software Update Protocol Proposal
-
-0.0 Introduction
-
-The Tor project and its users require a robust method to update shipped
-software bundles. The software bundles often includes Vidalia, Privoxy, Polipo,
-Torbutton and of course Tor itself. It is not inconcievable that an update
-could include all of the Tor Browser Bundle. It seems reasonable to make this 
-a standalone program that can be called in shell scripts, cronjobs or by
-various Tor controllers.
-
-0.1 Minimal Tasks To Implement Automatic Updating
-
-At the most minimal, an update must be able to do the following: 
-
-    0 - Detect the curent Tor version, note the working status of Tor.
-    1 - Detect the latest Tor version. 
-    2 - Fetch the latest version in the form of a platform specific package(s).
-    3 - Verify the itegrity of the downloaded package(s).
-    4 - Install the verified package(s).
-    5 - Test that the new package(s) works properly.
-
-0.2 Specific Enumeration Of Minimal Tasks
-
-To implement requirement 0, we need to detect the current Tor version of both 
-the updater and the current running Tor. The update program itself should be 
-versioned internally. This requirement should also test connecting through Tor 
-itself and note if such connections are possible.
-
-To implement requirement 1, we need to learn the concensus from the directory 
-authorities or fail back to a known good URL with cryptographically signed 
-content.
-
-To implement requirement 2, we need to download Tor - hopefully over Tor.
-
-To implement requirement 3, we need to verify the package signature.
-
-To implement requirement 4, we need to use a platform specific method of 
-installation. The Tor controller performing the update perform these platform 
-specific methods.
-
-To implement requirement 5, we need to be able to extend circuits and reach 
-the internet through Tor.
-
-0.x Implementation Goals
-
-The update system will be cross platform and rely on as little external code 
-as possible. If the update system uses it, it must be updated by the update 
-system itself. It will consist only of free software and will not rely on any 
-non-free components until the actual installation phase. If a package manager 
-is in use, it will be platform specific and thus only invoked by the update 
-system implementing the update protocol.
-
-The update system itself will attempt to perform update related network 
-activity over Tor. Possibly it will attempt to use a hidden service first.
-It will attempt to use novel and not so novel caching 
-when possible, it will always verify cryptographic signatures before any 
-remotely fetched code is executed. In the event of an unusable Tor system, 
-it will be able to attempt to fetch updates without Tor. This should be user 
-configurable, some users will be unwilling to update without the protection of 
-using Tor - others will simply be unable because of blocking of the main Tor 
-website.
-
-The update system will track current version numbers of Tor and supporting 
-software. The update system will also track known working versions to assist 
-with automatic The update system itself will be a standalone library. It will be 
-strongly versioned internally to match the Tor bundle it was shiped with. The 
-update system will keep track of the given platform, cpu architecture, lsb_release, 
-package management functionality and any other platform specific metadata.
-
-We have referenced two popular automatic update systems, though neither fit 
-our needs, both are useful as an idea of what others are doing in the same 
-area.
-
-The first is sparkle[0] but it is sadly only available for Cocoa 
-environments and is written in Objective C. This doesn't meet our requirements 
-because it is directly tied into the private Apple framework.
-
-The second is the Mozilla Automatic Update System[1]. It is possibly useful 
-as an idea of how other free software projects automatically update. It is 
-however not useful in its currently documented form.
-
-
-    [0] http://sparkle.andymatuschak.org/documentation/
-    [1] http://wiki.mozilla.org/AUS:Manual
-
-0.x Previous methods of Tor and related software update
-
-Previously, Tor users updated their Tor related software by hand. There has
-been no fully automatic method for any user to update. In addition, there
-hasn't been any specific way to find out the most current stable version of Tor
-or related software as voted on by the directory authority concensus.
-
-0.x Changes to the directory specification
-
-We will want to supplement client-versions and server-versions in the 
-concensus voting with another version identifier known as 
-'auto-update-versions'. This will keep track of the current concensus of 
-specific versions that are best per platform and per architecture. It should 
-be noted that while the Mac OS X universal binary may be the best for x86 
-processers with Tiger, it may not be the best for PPC users on Panther. This 
-goes for all of the package updates. We want to prevent updates that cause Tor 
-to break even if the updating program can recover gracefully.
-
-x.x Assumptions About Operating System Package Management
-
-It is assumed that users will use their package manager unless they are on 
-Microsoft Windows (any version) or Mac OS X (any version). Microsoft Windows 
-users will have integration with the normal "add/remove program" functionality 
-that said users would expect.
-
-x.x Package Update System Failure Modes
-
-The package update will try to ensure that a user always has a working Tor at 
-the very least. It will keep state to remember versions of Tor that were able 
-to bootstrap properly and reach the rest of the Tor network. It will also keep 
-note of which versions broke. It will select the best Tor that works for the 
-user. It will also allow for anonymized bug reporting on the packages 
-available and tested by the auto-update system.
-
-x.x Package Signature Verification
-
-The update system will be aware of replay attacks against the update signature 
-system itself. It will not allow package update signatures that are radically 
-out of date. It will be a multi-key system to prevent any single party from 
-forging an update. The key will be updated regularly. This is like authority 
-key (see proposal 103) usage.
-
-x.x Package Caching
-
-The update system will iterate over different update methods. Whichever method 
-is picked will have caching functionality. Each Tor server itself should be 
-able to serve cached update files. This will be an option that friendly server 
-administrators can turn on should they wish to support caching. In addition, 
-it is possible to cache the full contents of a package in an 
-authoratative DNS zone. Users can then query the DNS zone for their package. 
-If we wish to further distribute the update load, we can also offer packages 
-with encrypted bittorrent. Clients who wish to share the updates but do not 
-wish to be a server can help distribute Tor updates. This can be tied together 
-with the DNS caching[2][3] if needed.
-
-    [2] http://www.netrogenic.com/dnstorrent/
-    [3] http://www.doxpara.com/ozymandns_src_0.1.tgz
-
-x.x Helping Our Users Spread Tor
-
-There should be a way for a user to participate in the packaging caching as 
-described in section x.x. This option should be presented by the Tor 
-controller.
-
-x.x Simple HTTP Proxy To The Tor Project Website
-
-It has been suggested that we should provide a simple proxy that allows a user 
-to visit the main Tor website to download packages. This was part of a 
-previous proposal and has not been closely examined.
-
-x.x Package Installation
-
-Platform specific methods for proper package installation will be left to the 
-controller that is calling for an update. Each platform is different, the 
-installation options and user interface will be specific to the controller in 
-question.
-
-x.x Other Things
-
-Other things should be added to this proposal. What are they?
diff --git a/doc/spec/proposals/154-automatic-updates.txt b/doc/spec/proposals/154-automatic-updates.txt
deleted file mode 100644
index 00a820d..0000000
--- a/doc/spec/proposals/154-automatic-updates.txt
+++ /dev/null
@@ -1,379 +0,0 @@
-Filename: 154-automatic-updates.txt
-Title: Automatic Software Update Protocol
-Version: $Revision$
-Last-Modified: $Date$
-Author: Matt Edman
-Created: 30-July-2008
-Status: Superseded
-Target: 0.2.1.x
-
-Superseded by thandy-spec.txt
-
-Scope
-
-  This proposal specifies the method by which an automatic update client can
-  determine the most recent recommended Tor installation package for the
-  user's platform, download the package, and then verify that the package was
-  downloaded successfully. While this proposal focuses on only the Tor
-  software, the protocol defined is sufficiently extensible such that other
-  components of the Tor bundles, like Vidalia, Polipo, and Torbutton, can be
-  managed and updated by the automatic update client as well.
-
-  The initial target platform for the automatic update framework is Windows,
-  given that's the platform used by a majority of our users and that it lacks
-  a sane package management system that many Linux distributions already have.
-  Our second target platform will be Mac OS X, and so the protocol will be
-  designed with this near-future direction in mind.
-
-  Other client-side aspects of the automatic update process, such as user
-  interaction, the interface presented, and actual package installation
-  procedure, are outside the scope of this proposal.
-
-
-Motivation
-
-  Tor releases new versions frequently, often with important security,
-  anonymity, and stability fixes. Thus, it is important for users to be able
-  to promptly recognize when new versions are available and to easily
-  download, authenticate, and install updated Tor and Tor-related software
-  packages.
-
-  Tor's control protocol [2] provides a method by which controllers can
-  identify when the user's Tor software is obsolete or otherwise no longer
-  recommended. Currently, however, no mechanism exists for clients to
-  automatically download and install updated Tor and Tor-related software for
-  the user.
-
-
-Design Overview
-
-  The core of the automatic update framework is a well-defined file called a
-  "recommended-packages" file. The recommended-packages file is accessible via
-  HTTP[S] at one or more well-defined URLs. An example recommended-packages
-  URL may be:
-
-    https://updates.torproject.org/recommended-packages
-
-  The recommended-packages document is formatted according to Section 1.2
-  below and specifies the most recent recommended installation package
-  versions for Tor or Tor-related software, as well as URLs at which the
-  packages and their signatures can be downloaded.
-
-  An automatic update client process runs on the Tor user's computer and
-  periodically retrieves the recommended-packages file according to the method
-  described in Section 2.0. As described further in Section 1.2, the
-  recommended-packages file is signed and can be verified by the automatic
-  update client with one or more public keys included in the client software.
-  Since it is signed, the recommended-packages file can be mirrored by
-  multiple hosts (e.g., Tor directory authorities), whose URLs are included in
-  the automatic update client's configuration.
-
-  After retrieving and verifying the recommended-packages file, the automatic
-  update client compares the versions of the recommended software packages
-  listed in the file with those currently installed on the end-user's
-  computer. If one or more of the installed packages is determined to be out
-  of date, an updated package and its signature will be downloaded from one of
-  the package URLs listed in the recommended-packages file as described in
-  Section 2.2.
-
-  The automatic update system uses a multilevel signing key scheme for package
-  signatures. There are a small number of entities we call "packaging
-  authorities" that each have their own signing key. A packaging authority is
-  responsible for signing and publishing the recommended-packages file.
-  Additionally, each individual packager responsible for producing an
-  installation package for one or more platforms has their own signing key.
-  Every packager's signing key must be signed by at least one of the packaging
-  authority keys.
-
-
-Specification
-
-  1. recommended-packages Specification
-
-  In this section we formally specify the format of the published
-  recommended-packages file.
-
-  1.1. Document Meta-format
-
-  The recommended-packages document follows the lightweight extensible
-  information format defined in Tor's directory protocol specification [1]. In
-  the interest of self-containment, we have reproduced the relevant portions
-  of that format's specification in this Section. (Credits to Nick Mathewson
-  for much of the original format definition language.)
-
-  The highest level object is a Document, which consists of one or more
-  Items.  Every Item begins with a KeywordLine, followed by zero or more
-  Objects. A KeywordLine begins with a Keyword, optionally followed by
-  whitespace and more non-newline characters, and ends with a newline.  A
-  Keyword is a sequence of one or more characters in the set [A-Za-z0-9-].
-  An Object is a block of encoded data in pseudo-Open-PGP-style
-  armor. (cf. RFC 2440)
-
-  More formally:
-
-    Document     ::= (Item | NL)+
-    Item         ::= KeywordLine Object*
-    KeywordLine  ::= Keyword NL | Keyword WS ArgumentChar+ NL
-    Keyword      ::= KeywordChar+
-    KeywordChar  ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9' | '-'
-    ArgumentChar ::= any printing ASCII character except NL.
-    WS           ::= (SP | TAB)+
-    Object       ::= BeginLine Base-64-encoded-data EndLine
-    BeginLine    ::= "-----BEGIN " Keyword "-----" NL
-    EndLine      ::= "-----END " Keyword "-----" NL
-
-    The BeginLine and EndLine of an Object must use the same keyword.
-
-  In our Document description below, we also tag Items with a multiplicity in
-  brackets. Possible tags are:
-
-    "At start, exactly once": These items MUST occur in every instance of the
-    document type, and MUST appear exactly once, and MUST be the first item in
-    their documents.
-
-    "Exactly once": These items MUST occur exactly one time in every
-    instance of the document type.
-
-    "Once or more": These items MUST occur at least once in any instance
-    of the document type, and MAY occur more than once.
-
-    "At end, exactly once": These items MUST occur in every instance of
-    the document type, and MUST appear exactly once, and MUST be the
-    last item in their documents.
-
-  1.2. recommended-packages Document Format
-
-  When interpreting a recommended-packages Document, software MUST ignore
-  any KeywordLine that starts with a keyword it doesn't recognize; future
-  implementations MUST NOT require current automatic update clients to
-  understand any KeywordLine not currently described.
-
-  In lines that take multiple arguments, extra arguments SHOULD be
-  accepted and ignored.
-
-  The currently defined Items contained in a recommended-packages document
-  are:
-
-    "recommended-packages-format" SP number NL
-
-      [Exactly once]
-
-      This Item specifies the version of the recommended-packages format that
-      is contained in the subsequent document. The version defined in this
-      proposal is version "1". Subsequent iterations of this protocol MUST
-      increment this value if they introduce incompatible changes to the
-      document format and MAY increment this value if they only introduce
-      additional Keywords.
-
-    "published" SP YYYY-MM-DD SP HH:MM:SS NL
-
-      [Exactly once]
-
-      The time, in GMT, when this recommended-packages document was generated.
-      Automatic update clients SHOULD ignore Documents over 60 days old.
-
-    "tor-stable-win32-version" SP TorVersion NL
-
-      [Exactly once]
-
-      This keyword specifies the latest recommended release of Tor's "stable"
-      branch for the Windows platform that has an installation package
-      available. Note that this version does not necessarily correspond to the
-      most recently tagged stable Tor version, since that version may not yet
-      have an installer package available, or may have known issues on
-      Windows.
-
-      The TorVersion field is formatted according to Section 2 of Tor's
-      version specification [3].
-
-    "tor-stable-win32-package" SP Url NL
-
-      [Once or more]
-
-      This Item specifies the location from which the most recent
-      recommended Windows installation package for Tor's stable branch can be
-      downloaded.
-
-      When this Item appears multiple times within the Document, automatic
-      update clients SHOULD select randomly from the available package
-      mirrors.
-
-    "tor-dev-win32-version" SP TorVersion NL
-
-      [Exactly once]
-
-      This Item specifies the latest recommended release of Tor's
-      "development" branch for the Windows platform that has an installation
-      package available. The same caveats from the description of
-      "tor-stable-win32-version" also apply to this keyword.
-
-      The TorVersion field is formatted according to Section 2 of Tor's
-      version specification [3].
-
-    "tor-dev-win32-package" SP Url NL
-
-      [Once or more]
-
-      This Item specifies the location from which the most recent recommended
-      Windows installation package and its signature for Tor's development
-      branch can be downloaded.
-
-      When this Keyword appears multiple times within the Document, automatic
-      update clients SHOULD select randomly from the available package
-      mirrors.
-
-    "signature" NL SIGNATURE NL
-
-      [At end, exactly once]
-
-      The "SIGNATURE" Object contains a PGP signature (using a packaging
-      authority signing key) of the entire document, taken from the beginning
-      of the "recommended-packages-format" keyword, through the newline after
-      the "signature" Keyword.
-
-
-  2. Automatic Update Client Behavior
-
-  The client-side component of the automatic update framework is an
-  application that runs on the end-user's machine. It is responsible for
-  fetching and verifying a recommended-packages document, as well as
-  downloading, verifying, and subsequently installing any necessary updated
-  software packages.
-
-  2.1. Download and verify a recommended-packages document
-
-  The first step in the automatic update process is for the client to download
-  a copy of the recommended-packages file. The automatic update client
-  contains a (hardcoded and/or user-configurable) list of URLs from which it
-  will attempt to retrieve a recommended-packages file.
-
-  Connections to each of the recommended-packages URLs SHOULD be attempted in
-  the following order:
-
-    1) HTTPS over Tor
-    2) HTTP over Tor
-    3) Direct HTTPS
-    4) Direct HTTP
-
-  If the client fails to retrieve a recommended-packages document via any of
-  the above connection methods from any of the configured URLs, the client
-  SHOULD retry its download attempts following an exponential back-off
-  algorithm. After the first failed attempt, the client SHOULD delay one hour
-  before attempting again, up to a maximum of 24 hours delay between retry
-  attempts.
-
-  After successfully downloading a recommended-packages file, the automatic
-  update client will verify the signature using one of the public keys
-  distributed with the client software. If more than one recommended-packages
-  file is downloaded and verified, the file with the most recent "published"
-  date that is verified will be retained and the rest discarded.
-
-  2.2. Download and verify the updated packages
-
-  The automatic update client next compares the latest recommended package
-  version from the recommended-packages document with the currently installed
-  Tor version. If the user currently has installed a Tor version from Tor's
-  "development" branch, then the version specified in "tor-dev-*-version" Item
-  is used for comparison. Similarly, if the user currently has installed a Tor
-  version from Tor's "stable" branch, then the version specified in the
-  "tor-stable-*version" Item is used for comparison. Version comparisons are
-  done according to Tor's version specification [3].
-
-  If the automatic update client determines an installation package newer than
-  the user's currently installed version is available, it will attempt to
-  download a package appropriate for the user's platform and Tor branch from a
-  URL specified by a "tor-[branch]-[platform]-package" Item. If more than one
-  mirror for the selected package is available, a mirror will be chosen at
-  random from all those available.
-
-  The automatic update client must also download a ".asc" signature file for
-  the retrieved package. The URL for the package signature is the same as that
-  for the package itself, except with the extension ".asc" appended to the
-  package URL.
-
-  Connections to download the updated package and its signature SHOULD be
-  attempted in the same order described in Section 2.1.
-
-  After completing the steps described in Sections 2.1 and 2.2, the automatic
-  update client will have downloaded and verified a copy of the latest Tor
-  installation package. It can then take whatever subsequent platform-specific
-  steps are necessary to install the downloaded software updates.
-
-  2.3. Periodic checking for updates
-
-  The automatic update client SHOULD maintain a local state file in which it
-  records (at a minimum) the timestamp at which it last retrieved a
-  recommended-packages file and the timestamp at which the client last
-  successfully downloaded and installed a software update.
-
-  Automatic update clients SHOULD check for an updated recommended-packages
-  document at most once per day but at least once every 30 days.
-
-
-  3. Future Extensions
-
-  There are several possible areas for future extensions of this framework.
-  The extensions below are merely suggestions and should be the subject of
-  their own proposal before being implemented.
-
-  3.1. Additional Software Updates
-
-  There are several software packages often included in Tor bundles besides
-  Tor, such as Vidalia, Privoxy or Polipo, and Torbutton. The versions and
-  download locations of updated installation packages for these bundle
-  components can be easily added to the recommended-packages document
-  specification above.
-
-  3.2. Including ChangeLog Information
-
-  It may be useful for automatic update clients to be able to display for
-  users a summary of the changes made in the latest Tor or Tor-related
-  software release, before the user chooses to install the update. In the
-  future, we can add keywords to the specification in Section 1.2 that specify
-  the location of a ChangeLog file for the latest recommended package
-  versions. It may also be desirable to allow localized ChangeLog information,
-  so that the automatic update client can fetch release notes in the
-  end-user's preferred language.
-
-  3.3. Weighted Package Mirror Selection
-
-  We defined in Section 1.2 a method by which automatic update clients can
-  select from multiple available package mirrors. We may want to add a Weight
-  argument to the "*-package" Items that allows the recommended-packages file
-  to suggest to clients the probability with which a package mirror should be
-  chosen. This will allow clients to more appropriately distribute package
-  downloads across available mirrors proportional to their approximate
-  bandwidth.
-
-
-Implementation
-
-  Implementation of this proposal will consist of two separate components.
-
-  The first component is a small "au-publish" tool that takes as input a
-  configuration file specifying the information described in Section 1.2 and a
-  private key. The tool is run by a "packaging authority" (someone responsible
-  for publishing updated installation packages), who will be prompted to enter
-  the passphrase for the private key used to sign the recommended-packages
-  document. The output of the tool is a document formatted according to
-  Section 1.2, with a signature appended at the end. The resulting document
-  can then be published to any of the update mirrors.
-
-  The second component is an "au-client" tool that is run on the end-user's
-  machine. It periodically checks for updated installation packages according
-  to Section 2 and fetches the packages if necessary. The public keys used
-  to sign the recommended-packages file and any of the published packages are
-  included in the "au-client" tool.
-
-
-References
-
-  [1] Tor directory protocol (version 3),
-  https://tor-svn.freehaven.net/svn/tor/trunk/doc/spec/dir-spec.txt
-
-  [2] Tor control protocol (version 2),
-  https://tor-svn.freehaven.net/svn/tor/trunk/doc/spec/control-spec.txt
-
-  [3] Tor version specification,
-  https://tor-svn.freehaven.net/svn/tor/trunk/doc/spec/version-spec.txt
-
diff --git a/doc/spec/proposals/155-four-hidden-service-improvements.txt b/doc/spec/proposals/155-four-hidden-service-improvements.txt
deleted file mode 100644
index f528f8b..0000000
--- a/doc/spec/proposals/155-four-hidden-service-improvements.txt
+++ /dev/null
@@ -1,122 +0,0 @@
-Filename: 155-four-hidden-service-improvements.txt
-Title: Four Improvements of Hidden Service Performance
-Version: $Revision$
-Last-Modified: $Date$
-Author: Karsten Loesing, Christian Wilms
-Created: 25-Sep-2008
-Status: Finished
-Implemented-In: 0.2.1.x
-
-Change history:
-
-  25-Sep-2008  Initial proposal for or-dev
-
-Overview:
-
-  A performance analysis of hidden services [1] has brought up a few
-  possible design changes to reduce advertisement time of a hidden service
-  in the network as well as connection establishment time. Some of these
-  design changes have side-effects on anonymity or overall network load
-  which had to be weighed up against individual performance gains. A
-  discussion of seven possible design changes [2] has led to a selection
-  of four changes [3] that are proposed to be implemented here.
-
-Design:
-
-  1. Shorter Circuit Extension Timeout
-
-  When establishing a connection to a hidden service a client cannibalizes
-  an existing circuit and extends it by one hop to one of the service's
-  introduction points. In most cases this can be accomplished within a few
-  seconds. Therefore, the current timeout of 60 seconds for extending a
-  circuit is far too high.
-
-  Assuming that the timeout would be reduced to a lower value, for example
-  30 seconds, a second (or third) attempt to cannibalize and extend would
-  be started earlier. With the current timeout of 60 seconds, 93.42% of all
-  circuits can be established, whereas this fraction would have been only
-  0.87% smaller at 92.55% with a timeout of 30 seconds.
-
-  For a timeout of 30 seconds the performance gain would be approximately 2
-  seconds in the mean as opposed to the current timeout of 60 seconds. At
-  the same time a smaller timeout leads to discarding an increasing number
-  of circuits that might have been completed within the current timeout of
-  60 seconds.
-
-  Measurements with simulated low-bandwidth connectivity have shown that
-  there is no significant effect of client connectivity on circuit
-  extension times. The reason for this might be that extension messages are
-  small and thereby independent of the client bandwidth. Further, the
-  connection between client and entry node only constitutes a single hop of
-  a circuit, so that its influence on the whole circuit is limited.
-
-  The exact value of the new timeout does not necessarily have to be 30
-  seconds, but might also depend on the results of circuit build timeout
-  measurements as described in proposal 151.
-
-  2. Parallel Connections to Introduction Points
-
-  An additional approach to accelerate extension of introduction circuits
-  is to extend a second circuit in parallel to a different introduction
-  point. Such parallel extension attempts should be started after a short
-  delay of, e.g., 15 seconds in order to prevent unnecessary circuit
-  extensions and thereby save network resources. Whichever circuit
-  extension succeeds first is used for introduction, while the other
-  attempt is aborted.
-
-  An evaluation has been performed for the more resource-intensive approach
-  of starting two parallel circuits immediately instead of waiting for a
-  short delay. The result was a reduction of connection establishment times
-  from 27.4 seconds in the original protocol to 22.5 seconds.
-
-  While the effect of the proposed approach of delayed parallelization on
-  mean connection establishment times is expected to be smaller,
-  variability of connection attempt times can be reduced significantly.
-
-  3. Increase Count of Internal Circuits
-
-  Hidden services need to create or cannibalize and extend a circuit to a
-  rendezvous point for every client request. Really popular hidden services
-  require more than two internal circuits in the pool to answer multiple
-  client requests at the same time. This scenario was not yet analyzed, but
-  will probably exhibit worse performance than measured in the previous
-  analysis. The number of preemptively built internal circuits should be a
-  function of connection requests in the past to adapt to changing needs.
-  Furthermore, an increased number of internal circuits on client side
-  would allow clients to establish connections to more than one hidden
-  service at a time.
-
-  Under the assumption that a popular hidden service cannot make use of
-  cannibalization for connecting to rendezvous points, the circuit creation
-  time needs to be added to the current results. In the mean, the
-  connection establishment time to a popular hidden service would increase
-  by 4.7 seconds.
-
-  4. Build More Introduction Circuits
-
-  When establishing introduction points, a hidden service should launch 5
-  instead of 3 introduction circuits at the same time and use only the
-  first 3 that could be established. The remaining two circuits could still
-  be used for other purposes afterwards.
-
-  The effect has been simulated using previously measured data, too.
-  Therefore, circuit establishment times were derived from log files and
-  written to an array. Afterwards, a simulation with 10,000 runs was
-  performed picking 5 (4, 6) random values and using the 3 lowest values in
-  contrast to picking only 3 values at random. The result is that the mean
-  time of the 3-out-of-3 approach is 8.1 seconds, while the mean time of
-  the 3-out-of-5 approach is 4.4 seconds.
-
-  The effect on network load is minimal, because the hidden service can
-  reuse the slower internal circuits for other purposes, e.g., rendezvous
-  circuits. The only change is that a hidden service starts establishing
-  more circuits at once instead of subsequently doing so.
-
-References:
-
-  [1] http://freehaven.net/~karsten/hidserv/perfanalysis-2008-06-15.pdf
-
-  [2] http://freehaven.net/~karsten/hidserv/discussion-2008-07-15.pdf
-
-  [3] http://freehaven.net/~karsten/hidserv/design-2008-08-15.pdf
-
diff --git a/doc/spec/proposals/156-tracking-blocked-ports.txt b/doc/spec/proposals/156-tracking-blocked-ports.txt
deleted file mode 100644
index 1e7b0d9..0000000
--- a/doc/spec/proposals/156-tracking-blocked-ports.txt
+++ /dev/null
@@ -1,529 +0,0 @@
-Filename: 156-tracking-blocked-ports.txt
-Title: Tracking blocked ports on the client side
-Version: $Revision$
-Last-Modified: $Date$
-Author: Robert Hogan
-Created: 14-Oct-2008
-Status: Open
-Target: 0.2.?
-
-Motivation:
-Tor clients that are behind extremely restrictive firewalls can end up
-waiting a while for their first successful OR connection to a node on the
-network.  Worse, the more restrictive their firewall the more susceptible
-they are to an attacker guessing their entry nodes. Tor routers that
-are behind extremely restrictive firewalls can only offer a limited,
-'partitioned' service to other routers and clients on the network. Exit
-nodes behind extremely restrictive firewalls may advertise ports that they
-are actually not able to connect to, wasting network resources in circuit
-constructions that are doomed to fail at the last hop on first use.
-
-Proposal:
-
-When a client attempts to connect to an entry guard it should avoid
-further attempts on ports that fail once until it has connected to at
-least one entry guard successfully. (Maybe it should wait for more than
-one failure to reduce the skew on the first node selection.) Thereafter
-it should select entry guards regardless of port and warn the user if
-it observes that connections to a given port have failed every multiple
-of 5 times without success or since the last success.
-
-Tor should warn the operators of exit, middleman and entry nodes if it
-observes that connections to a given port have failed a multiple of 5
-times without success or since the last success. If attempts on a port
-fail 20 or more times without or since success, Tor should add the port
-to a 'blocked-ports' entry in its descriptor's extra-info. Some thought
-needs to be given to what the authorities might do with this information.
-
-Related TODO item:
-    "- Automatically determine what ports are reachable and start using
-      those, if circuits aren't working and it's a pattern we
-      recognize ("port 443 worked once and port 9001 keeps not
-      working")."
-
-
-I've had a go at implementing all of this in the attached.
-
-Addendum:
-Just a note on the patch, storing the digest of each router that uses the port
-is a bit of a memory hog, and its only real purpose is to provide a count of
-routers using that port when warning the user. That could be achieved when
-warning the user by iterating through the routerlist instead.
-
-Index: src/or/connection_or.c
-===================================================================
---- src/or/connection_or.c	(revision 17104)
-+++ src/or/connection_or.c	(working copy)
-@@ -502,6 +502,9 @@
- connection_or_connect_failed(or_connection_t *conn,
-                              int reason, const char *msg)
- {
-+  if ((reason == END_OR_CONN_REASON_NO_ROUTE) ||
-+      (reason == END_OR_CONN_REASON_REFUSED))
-+    or_port_hist_failure(conn->identity_digest,TO_CONN(conn)->port);
-   control_event_or_conn_status(conn, OR_CONN_EVENT_FAILED, reason);
-   if (!authdir_mode_tests_reachability(get_options()))
-     control_event_bootstrap_problem(msg, reason);
-@@ -580,6 +583,7 @@
-     /* already marked for close */
-     return NULL;
-   }
-+
-   return conn;
- }
- 
-@@ -909,6 +913,7 @@
-   control_event_or_conn_status(conn, OR_CONN_EVENT_CONNECTED, 0);
- 
-   if (started_here) {
-+    or_port_hist_success(TO_CONN(conn)->port);
-     rep_hist_note_connect_succeeded(conn->identity_digest, now);
-     if (entry_guard_register_connect_status(conn->identity_digest,
-                                             1, now) < 0) {
-Index: src/or/rephist.c
-===================================================================
---- src/or/rephist.c	(revision 17104)
-+++ src/or/rephist.c	(working copy)
-@@ -18,6 +18,7 @@
- static void bw_arrays_init(void);
- static void predicted_ports_init(void);
- static void hs_usage_init(void);
-+static void or_port_hist_init(void);
- 
- /** Total number of bytes currently allocated in fields used by rephist.c. */
- uint64_t rephist_total_alloc=0;
-@@ -89,6 +90,25 @@
-   digestmap_t *link_history_map;
- } or_history_t;
- 
-+/** or_port_hist_t contains our router/client's knowledge of
-+    all OR ports offered on the network, and how many servers with each port we
-+    have succeeded or failed to connect to. */
-+typedef struct {
-+  /** The port this entry is tracking. */
-+  uint16_t or_port;
-+  /** Have we ever connected to this port on another OR?. */
-+  unsigned int success:1;
-+  /** The ORs using this port. */
-+  digestmap_t *ids;
-+  /** The ORs using this port we have failed to connect to. */
-+  digestmap_t *failure_ids;
-+  /** Are we excluding ORs with this port during entry selection?*/
-+  unsigned int excluded;
-+} or_port_hist_t;
-+
-+static unsigned int still_searching = 0;
-+static smartlist_t *or_port_hists;
-+
- /** When did we last multiply all routers' weighted_run_length and
-  * total_run_weights by STABILITY_ALPHA? */
- static time_t stability_last_downrated = 0;
-@@ -164,6 +184,16 @@
-   tor_free(hist);
- }
- 
-+/** Helper: free storage held by a single OR port history entry. */
-+static void
-+or_port_hist_free(or_port_hist_t *p)
-+{
-+  tor_assert(p);
-+  digestmap_free(p->ids,NULL);
-+  digestmap_free(p->failure_ids,NULL);
-+  tor_free(p);
-+}
-+
- /** Update an or_history_t object <b>hist</b> so that its uptime/downtime
-  * count is up-to-date as of <b>when</b>.
-  */
-@@ -1639,7 +1669,7 @@
-     tmp_time = smartlist_get(predicted_ports_times, i);
-     if (*tmp_time + PREDICTED_CIRCS_RELEVANCE_TIME < now) {
-       tmp_port = smartlist_get(predicted_ports_list, i);
--      log_debug(LD_CIRC, "Expiring predicted port %d", *tmp_port);
-+      log_debug(LD_HIST, "Expiring predicted port %d", *tmp_port);
-       smartlist_del(predicted_ports_list, i);
-       smartlist_del(predicted_ports_times, i);
-       rephist_total_alloc -= sizeof(uint16_t)+sizeof(time_t);
-@@ -1821,6 +1851,12 @@
-   tor_free(last_stability_doc);
-   built_last_stability_doc_at = 0;
-   predicted_ports_free();
-+  if (or_port_hists) {
-+    SMARTLIST_FOREACH(or_port_hists, or_port_hist_t *, p,
-+                      or_port_hist_free(p));
-+    smartlist_free(or_port_hists);
-+    or_port_hists = NULL;
-+  }
- }
- 
- /****************** hidden service usage statistics ******************/
-@@ -2356,3 +2392,225 @@
-   tor_free(fname);
- }
- 
-+/** Create a new entry in the port tracking cache for the or_port in
-+  * <b>ri</b>. */
-+void
-+or_port_hist_new(const routerinfo_t *ri)
-+{
-+  or_port_hist_t *result;
-+  const char *id=ri->cache_info.identity_digest;
-+
-+  if (!or_port_hists)
-+    or_port_hist_init();
-+
-+  SMARTLIST_FOREACH(or_port_hists, or_port_hist_t *, tp,
-+    {
-+      /* Cope with routers that change their advertised OR port or are
-+         dropped from the networkstatus. We don't discard the failures of
-+         dropped routers because they are still valid when counting
-+         consecutive failures on a port.*/
-+      if (digestmap_get(tp->ids, id) && (tp->or_port != ri->or_port)) {
-+        digestmap_remove(tp->ids, id);
-+      }
-+      if (tp->or_port == ri->or_port) {
-+        if (!(digestmap_get(tp->ids, id)))
-+          digestmap_set(tp->ids, id, (void*)1);
-+        return;
-+      }
-+    });
-+
-+  result = tor_malloc_zero(sizeof(or_port_hist_t));
-+  result->or_port=ri->or_port;
-+  result->success=0;
-+  result->ids=digestmap_new();
-+  digestmap_set(result->ids, id, (void*)1);
-+  result->failure_ids=digestmap_new();
-+  result->excluded=0;
-+  smartlist_add(or_port_hists, result);
-+}
-+
-+/** Create the port tracking cache. */
-+/*XXX: need to call this when we rebuild/update our network status */
-+static void
-+or_port_hist_init(void)
-+{
-+  routerlist_t *rl = router_get_routerlist();
-+
-+  if (!or_port_hists)
-+    or_port_hists=smartlist_create();
-+
-+  if (rl && rl->routers) {
-+    SMARTLIST_FOREACH(rl->routers, routerinfo_t *, ri,
-+    {
-+      or_port_hist_new(ri);
-+    });
-+  }
-+}
-+
-+#define NOT_BLOCKED 0
-+#define FAILURES_OBSERVED 1
-+#define POSSIBLY_BLOCKED 5
-+#define PROBABLY_BLOCKED 10
-+/** Return the list of blocked ports for our router's extra-info.*/
-+char *
-+or_port_hist_get_blocked_ports(void)
-+{
-+  char blocked_ports[2048];
-+  char *bp;
-+  
-+  tor_snprintf(blocked_ports,sizeof(blocked_ports),"blocked-ports");
-+  SMARTLIST_FOREACH(or_port_hists, or_port_hist_t *, tp,
-+    {
-+      if (digestmap_size(tp->failure_ids) >= PROBABLY_BLOCKED)
-+        tor_snprintf(blocked_ports+strlen(blocked_ports),
-+                     sizeof(blocked_ports)," %u,",tp->or_port);
-+    });
-+  if (strlen(blocked_ports) == 13)
-+    return NULL;
-+  bp=tor_strdup(blocked_ports);
-+  bp[strlen(bp)-1]='\n';
-+  bp[strlen(bp)]='\0';
-+  return bp;
-+}
-+
-+/** Revert to client-only mode if we have seen to many failures on a port or
-+  * range of ports.*/
-+static void
-+or_port_hist_report_block(unsigned int min_severity)
-+{
-+  or_options_t *options=get_options();
-+  char failures_observed[2048],possibly_blocked[2048],probably_blocked[2048];
-+  char port[1024];
-+
-+  memset(failures_observed,0,sizeof(failures_observed));
-+  memset(possibly_blocked,0,sizeof(possibly_blocked));
-+  memset(probably_blocked,0,sizeof(probably_blocked));
-+
-+  SMARTLIST_FOREACH(or_port_hists, or_port_hist_t *, tp,
-+    {
-+      unsigned int failures = digestmap_size(tp->failure_ids);
-+      if (failures >= min_severity) {
-+        tor_snprintf(port, sizeof(port), " %u (%u failures %s out of %u on the"
-+                     " network)",tp->or_port,failures,
-+                     (!tp->success)?"and no successes": "since last success",
-+                     digestmap_size(tp->ids));
-+        if (failures >= PROBABLY_BLOCKED) {
-+          strlcat(probably_blocked, port, sizeof(probably_blocked));
-+        } else if (failures >= POSSIBLY_BLOCKED)
-+          strlcat(possibly_blocked, port, sizeof(possibly_blocked));
-+        else if (failures >= FAILURES_OBSERVED)
-+          strlcat(failures_observed, port, sizeof(failures_observed));
-+      }
-+    });
-+
-+  log_warn(LD_HIST,"%s%s%s%s%s%s%s%s",
-+           server_mode(options) &&
-+           ((min_severity==FAILURES_OBSERVED) || strlen(probably_blocked))?
-+           "You should consider disabling your Tor server.":"",
-+           (min_severity==FAILURES_OBSERVED)?
-+           "Tor appears to be blocked from connecting to a range of ports "
-+           "with the result that it cannot connect to one tenth of the Tor "
-+           "network. ":"",
-+           strlen(failures_observed)?
-+           "Tor has observed failures on the following ports: ":"",
-+           failures_observed,
-+           strlen(possibly_blocked)?
-+           "Tor is possibly blocked on the following ports: ":"",
-+           possibly_blocked,
-+           strlen(probably_blocked)?
-+           "Tor is almost certainly blocked on the following ports: ":"",
-+           probably_blocked);
-+
-+}
-+
-+/** Record the success of our connection to <b>digest</b>'s
-+  * OR port. */
-+void
-+or_port_hist_success(uint16_t or_port)
-+{
-+  SMARTLIST_FOREACH(or_port_hists, or_port_hist_t *, tp,
-+    {
-+      if (tp->or_port != or_port)
-+        continue;
-+      /*Reset our failure stats so we can notice if this port ever gets
-+        blocked again.*/
-+      tp->success=1;
-+      if (digestmap_size(tp->failure_ids)) {
-+        digestmap_free(tp->failure_ids,NULL);
-+        tp->failure_ids=digestmap_new();
-+      }
-+      if (still_searching) {
-+        still_searching=0;
-+        SMARTLIST_FOREACH(or_port_hists,or_port_hist_t *,t,t->excluded=0;);
-+      }
-+      return;
-+    });
-+}
-+/** Record the failure of our connection to <b>digest</b>'s
-+  * OR port. Warn, exclude the port from future entry guard selection, or
-+  * add port to blocked-ports in our server's extra-info as appropriate. */
-+void
-+or_port_hist_failure(const char *digest, uint16_t or_port)
-+{
-+  int total_failures=0, ports_excluded=0, report_block=0;
-+  int total_routers=smartlist_len(router_get_routerlist()->routers);
-+
-+  SMARTLIST_FOREACH(or_port_hists, or_port_hist_t *, tp,
-+    {
-+      ports_excluded += tp->excluded;
-+      total_failures+=digestmap_size(tp->failure_ids);
-+      if (tp->or_port != or_port)
-+        continue;
-+      /* We're only interested in unique failures */
-+      if (digestmap_get(tp->failure_ids, digest))
-+        return;
-+
-+      total_failures++;
-+      digestmap_set(tp->failure_ids, digest, (void*)1);
-+      if (still_searching && !tp->success) {
-+        tp->excluded=1;
-+        ports_excluded++;
-+      }
-+      if ((digestmap_size(tp->ids) >= POSSIBLY_BLOCKED) &&
-+         !(digestmap_size(tp->failure_ids) % POSSIBLY_BLOCKED))
-+        report_block=POSSIBLY_BLOCKED;
-+    });
-+
-+  if (total_failures >= (int)(total_routers/10))
-+    or_port_hist_report_block(FAILURES_OBSERVED);
-+  else if (report_block)
-+    or_port_hist_report_block(report_block);
-+
-+  if (ports_excluded >= smartlist_len(or_port_hists)) {
-+    log_warn(LD_HIST,"During entry node selection Tor tried every port "
-+             "offered on the network on at least one server "
-+             "and didn't manage a single "
-+             "successful connection. This suggests you are behind an "
-+             "extremely restrictive firewall. Tor will keep trying to find "
-+             "a reachable entry node.");
-+    SMARTLIST_FOREACH(or_port_hists, or_port_hist_t *, tp, tp->excluded=0;);
-+  }
-+}
-+
-+/** Add any ports marked as excluded in or_port_hist_t to <b>rt</b> */
-+void
-+or_port_hist_exclude(routerset_t *rt)
-+{
-+  SMARTLIST_FOREACH(or_port_hists, or_port_hist_t *, tp,
-+    {
-+      char portpolicy[9];
-+      if (tp->excluded) {
-+        tor_snprintf(portpolicy,sizeof(portpolicy),"*:%u", tp->or_port);
-+        log_warn(LD_HIST,"Port %u may be blocked, excluding it temporarily "
-+                          "from entry guard selection.", tp->or_port);
-+        routerset_parse(rt, portpolicy, "Ports");
-+      }
-+    });
-+}
-+
-+/** Allow the exclusion of ports during our search for an entry node. */
-+void
-+or_port_hist_search_again(void)
-+{
-+    still_searching=1;
-+}
-Index: src/or/or.h
-===================================================================
---- src/or/or.h	(revision 17104)
-+++ src/or/or.h	(working copy)
-@@ -3864,6 +3864,13 @@
- int any_predicted_circuits(time_t now);
- int rep_hist_circbuilding_dormant(time_t now);
- 
-+void or_port_hist_failure(const char *digest, uint16_t or_port);
-+void or_port_hist_success(uint16_t or_port);
-+void or_port_hist_new(const routerinfo_t *ri);
-+void or_port_hist_exclude(routerset_t *rt);
-+void or_port_hist_search_again(void);
-+char *or_port_hist_get_blocked_ports(void);
-+
- /** Possible public/private key operations in Tor: used to keep track of where
-  * we're spending our time. */
- typedef enum {
-Index: src/or/routerparse.c
-===================================================================
---- src/or/routerparse.c	(revision 17104)
-+++ src/or/routerparse.c	(working copy)
-@@ -1401,6 +1401,8 @@
-     goto err;
-   }
- 
-+  or_port_hist_new(router);
-+
-   if (!router->platform) {
-     router->platform = tor_strdup("<unknown>");
-   }
-Index: src/or/router.c
-===================================================================
---- src/or/router.c	(revision 17104)
-+++ src/or/router.c	(working copy)
-@@ -1818,6 +1818,7 @@
-   char published[ISO_TIME_LEN+1];
-   char digest[DIGEST_LEN];
-   char *bandwidth_usage;
-+  char *blocked_ports;
-   int result;
-   size_t len;
- 
-@@ -1825,7 +1826,6 @@
-                 extrainfo->cache_info.identity_digest, DIGEST_LEN);
-   format_iso_time(published, extrainfo->cache_info.published_on);
-   bandwidth_usage = rep_hist_get_bandwidth_lines(1);
--
-   result = tor_snprintf(s, maxlen,
-                         "extra-info %s %s\n"
-                         "published %s\n%s",
-@@ -1835,6 +1835,16 @@
-   if (result<0)
-     return -1;
- 
-+  blocked_ports = or_port_hist_get_blocked_ports();
-+  if (blocked_ports) {
-+      result = tor_snprintf(s+strlen(s), maxlen-strlen(s),
-+                            "%s",
-+                            blocked_ports);
-+      tor_free(blocked_ports);
-+      if (result<0)
-+        return -1;
-+  }
-+
-   if (should_record_bridge_info(options)) {
-     static time_t last_purged_at = 0;
-     char *geoip_summary;
-Index: src/or/circuitbuild.c
-===================================================================
---- src/or/circuitbuild.c	(revision 17104)
-+++ src/or/circuitbuild.c	(working copy)
-@@ -62,6 +62,7 @@
- 
- static void entry_guards_changed(void);
- static time_t start_of_month(time_t when);
-+static int num_live_entry_guards(void);
- 
- /** Iterate over values of circ_id, starting from conn-\>next_circ_id,
-  * and with the high bit specified by conn-\>circ_id_type, until we get
-@@ -1627,12 +1628,14 @@
-   smartlist_t *excluded;
-   or_options_t *options = get_options();
-   router_crn_flags_t flags = 0;
-+  routerset_t *_ExcludeNodes;
- 
-   if (state && options->UseEntryGuards &&
-       (purpose != CIRCUIT_PURPOSE_TESTING || options->BridgeRelay)) {
-     return choose_random_entry(state);
-   }
- 
-+  _ExcludeNodes = routerset_new();
-   excluded = smartlist_create();
- 
-   if (state && (r = build_state_get_exit_router(state))) {
-@@ -1670,12 +1673,18 @@
-   if (options->_AllowInvalid & ALLOW_INVALID_ENTRY)
-     flags |= CRN_ALLOW_INVALID;
- 
-+  if (options->ExcludeNodes)
-+    routerset_union(_ExcludeNodes,options->ExcludeNodes);
-+
-+  or_port_hist_exclude(_ExcludeNodes);
-+
-   choice = router_choose_random_node(
-            NULL,
-            excluded,
--           options->ExcludeNodes,
-+           _ExcludeNodes,
-            flags);
-   smartlist_free(excluded);
-+  routerset_free(_ExcludeNodes);
-   return choice;
- }
- 
-@@ -2727,6 +2736,7 @@
- entry_guards_update_state(or_state_t *state)
- {
-   config_line_t **next, *line;
-+  unsigned int have_reachable_entry=0;
-   if (! entry_guards_dirty)
-     return;
- 
-@@ -2740,6 +2750,7 @@
-       char dbuf[HEX_DIGEST_LEN+1];
-       if (!e->made_contact)
-         continue; /* don't write this one to disk */
-+      have_reachable_entry=1;
-       *next = line = tor_malloc_zero(sizeof(config_line_t));
-       line->key = tor_strdup("EntryGuard");
-       line->value = tor_malloc(HEX_DIGEST_LEN+MAX_NICKNAME_LEN+2);
-@@ -2785,6 +2796,11 @@
-   if (!get_options()->AvoidDiskWrites)
-     or_state_mark_dirty(get_or_state(), 0);
-   entry_guards_dirty = 0;
-+
-+  /* XXX: Is this the place to decide that we no longer have any reachable
-+    guards? */
-+  if (!have_reachable_entry)
-+    or_port_hist_search_again();
- }
- 
- /** If <b>question</b> is the string "entry-guards", then dump
-
diff --git a/doc/spec/proposals/157-specific-cert-download.txt b/doc/spec/proposals/157-specific-cert-download.txt
deleted file mode 100644
index e54a987..0000000
--- a/doc/spec/proposals/157-specific-cert-download.txt
+++ /dev/null
@@ -1,104 +0,0 @@
-Filename: 157-specific-cert-download.txt
-Title: Make certificate downloads specific
-Version: $Revision$
-Last-Modified: $Date$
-Author: Nick Mathewson
-Created: 2-Dec-2008
-Status: Accepted
-Target: 0.2.1.x
-
-History:
-
-  2008 Dec 2, 22:34
-     Changed name of cross certification field to match the other authority
-     certificate fields.
-
-Status:
-
-  As of 0.2.1.9-alpha:
-    Cross-certification is implemented for new certificates, but not yet
-    required.  Directories support the tor/keys/fp-sk urls.
-
-Overview:
-
-  Tor's directory specification gives two ways to download a certificate:
-  by its identity fingerprint, or by the digest of its signing key.  Both
-  are error-prone.  We propose a new download mechanism to make sure that
-  clients get the certificates they want.
-
-Motivation:
-
-  When a client wants a certificate to verify a consensus, it has two choices
-  currently:
-     - Download by identity key fingerprint.  In this case, the client risks
-       getting a certificate for the same authority, but with a different
-       signing key than the one used to sign the consensus.
-
-     - Download by signing key fingerprint.  In this case, the client risks
-       getting a forged certificate that contains the right signing key
-       signed with the wrong identity key.  (Since caches are willing to
-       cache certs from authorities they do not themselves recognize, the
-       attacker wouldn't need to compromise an authority's key to do this.)
-
-Current solution:
-
-  Clients fetch by identity keys, and re-fetch with backoff if they don't get
-  certs with the signing key they want.
-
-Proposed solution:
-
-  Phase 1: Add a URL type for clients to download certs by identity _and_
-  signing key fingerprint.  Unless both fields match, the client doesn't
-  accept the certificate(s).  Clients begin using this method when their
-  randomly chosen directory cache supports it.
-
-  Phase 1A: Simultaneously, add a cross-certification element to
-  certificates.
-
-  Phase 2: Once many directory caches support phase 1, clients should prefer
-  to fetch certificates using that protocol when available.
-
-  Phase 2A: Once all authorities are generating cross-certified certificates
-  as in phase 1A, require cross-certification.
-
-Specification additions:
-
-  The key certificate whose identity key fingerprint is <F> and whose signing
-  key fingerprint is <S> should be available at:
-
-      http://<hostname>/tor/keys/fp-sk/<F>-<S>.z
-
-  As usual, clients may request multiple certificates using:
-
-      http://<hostname>/tor/keys/fp-sk/<F1>-<S1>+<F2>-<S2>.z
-
-  Clients SHOULD use this format whenever they know both key fingerprints for
-  a desired certificate.
-
-
-  Certificates SHOULD contain the following field (at most once):
-
-  "dir-key-crosscert" NL CrossSignature NL
-
-  where CrossSignature is a signature, made using the certificate's signing
-  key, of the digest of the PKCS1-padded hash of the certificate's identity
-  key.  For backward compatibility with broken versions of the parser, we
-  wrap the base64-encoded signature in -----BEGIN ID SIGNATURE---- and
-  -----END ID SIGNATURE----- tags.  (See bug 880.) Implementations MUST allow
-  the "ID " portion to be omitted, however.
-
-  When encountering a certificate with a dir-key-crosscert entry,
-  implementations MUST verify that the signature is a correct signature of
-  the hash of the identity key using the signing key.
-
-  (In a future version of this specification, dir-key-crosscert entries will
-  be required.)
-
-Why cross-certify too?
-
-  Cross-certification protects clients who haven't updated yet, by reducing
-  the number of caches that are willing to hold and serve bogus certificates.
-
-References:
-
-  This is related to part 2 of bug 854.
diff --git a/doc/spec/proposals/158-microdescriptors.txt b/doc/spec/proposals/158-microdescriptors.txt
deleted file mode 100644
index f478a3c..0000000
--- a/doc/spec/proposals/158-microdescriptors.txt
+++ /dev/null
@@ -1,207 +0,0 @@
-Filename: 158-microdescriptors.txt
-Title: Clients download consensus + microdescriptors
-Version: $Revision$
-Last-Modified: $Date$
-Author: Roger Dingledine
-Created: 17-Jan-2009
-Status: Open
-
-1. Overview
-
-  This proposal replaces section 3.2 of proposal 141, which was
-  called "Fetching descriptors on demand". Rather than modifying the
-  circuit-building protocol to fetch a server descriptor inline at each
-  circuit extend, we instead put all of the information that clients need
-  either into the consensus itself, or into a new set of data about each
-  relay called a microdescriptor. The microdescriptor is a direct
-  transform from the relay descriptor, so relays don't even need to know
-  this is happening.
-
-  Descriptor elements that are small and frequently changing should go
-  in the consensus itself, and descriptor elements that are small and
-  relatively static should go in the microdescriptor. If we ever end up
-  with descriptor elements that aren't small yet clients need to know
-  them, we'll need to resume considering some design like the one in
-  proposal 141.
-
-2. Motivation
-
-  See
-  http://archives.seul.org/or/dev/Nov-2008/msg00000.html and
-  http://archives.seul.org/or/dev/Nov-2008/msg00001.html and especially
-  http://archives.seul.org/or/dev/Nov-2008/msg00007.html
-  for a discussion of the options and why this is currently the best
-  approach.
-
-3. Design
-
-  There are three pieces to the proposal. First, authorities will list in
-  their votes (and thus in the consensus) what relay descriptor elements
-  are included in the microdescriptor, and also list the expected hash
-  of microdescriptor for each relay. Second, directory mirrors will serve
-  microdescriptors. Third, clients will ask for them and cache them.
-
-3.1. Consensus changes
-
-  V3 votes should include a new line:
-    microdescriptor-elements bar baz foo
-  listing each descriptor element (sorted alphabetically) that authority
-  included when it calculated its expected microdescriptor hashes.
-
-  We also need to include the hash of each expected microdescriptor in
-  the routerstatus section. I suggest a new "m" line for each stanza,
-  with the base64 of the hash of the elements that the authority voted
-  for above.
-
-  The consensus microdescriptor-elements and "m" lines are then computed
-  as described in Section 3.1.2 below.
-
-  I believe that means we need a new consensus-method "6" that knows
-  how to compute the microdescriptor-elements and add "m" lines.
-
-3.1.1. Descriptor elements to include for now
-
-  To start, the element list that authorities suggest should be
-    family onion-key
-
-  (Note that the or-dev posts above only mention onion-key, but if
-  we don't also include family then clients will never learn it. It
-  seemed like it should be relatively static, so putting it in the
-  microdescriptor is smarter than trying to fit it into the consensus.)
-
-  We could imagine a config option "family,onion-key" so authorities
-  could change their voted preferences without needing to upgrade.
-
-3.1.2. Computing consensus for microdescriptor-elements and "m" lines
-
-  One approach is for the consensus microdescriptor-elements line to
-  include every element listed by a majority of authorities, sorted. The
-  problem here is that it will no longer be deterministic what the correct
-  hash for the "m" line should be. We could imagine telling the authority
-  to go look in its descriptor and produce the right hash itself, but
-  we don't want consensus calculation to be based on external data like
-  that. (Plus, the authority may not have the descriptor that everybody
-  else voted to use.)
-
-  The better approach is to take the exact set that has the most votes
-  (breaking ties by the set that has the most elements, and breaking
-  ties after that by whichever is alphabetically first). That will
-  increase the odds that we actually get a microdescriptor hash that
-  is both a) for the descriptor we're putting in the consensus, and b)
-  over the elements that we're declaring it should be for.
-
-  Then the "m" line for a given relay is the one that gets the most votes
-  from authorities that both a) voted for the microdescriptor-elements
-  line we're using, and b) voted for the descriptor we're using.
-
-  (If there's a tie, use the smaller hash. But really, if there are
-  multiple such votes and they differ about a microdescriptor, we caught
-  one of them lying or being buggy. We should log it to track down why.)
-
-  If there are no such votes, then we leave out the "m" line for that
-  relay. That means clients should avoid it for this time period. (As
-  an extension it could instead mean that clients should fetch the
-  descriptor and figure out its microdescriptor themselves. But let's
-  not get ahead of ourselves.)
-
-  It would be nice to have a more foolproof way to agree on what
-  microdescriptor hash each authority should vote for, so we can avoid
-  missing "m" lines. Just switching to a new consensus-method each time
-  we change the set of microdescriptor-elements won't help though, since
-  each authority will still have to decide what hash to vote for before
-  knowing what consensus-method will be used.
-
-  Here's one way we could do it. Each vote / consensus includes
-  the microdescriptor-elements that were used to compute the hashes,
-  and also a preferred-microdescriptor-elements set. If an authority
-  has a consensus from the previous period, then it should use the
-  consensus preferred-microdescriptor-elements when computing its votes
-  for microdescriptor-elements and the appropriate hashes in the upcoming
-  period. (If it has no previous consensus, then it just writes its
-  own preferences in both lines.)
-
-3.2. Directory mirrors serve microdescriptors
-
-  Directory mirrors should then read the microdescriptor-elements line
-  from the consensus, and learn how to answer requests. (Directory mirrors
-  continue to serve normal relay descriptors too, a) to serve old clients
-  and b) to be able to construct microdescriptors on the fly.)
-
-  The microdescriptors with hashes <D1>,<D2>,<D3> should be available at:
-    http://<hostname>/tor/micro/d/<D1>+<D2>+<D3>.z
-
-  All the microdescriptors from the current consensus should also be
-  available at:
-    http://<hostname>/tor/micro/all.z
-  so a client that's bootstrapping doesn't need to send a 70KB URL just
-  to name every microdescriptor it's looking for.
-
-  The format of a microdescriptor is the header line
-  "microdescriptor-header"
-  followed by each element (keyword and body), alphabetically. There's
-  no need to mention what hash it's for, since it's self-identifying:
-  you can hash the elements to learn this.
-
-  (Do we need a footer line to show that it's over, or is the next
-  microdescriptor line or EOF enough of a hint? A footer line wouldn't
-  hurt much. Also, no fair voting for the microdescriptor-element
-  "microdescriptor-header".)
-
-  The hash of the microdescriptor is simply the hash of the concatenated
-  elements -- not counting the header line or hypothetical footer line.
-  Unless you prefer that?
-
-  Is there a reasonable way to version these things? We could say that
-  the microdescriptor-header line can contain arguments which clients
-  must ignore if they don't understand them. Any better ways?
-
-  Directory mirrors should check to make sure that the microdescriptors
-  they're about to serve match the right hashes (either the hashes from
-  the fetch URL or the hashes from the consensus, respectively).
-
-  We will probably want to consider some sort of smart data structure to
-  be able to quickly convert microdescriptor hashes into the appropriate
-  microdescriptor. Clients will want this anyway when they load their
-  microdescriptor cache and want to match it up with the consensus to
-  see what's missing.
-
-3.3. Clients fetch them and cache them
-
-  When a client gets a new consensus, it looks to see if there are any
-  microdescriptors it needs to learn. If it needs to learn more than
-  some threshold of the microdescriptors (half?), it requests 'all',
-  else it requests only the missing ones.
-
-  Clients maintain a cache of microdescriptors along with metadata like
-  when it was last referenced by a consensus. They keep a microdescriptor
-  until it hasn't been mentioned in any consensus for a week. Future
-  clients might cache them for longer or shorter times.
-
-3.3.1. Information leaks from clients
-
-  If a client asks you for a set of microdescs, then you know she didn't
-  have them cached before. How much does that leak? What about when
-  we're all using our entry guards as directory guards, and we've seen
-  that user make a bunch of circuits already?
-
-  Fetching "all" when you need at least half is a good first order fix,
-  but might not be all there is to it.
-
-  Another future option would be to fetch some of the microdescriptors
-  anonymously (via a Tor circuit).
-
-4. Transition and deployment
-
-  Phase one, the directory authorities should start voting on
-  microdescriptors and microdescriptor elements, and putting them in the
-  consensus. This should happen during the 0.2.1.x series, and should
-  be relatively easy to do.
-
-  Phase two, directory mirrors should learn how to serve them, and learn
-  how to read the consensus to find out what they should be serving. This
-  phase could be done either in 0.2.1.x or early in 0.2.2.x, depending
-  on how messy it turns out to be and how quickly we get around to it.
-
-  Phase three, clients should start fetching and caching them instead
-  of normal descriptors. This should happen post 0.2.1.x.
-
diff --git a/doc/spec/proposals/159-exit-scanning.txt b/doc/spec/proposals/159-exit-scanning.txt
deleted file mode 100644
index fbc69aa..0000000
--- a/doc/spec/proposals/159-exit-scanning.txt
+++ /dev/null
@@ -1,144 +0,0 @@
-Filename: 159-exit-scanning.txt
-Title: Exit Scanning
-Version: $Revision$
-Last-Modified: $Date$
-Author: Mike Perry
-Created: 13-Feb-2009
-Status: Open
-
-Overview:
-
-This proposal describes the implementation and integration of an
-automated exit node scanner for scanning the Tor network for malicious,
-misconfigured, firewalled or filtered nodes.
-
-Motivation:
-
-Tor exit nodes can be run by anyone with an Internet connection. Often,
-these users aren't fully aware of limitations of their networking
-setup.  Content filters, antivirus software, advertisements injected by
-their service providers, malicious upstream providers, and the resource
-limitations of their computer or networking equipment have all been
-observed on the current Tor network.
-
-It is also possible that some nodes exist purely for malicious
-purposes.  In the past, there have been intermittent instances of
-nodes spoofing SSH keys, as well as nodes being used for purposes of
-plaintext surveillance.
-
-While it is not realistic to expect to catch extremely targeted or
-completely passive malicious adversaries, the goal is to prevent
-malicious adversaries from deploying dragnet attacks against large
-segments of the Tor userbase.
-
-
-Scanning methodology:
-
-The first scans to be implemented are HTTP, HTML, Javascript, and
-SSL scans.
-
-The HTTP scan scrapes Google for common filetype urls such as exe, msi,
-doc, dmg, etc. It then fetches these urls through Non-Tor and Tor, and
-compares the SHA1 hashes of the resulting content.
-
-The SSL scan downloads certificates for all IPs a domain will locally
-resolve to and compares these certificates to those seen over Tor. The
-scanner notes if a domain had rotated certificates locally in the
-results for each scan.
-
-The HTML scan checks HTML, Javascript, and plugin content for
-modifications. Because of the dynamic nature of most of the web, the
-scanner has a number of mechanisms built in to filter out false
-positives that are used when a change is noticed between Tor and
-Non-Tor.
-
-All tests also share a URL-based false positive filter that
-automatically removes results retroactively if the number of failures
-exceeds a certain percentage of nodes tested with the URL.
-
-
-Deployment Stages:
-
-To avoid instances where bugs cause us to mark exit nodes as BadExit
-improperly, it is proposed that we begin use of the scanner in stages.
-
-1. Manual Review:
-
-  In the first stage, basic scans will be run by a small number of
-  people while we stabilize the scanner. The scanner has the ability
-  to resume crashed scans, and to rescan nodes that fail various
-  tests.
-
-2. Human Review:
-
-  In the second stage, results will be automatically mailed to
-  an email list of interested parties for review. We will also begin
-  classifying failure types into three to four different severity
-  levels, based on both the reliability of the test and the nature of
-  the failure.
-
-3. Automatic BadExit Marking:
-
-  In the final stage, the scanner will begin marking exits depending
-  on the failure severity level in one of three different ways: by
-  node idhex, by node IP, or by node IP mask. A potential fourth, less
-  severe category of results may still be delivered via email only for
-  review.
-
-  BadExit markings will be delivered in batches upon completion
-  of whole-network scans, so that the final false positive
-  filter has an opportunity to filter out URLs that exhibit
-  dynamic content beyond what we can filter.
-
-
-Specification of Exit Marking:
-
-Technically, BadExit could be marked via SETCONF AuthDirBadExit over
-the control port, but this would allow full access to the directory
-authority configuration and operation.
-
-The approved-routers file could also be used, but currently it only
-supports fingerprints, and it also contains other data unrelated to
-exit scanning that would be difficult to coordinate.
-
-Instead, we propose that a new badexit-routers file that has three
-keywords:
-
-  BadExitNet 1*[exitpattern from 2.3 in dir-spec.txt]
-  BadExitFP 1*[hexdigest from 2.3 in dir-spec.txt]
-
-BadExitNet lines would follow the codepaths used by AuthDirBadExit to
-set authdir_badexit_policy, and BadExitFP would follow the codepaths
-from approved-router's !badexit lines.
-
-The scanner would have exclusive ability to write, append, rewrite,
-and modify this file. Prior to building a new consensus vote, a
-participating Tor authority would read in a fresh copy.
-
-
-Security Implications:
-
-Aside from evading the scanner's detection, there are two additional
-high-level security considerations:
-
-1. Ensure nodes cannot be marked BadExit by an adversary at will
-
-It is possible individual website owners will be able to target certain
-Tor nodes, but once they begin to attempt to fail more than the URL
-filter percentage of the exits, their sites will be automatically
-discarded.
-
-Failing specific nodes is possible, but scanned results are fully
-reproducible, and BadExits should be rare enough that humans are never
-fully removed from the loop.
-
-State (cookies, cache, etc) does not otherwise persist in the scanner
-between exit nodes to enable one exit node to bias the results of a
-later one.
-
-2. Ensure that scanner compromise does not yield authority compromise
-
-Having a separate file that is under the exclusive control of the
-scanner allows us to heavily isolate the scanner from the Tor
-authority, potentially even running them on separate machines.
-
diff --git a/doc/spec/proposals/ideas/xxx-auto-update.txt b/doc/spec/proposals/ideas/xxx-auto-update.txt
deleted file mode 100644
index dc9a857..0000000
--- a/doc/spec/proposals/ideas/xxx-auto-update.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-
-Notes on an auto updater:
-
-steve wants a "latest" symlink so he can always just fetch that.
-
-roger worries that this will exacerbate the "what version are you
-using?" "latest." problem.
-
-weasel suggests putting the latest recommended version in dns. then
-we don't have to hit the website. it's got caching, it's lightweight,
-it scales. just put it in a TXT record or something.
-
-but, no dnssec.
-
-roger suggests a file on the https website that lists the latest
-recommended version (or filename or url or something like that).
-
-(steve seems to already be doing this with xerobank. he additionally
-suggests a little blurb that can be displayed to the user to describe
-what's new.)
-
-how to verify you're getting the right file?
-a) it's https.
-b) ship with a signing key, and use some openssl functions to verify.
-c) both
-
-andrew reminds us that we have a "recommended versions" line in the
-consensus directory already.
-
-if only we had some way to point out the "latest stable recommendation"
-from this list. we could list it first, or something.
-
-the recommended versions line also doesn't take into account which
-packages are available -- e.g. on Windows one version might be the best
-available, and on OS X it might be a different one.
-
-aren't there existing solutions to this? surely there is a beautiful,
-efficient, crypto-correct auto updater lib out there. even for windows.
-
diff --git a/doc/spec/proposals/ideas/xxx-bridge-disbursement.txt b/doc/spec/proposals/ideas/xxx-bridge-disbursement.txt
deleted file mode 100644
index 6c9a3c7..0000000
--- a/doc/spec/proposals/ideas/xxx-bridge-disbursement.txt
+++ /dev/null
@@ -1,174 +0,0 @@
-
-How to hand out bridges.
-
-Divide bridges into 'strategies' as they come in.  Do this uniformly
-at random for now.
-
-For each strategy, we'll hand out bridges in a different way to
-clients.  This document describes two strategies: email-based and
-IP-based.
-
-0. Notation:
-
-   HMAC(k,v) : an HMAC of v using the key k.
-
-   A|B: The string A concatenated with the string B.
-
-
-1. Email-based.
-
-  Goal: bootstrap based on one or more popular email service's sybil
-     prevention algorithms.
-
-
-  Parameters:
-     HMAC -- an HMAC function
-     P -- a time period
-     K -- the number of bridges to send in a period.
-
-  Setup: Generate two nonces, N and M.
-
-  As bridges arrive, put them into a ring according to HMAC(N,ID)
-  where ID is the bridges's identity digest.
-
-  Divide time into divisions of length P.
-
-  When we get an email:
-
-     If it's not from a supported email service, reject it.
-
-     If we already sent a response to that email address (normalized)
-     in this period, send _exactly_ the same response.
-
-     If it is from a supported service, generate X = HMAC(M,PS|E) where E
-     is the lowercased normalized email address for the user, and
-     where PS is the start of the currrent period.  Send
-     the first K bridges in the ring after point X.
-
-     [If we want to make sure that repeat queries are given exactly the
-      same results, then we can't let the ring change during the
-      time period. For a long time period like a month, that's quite a
-      hassle. How about instead just keeping a replay cache of addresses
-      that have been answered, and sending them a "sorry, you already got
-      your addresses for the time period; perhaps you should try these
-      other fine distribution strategies while you wait?" response? This
-      approach would also resolve the "Make sure you can't construct a
-      distinct address to match an existing one" note below. -RD]
-
-        [I think, if we get a replay, we need to send back the same
-        answer as we did the first time, not say "try again."
-        Otherwise we need to worry that an attacker can keep people
-        from getting bridges by preemtively asking for them,
-        or that an attacker may force them to prove they haven't
-        gotten any bridges by asking. -NM]
-
-     [While we're at it, if we do the replay cache thing and don't need
-      repeatable answers, we could just pick K random answers from the
-      pool. Is it beneficial that a bridge user who knows about a clump of
-      nodes will be sharing them with other users who know about a similar
-      (overlapping) clump? One good aspect is against an adversary who
-      learns about a clump this way and watches those bridges to learn
-      other users and discover *their* bridges: he doesn't learn about
-      as many new bridges as he might if they were randomly distributed.
-      A drawback is against an adversary who happens to pick two email
-      addresses in P that include overlapping answers: he can measure
-      the difference in clumps and estimate how quickly the bridge pool
-      is growing. -RD]
-
-        [Random is one more darn thing to implement; rings are already
-         there. -NM]
-
-     [If we make the period P be mailbox-specific, and make it a random
-      value around some mean, then we make it harder for an attacker to
-      know when to try using his small army of gmail addresses to gather
-      another harvest. But we also make it harder for users to know when
-      they can try again. -RD]
-
-        [Letting the users know about when they can try again seems
-         worthwhile.  Otherwise users and attackers will all probe and
-         probe and probe until they get an answer.  No additional
-         security will be achieved, but bandwidth will be lost. -NM]
-
-  To normalize an email address:
-     Start with the RFC822 address.  Consider only the mailbox {???}
-     portion of the address (username@domain).  Put this into lowercase
-     ascii.
-
-  Questions:
-     What to do with weird character encodings?  Look up the RFC.
-
-  Notes:
-     Make sure that you can't force a single email address to appear
-     in lots of different ways.  IOW, if nickm@xxxxxxxxxxxxx and
-     NICKM@xxxxxxxxxxxxx aren't treated the same, then I can get lots
-     more bridges than I should.
-
-     Make sure you can't construct a distinct address to match an
-     existing one.  IOW, if we treat nickm@X and nickm@Y as the same
-     user, then anybody can register nickm@Z and use it to tell which
-     bridges nickm@X got (or would get).
-
-     Make sure that we actually check headers so we can't be trivially
-     used to spam people.
-
-
-2. IP-based.
-
-  Goal: avoid handing out all the bridges to users in a similar IP
-  space and time.
-
-  Parameters:
-
-     T_Flush -- how long it should take a user on a single network to
-        see a whole cluster of bridges.
-
-     N_C
-
-     K -- the number of bridges we hand out in response to a single
-     request.
-
-  Setup: using an AS map or a geoip map or some other flawed input
-  source, divide IP space into "areas" such that surveying a large
-  collection of "areas" is hard.  For v0, use /24 address blocks.
-
-  Group areas into N_C clusters.
-
-  Generate secrets L, M, N.
-
-  Set the period P such that P*(bridges-per-cluster/K) = T_flush.
-  Don't set P to greater than a week, or less than three hours.
-
-  When we get a bridge:
-
-     Based on HMAC(L,ID), assign the bridge to a cluster.  Within each
-     cluster, keep the bridges in a ring based on HMAC(M,ID).
-
-     [Should we re-sort the rings for each new time period, so the ring
-      for a given cluster is based on HMAC(M,PS|ID)? -RD]
-
-  When we get a connection:
-
-     If it's http, redirect it to https.
-
-     Let area be the incoming IP network.  Let PS be the current
-     period.  Compute X = HMAC(N, PS|area).  Return the next K bridges
-     in the ring after X.
-
-     [Don't we want to compute C = HMAC(key, area) to learn what cluster
-      to answer from, and then X = HMAC(key, PS|area) to pick a point in
-      that ring? -RD]
-
-
-  Need to clarify that some HMACs are for rings, and some are for
-  partitions. How rings scale is clear. How do we grow the number of
-  partitions? Looking at successive bits from the HMAC output is one way.
-
-3. Open issues
-
-   Denial of service attacks
-   A good view of network topology
-
-at some point we should learn some reliability stats on our bridges. when
-we say above 'give out k bridges', we might give out 2 reliable ones and
-k-2 others. we count around the ring the same way we do now, to find them.
-
diff --git a/doc/spec/proposals/ideas/xxx-controllers-intercept-extends.txt b/doc/spec/proposals/ideas/xxx-controllers-intercept-extends.txt
deleted file mode 100644
index 76ba5c8..0000000
--- a/doc/spec/proposals/ideas/xxx-controllers-intercept-extends.txt
+++ /dev/null
@@ -1,44 +0,0 @@
-Author: Geoff Goodell
-Title: Allow controller to manage circuit extensions
-Date: 12 March 2006
-
-History:
-
-  This was once bug 268.  Moving it into the proposal system for posterity.
-
-Test:
-
-Tor controllers should have a means of learning more about circuits built
-through Tor routers.  Specifically, if a Tor controller is connected to a Tor
-router, it should be able to subscribe to a new class of events, perhaps
-"onion" or "router" events.  A Tor router SHOULD then ensure that the
-controller is informed:
-
-(a) (NEW) when it receives a connection from some other location, in which
-case it SHOULD indicate (1) a unique identifier for the circuit, and (2) a
-ServerID in the event of an OR connection from another Tor router, and
-Hostname otherwise.
-
-(b) (REQUEST) when it receives a request to extend an existing circuit to a
-successive Tor router, in which case it SHOULD provide (1) the unique
-identifier for the circuit, (2) a Hostname (or, if possible, ServerID) of the
-previous Tor router in the circuit, and (3) a ServerID for the requested
-successive Tor router in the circuit;
-
-(c) (EXTEND) Tor will attempt to extend the circuit to some other router, in
-which case it SHOULD provide the same fields as provided for REQUEST.
-
-(d) (SUCCEEDED) The circuit has been successfully extended to some ther
-router, in which case it SHOULD provide the same fields as provided for
-REQUEST.
-
-We also need a new configuration option analogous to _leavestreamsunattached,
-specifying whether the controller is to manage circuit extensions or not.
-Perhaps we can call it "_leavecircuitsunextended".  When set to 0, Tor
-manages everything as usual.  When set to 1, a circuit received by the Tor
-router cannot transition from "REQUEST" to "EXTEND" state without being
-directed by a new controller command.  The controller command probably does
-not need any arguments, since circuits are extended per client source
-routing, and all that the controller does is accept or reject the extension.
-
-This feature can be used as a basis for enforcing routing policy.
diff --git a/doc/spec/proposals/ideas/xxx-exit-scanning-outline.txt b/doc/spec/proposals/ideas/xxx-exit-scanning-outline.txt
deleted file mode 100644
index d840944..0000000
--- a/doc/spec/proposals/ideas/xxx-exit-scanning-outline.txt
+++ /dev/null
@@ -1,44 +0,0 @@
-1. Scanning process
-   A. Non-HTML/JS HTTP mime types compared via SHA1 hash
-   B. Dynamic HTTP content filtered at 4 levels:
-      1. IP change+Tor cookie utilization
-         - Tor cookies replayed with new IP in case of changes
-      2. HTML Tag+Attribute+JS comparison
-         - Comparisons made based only on "relevant" HTML tags
-           and attributes 
-      3. HTML Tag+Attribute+JS diffing
-         - Tags, attributes and JS AST nodes that change during
-           Non-Tor fetches pruned from comparison
-      4. URLS with > N% of node failures removed
-         - results purged from filesystem at end of scan loop
-   C. SSL scanning handles some forms of dynamic certs
-      1. Catalogs certs for all IPs resolved locally
-         by getaddrinfo over the duration of the scan. 
-         - Updated each test.
-      2. If the domain presents a new cert for each IP, this
-         is noted on the failure result for the node
-      3. If the same IP presents two different certs locally,
-         the cert list is first refreshed, and if it happens
-         again, discarded
-      4. A N% node failure filter also applies
-   D. Scanner can be restarted from any point in the event
-      of scanner or system crashes, or graceful shutdown.
-      - Results+scan state pickled to filesystem continuously
-2. Cron job checks results periodically for reporting
-   A. Divide failures into three types of BadExit based on type
-      and frequency over time and incident rate
-   B. write reject lines to approved-routers for those three types:
-      1. ID Hex based (for misconfig/network problems easily fixed)
-      2. IP based (for content modification)
-      3. IP+mask based (for continuous/egregious content modification)
-   C. Emails results to tor-scanners@xxxxxxxxxxxxx
-3. Human Review and Appeal
-   A. ID Hex-based BadExit is meant to be possible to removed easily
-      without needing to beg us.
-      - Should this behavior be encouraged? 
-   B. Optionally can reserve IP based badexits for human review
-      1. Results are encapsulated fully on the filesystem and can be
-         reviewed without network access
-      2. Soat has --rescan to rescan failed nodes from a data directory
-         - New set of URLs used
-
diff --git a/doc/spec/proposals/ideas/xxx-geoip-survey-plan.txt b/doc/spec/proposals/ideas/xxx-geoip-survey-plan.txt
deleted file mode 100644
index 49c6615..0000000
--- a/doc/spec/proposals/ideas/xxx-geoip-survey-plan.txt
+++ /dev/null
@@ -1,137 +0,0 @@
-
-
-Abstract
-
-   This document explains how to tell about how many Tor users there
-   are, and how many there are in which country.  Statistics are
-   involved.
-
-Motivation
-
-   There are a few reasons we need to keep track of which countries
-   Tor users (in aggregate) are coming from:
-
-      - Resource allocation.  Knowing about underserved countries with
-        lots of users can let us know about where we need to direct
-        translation and outreach efforts.
-
-      - Anticensorship.  Sudden drops in usage on a national basis can
-        indicate the arrival of a censorious firewall.
-
-      - Sponsor outreach and self-evalutation.  Many people and
-        organizations who are interested in funding The Tor Project's
-        work want to know that we're successfully serving parts of the
-        world they're interested in, and that efforts to expand our
-        userbase are actually succeeding.  So do we.
-
-Goals
-
-   We want to know approximately how many Tor users there are, and which
-   countries they're in, even in the presence of a hypothetical
-   "directory guard" feature.  Some uncertainty is okay, but we'd like
-   to be able to put a bound on the uncertainty.
-
-   We need to make sure this information isn't exposed in a way that
-   helps an adversary.
-
-Methods for current clients:
-
-   Every client downloads network status documents.  There are
-   currently three methods (one hypothetical) for clients to get them.
-      - 0.1.2.x clients (and earlier) fetch a v2 networkstatus
-        document about every NETWORKSTATUS_CLIENT_DL_INTERVAL [30
-        minutes].
-
-      - 0.2.0.x clients fetch a v3 networkstatus consensus document
-        at a random interval between when their current document is no
-        longer freshest, and when their current document is about to
-        expire.
-
-        [In both of the above cases, clients choose a running
-        directory cache at random with odds roughly proportional to
-        its bandwidth.  If they're just starting, they know a XXXX FIXME -NM]
-
-      - In some future version, clients will choose directory caches
-        to serve as their "directory guards" to avoid profiling
-        attacks, similarly to how clients currently start all their
-        circuits at guard nodes.
-
-    We assume that a directory cache can tell which of these three
-    categories a client is in by the format of its status request.
-
-    A directory cache can be made to count distinct client IP
-    addresses that make a certain request of it in a given timeframe,
-    and total requests made to it over that timeframe.  For the first
-    two cases, a cache can get a  picture of the overall
-    number and countries of users in the network by dividing the IP
-    count by the probability with which they (as a cache) would be
-    chosen.  Assuming that our listed bandwidth is such that we expect
-    to be chosen with probability P for any given request, and we've
-    been counting IPs for long enough that we expect the average
-    client to have made N requests, they will have visited us at least
-    once with probability P' = 1-(1-P)^N, and so we divide the IP
-    counts we've seen by P' for our estimate.  To estimate total
-    number of clients of a given type, determine how many requests a
-    client of that type will make over that time, and assume we'll
-    have seen P of them.
-
-    Both of these numbers are useful: the IP counts will give the
-    total number of IPs connecting to the network, and the request
-    counts will give the total number of users on the network at any
-    given time.
-
-    Notes:
-       - [Over H hours, the N for V2 clients is 2*H, and the N for V3
-         clients is currently around H/2 or H/3.]
-
-       - (We should only count requests that we actually intend to answer;
-         503 requests shouldn't count.)
-
-       - These measurements should also be taken at a directory
-         authority if possible: their picture of the network is skewed
-         by clients that fetch from them directly.  These clients,
-         however, are all the clients that are just bootstrapping
-         (assuming that the fallback-consensus feature isn't yet used
-         much).
-
-       - These measurements also overestimate the V2 download rate if
-         some downloads fail and clients retry them later after backing
-         off.
-
-Methods for directory guards:
-
-    If directory guards are in use, directory guards get a picture of
-    all those users who chose them as a guard when they were listed
-    as a good choice for a guard, and who are also on the network
-    now.  The cleanest data here will come from nodes that were listed
-    as good new-guards choices for a while, and have not been so for a
-    while longer (to study decay rates); nodes that have been listed
-    as good new-guard choices consistently for a long time (to get a
-    sample of the network); and nodes that have been listed as good
-    new-guard choices only recently (to get a sample of new users and
-    users whose guards have died out.)
-
-    Since directory guards are currently unspecified, we'll need to
-    make some guesses about how they'll turn out to work.  Here are
-    a couple of approaches that could work.
-       - We could have clients pick completely new directory guards on
-         a rolling basis every two months or so.  This would ensure
-         that staying as a guard for a while would be sufficient to
-         see a sample of users.  This is potentially advantageous for
-         load-balancing the network as well, though it might lose some
-         of the benefits of directory guard.  We need to quantify the
-         impact of this; it might not actually make stuff worse in
-         practice, if most guards don't stay good guards for a month
-         or two.
-
-       - We could try to collect statistics at several directory
-         guards and combine their statisics, but we would need to make
-         sure that for all time, at least one of the directory guards
-         had been recommended as a good choice for new guards.  By
-         looking at new-IP rates for guards, we could get an idea of
-         user uptake; for looking at old-IP decay rates, we could get
-         an idea of turnover.  This approach would entail significant
-         complexity, and we'd probably need to record more information
-         than we'd really like to.
-
-
diff --git a/doc/spec/proposals/ideas/xxx-grand-scaling-plan.txt b/doc/spec/proposals/ideas/xxx-grand-scaling-plan.txt
deleted file mode 100644
index 336798c..0000000
--- a/doc/spec/proposals/ideas/xxx-grand-scaling-plan.txt
+++ /dev/null
@@ -1,97 +0,0 @@
-
-Right now as I understand it, there are n big scaling problems heading
-our way:
-
-1) Clients need to learn all the relay descriptors they could use. That's
-a lot of bytes through a potentially small pipe.
-2) Relays need to hold open TCP connections to most other relays.
-3) Clients need to learn the whole networkstatus. Even using v3, as
-the network grows that will become unwieldy.
-4) Dir mirrors need to mirror all the relay descriptors; eventually this
-will get big too.
-
-Here's my plan.
-
---------------------------------------------------------------------
-
-Piece one: download O(1) descriptors rather than O(n) descriptors.
-
-We need to change our circuit extend protocol so it fetches a relay
-descriptor at every 'extend' operation:
-  - Client fetches networkstatus, picks guards, connects to one.
-  - Client picks middle hop out of networkstatus, asks guard for
-    its descriptor, then extends to it.
-  - Clients picks exit hop out of networkstatus, asks middle hop
-    for its descriptor, then extends to it. Done.
-
-The client needs to ask for the descriptor even if it already has a
-copy, because otherwise we leak too much. Also, the descriptor needs to
-be padded to some large (but not too large) size to prevent the middle
-hops from guessing about it.
-
-The first step towards this is to instrument the current code to see
-how much of a win this would actually be -- I am guessing it is already
-a win even with the current number of descriptors.
-
-We also would need to assign the 'Exit' flag more usefully, and make
-clients pay attention to it when picking their last hop, since they
-don't actually know the exit policies of the relays they're choosing from.
-
-We also need to think harder about other implications -- for example,
-a relay with a tiny exit policy won't get the Exit flag, and thus won't
-ever get picked as an exit relay. Plus, our "enclave exit" model is out
-the window unless we figure out a cool trick.
-
-More generally, we'll probably want to compress the descriptors that we
-send back; maybe 8k is a good upper bound? I wonder if we could ask for
-several descriptors, and bundle back all of the ones that fit in the 8k?
-
-We'd also want to put the load balancing weights into the networkstatus,
-so clients can choose fast nodes more often without needing to see the
-descriptors. This is a good opportunity for the authorities to be able
-to put "more accurate" weights in if they learn to detect attacks. It
-also means we should consider running automated audits to make sure the
-authorities aren't trying to snooker everybody.
-
-I'm aiming to get Peter Palfrader to tackle this problem in mid 2008,
-but I bet he could use some help.
-
---------------------------------------------------------------------
-
-Piece two: inter-relay communication uses UDP
-
-If relays send packets to/from other relays via UDP, they don't need a
-new descriptor for each such link. Thus we'll still need to keep state
-for each link, but we won't max out on sockets.
-
-Clearly a lot more work needs to be done here. Ian Goldberg has a student
-who has been working on it, and if all goes well we'll be chipping in
-some funding to continue that. Also, Camilo Viecco has been doing his
-PhD thesis on it.
-
---------------------------------------------------------------------
-
-Piece three: networkstatus documents get partitioned
-
-While the authorities should be expected to be able to handle learning
-about all the relays, there's no reason the clients or the mirrors need
-to. Authorities should put a cap on the number of relays listed in a
-single networkstatus, and split them when they get too big.
-
-We'd need a good way to have each authority come to the same conclusion
-about which partition a given relay goes into.
-
-Directory mirrors would then mirror all the relay descriptors in their
-partition. This is compatible with 'piece one' above, since clients in
-a given partition will only ask about descriptors in that partition.
-
-More complex versions of this design would involve overlapping partitions,
-but that would seem to start contradicting other parts of this proposal
-right quick.
-
-Nobody is working on this piece yet. It's hard to say when we'll need
-it, but it would be nice to have some more thought on it before the week
-that we need it.
-
---------------------------------------------------------------------
-
diff --git a/doc/spec/proposals/ideas/xxx-hide-platform.txt b/doc/spec/proposals/ideas/xxx-hide-platform.txt
deleted file mode 100644
index 3fed5cf..0000000
--- a/doc/spec/proposals/ideas/xxx-hide-platform.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-Filename: xxx-hide-platform.txt
-Title: Hide Tor Platform Information
-Version: $Revision$
-Last-Modified: $Date$
-Author: Jacob Appelbaum 
-Created: 24-July-2008
-Status: Draft
-
-
-                      Hiding Tor Platform Information
-
-0.0 Introduction
-
-The current Tor program publishes its specific Tor version and related OS
-platform information. This information could be misused by an attacker.
-
-0.1 Current Implementation
-
-Currently, the Tor binary sends data that looks like the following:
-
-    Tor 0.2.0.26-rc (r14597) on Darwin Power Macintosh
-    Tor 0.1.2.19 on Windows XP Service Pack 3 [workstation] {terminal services,
-    single user}
-
-1.0 Suggested changes
-
-It would be useful to allow a user to configure the disclosure of such
-information. Such a change would be an option in the torrc file like so:
-
-    HidePlatform Yes
-
-1.1 Suggested default behavior in the future
-
-If a user would like to disclose this information, they could configure their
-Tor to do so.
-
-    HidePlatform No
-
-
diff --git a/doc/spec/proposals/ideas/xxx-port-knocking.txt b/doc/spec/proposals/ideas/xxx-port-knocking.txt
deleted file mode 100644
index 9fbcdf3..0000000
--- a/doc/spec/proposals/ideas/xxx-port-knocking.txt
+++ /dev/null
@@ -1,93 +0,0 @@
-Filename: xxx-port-knocking.txt
-Title: Port knocking for bridge scanning resistance
-Version: $Revision$
-Last-Modified: $Date$
-Author: Jacob Appelbaum
-Created: 19-April-2009
-Status: Draft
-
-            Port knocking for bridge scanning resistance
-
-0.0 Introduction
-
-This document is a collection of ideas relating to improving scanning
-resistance for private bridge relays. This is intented to stop opportunistic
-network scanning and subsequent discovery of private bridge relays.
-
-
-0.1 Current Implementation
-
-Currently private bridges are only hidden by their obscurity. If you know
-a bridge ip address, the bridge can be detected trivially and added to a block
-list.
-
-0.2 Configuring an external port knocking program to control the firewall
-
-It is currently possible for bridge operators to configure a port knocking
-daemon that controls access to the incoming OR port. This is currently out of
-scope for Tor and Tor configuration. This process requires the firewall to know
-the current nodes in the Tor network.
-
-1.0 Suggested changes
-
-Private bridge operators should be able to configure a method of hiding their
-relay. Only authorized users should be able to communicate with the private
-bridge. This should be done with Tor and if possible without the help of the
-firewall. It should be possible for a Tor user to enter a secret key into
-Tor or optionally Vidalia on a per bridge basis. This secret key should be
-used to authenticate the bridge user to the private bridge.
-
-1.x Issues with low ports and bind() for ORPort
-
-Tor opens low numbered ports during startup and then drops privileges. It is
-no longer possible to rebind to those lower ports after they are closed.
-
-1.x Issues with OS level packet filtering
-
-Tor does not know about any OS level packet filtering. Currently there is no
-packet filters that understands the Tor network in real time.
-
-1.x Possible partioning of users by bridge operator
-
-Depending on implementation, it may be possible for bridge operators to
-uniquely identify users. This appears to be a general bridge issue when a
-bridge operator uniquely deploys bridges per user.
-
-2.0 Implementation ideas
-
-This is a suggested set of methods for port knocking.
-
-2.x Using SPA port knocking
-
-Single Packet Authentication port knocking encodes all required data into a
-single UDP packet. Improperly formatted packets may be simply discarded.
-Properly formatted packets should be processed and appropriate actions taken.
-
-2.x Using DNS as a transport for SPA
-
-It should be possible for Tor to bind to port 53 at startup and merely drop all
-packets that are not valid. UDP does not require a response and invalid packets
-will not trigger a response from Tor. With base32 encoding it should be
-possible to encode SPA as valid DNS requests. This should allow use of the
-public DNS infrastructure for authorization requests if desired.
-
-2.x Ghetto firewalling with opportunistic connection closing
-
-Until a user has authenticated with Tor, Tor only has a UDP listener. This
-listener should never send data in response, it should only open an ORPort
-when a user has successfully authenticated. After a user has authenticated
-with Tor to open an ORPort, only users who have authenticated will be able
-to use it. All other users as identified by their ip address will have their
-connection closed before any data is sent or received. This should be
-accomplished with an access policy. By default, the access policy should block
-all access to the ORPort.
-
-2.x Timing and reset of access policies
-
-Access to the ORPort is sensitive. The bridge should remove any exceptions
-to its access policy regularly when the ORPort is unused. Valid users should
-reauthenticate if they do not use the ORPort within a given time frame.
-
-2.x Additional considerations
-
-There are many. A format of the packet and the crypto involved is a good start.
diff --git a/doc/spec/proposals/ideas/xxx-rate-limit-exits.txt b/doc/spec/proposals/ideas/xxx-rate-limit-exits.txt
deleted file mode 100644
index 81fed20..0000000
--- a/doc/spec/proposals/ideas/xxx-rate-limit-exits.txt
+++ /dev/null
@@ -1,63 +0,0 @@
-
-1. Overview
-
-  We should rate limit the volume of stream creations at exits:
-
-2.1. Per-circuit limits
-
-  If a given circuit opens more than N streams in X seconds, further
-  stream requests over the next Y seconds should fail with the reason
-  'resourcelimit'. Clients will automatically notice this and switch to
-  a new circuit.
-
-  The goal is to limit the effects of port scans on a given exit relay,
-  so the relay's ISP won't get hassled as much.
-
-  First thoughts for parameters would be N=100 streams in X=5 seconds
-  causes 30 seconds of fails; and N=300 streams in X=30 seconds causes
-  30 seconds of fails.
-
-  We could simplify by, instead of having a "for 30 seconds" parameter,
-  just marking the circuit as forever failing new requests. (We don't want
-  to just close the circuit because it may still have open streams on it.)
-
-2.2. Per-destination limits
-
-  If a given circuit opens more than N1 streams in X seconds to a single
-  IP address, or all the circuits combined open more than N2 streams,
-  then we should fail further attempts to reach that address for a while.
-
-  The goal is to limit the abuse that Tor exit relays can dish out
-  to a single target either for socket DoS or for web crawling, in
-  the hopes of a) not triggering their automated defenses, and b) not
-  making them upset at Tor. Hopefully these self-imposed bans will be
-  much shorter-lived than bans or barriers put up by the websites.
-
-3. Issues
-
-3.1. Circuit-creation overload
-
-  Making clients move to new circuits more often will cause more circuit
-  creation requests.
-
-3.2. How to pick the parameters?
-
-  If we pick the numbers too low, then popular sites are effectively
-  cut out of Tor. If we pick them too high, we don't do much good.
-
-  Worse, picking them wrong isn't easy to fix, since the deployed Tor
-  servers will ship with a certain set of numbers.
-
-  We could put numbers (or "general settings") in the networkstatus
-  consensus, and Tor exits would adapt more dynamically.
-
-  We could also have a local config option about how aggressive this
-  server should be with its parameters.
-
-4. Client-side limitations
-
-  Perhaps the clients should have built-in rate limits too, so they avoid
-  harrassing the servers by default?
-
-  Tricky if we want to get Tor clients in use at large enclaves.
-
diff --git a/doc/spec/proposals/ideas/xxx-separate-streams-by-port.txt b/doc/spec/proposals/ideas/xxx-separate-streams-by-port.txt
deleted file mode 100644
index cebde65..0000000
--- a/doc/spec/proposals/ideas/xxx-separate-streams-by-port.txt
+++ /dev/null
@@ -1,61 +0,0 @@
-Filename: xxx-separate-streams-by-port.txt
-Title: Separate streams across circuits by destination port
-Version: $Revision$
-Last-Modified: $Date$
-Author: Robert Hogan
-Created: 21-Oct-2008
-Status: Draft
-
-Here's a patch Robert Hogan wrote to use only one destination port per
-circuit. It's based on a wishlist item Roger wrote, to never send AIM
-usernames over the same circuit that we're hoping to browse anonymously
-through. The remaining open question is: how many extra circuits does this
-cause an ordinary user to create? My guess is not very many, but I'm wary
-of putting this in until we have some better estimate. On the other hand,
-not putting it in means that we have a known security flaw. Hm.
-
-Index: src/or/or.h
-===================================================================
---- src/or/or.h (revision 17143)
-+++ src/or/or.h (working copy)
-@@ -1874,6 +1874,7 @@
-
-   uint8_t state; /**< Current status of this circuit. */
-   uint8_t purpose; /**< Why are we creating this circuit? */
-+  uint16_t service; /**< Port conn must have to use this circuit. */
-
-   /** How many relay data cells can we package (read from edge streams)
-    * on this circuit before we receive a circuit-level sendme cell asking
-Index: src/or/circuituse.c
-===================================================================
---- src/or/circuituse.c (revision 17143)
-+++ src/or/circuituse.c (working copy)
-@@ -62,10 +62,16 @@
-       return 0;
-   }
-
--  if (purpose == CIRCUIT_PURPOSE_C_GENERAL)
-+  if (purpose == CIRCUIT_PURPOSE_C_GENERAL) {
-     if (circ->timestamp_dirty &&
-        circ->timestamp_dirty+get_options()->MaxCircuitDirtiness <= now)
-       return 0;
-+    /* If the circuit is dirty and used for services on another port,
-+      then it is not suitable. */
-+    if (circ->service && conn->socks_request->port &&
-+       (circ->service != conn->socks_request->port))
-+      return 0;
-+  }
-
-   /* decide if this circ is suitable for this conn */
-
-@@ -1351,7 +1357,9 @@
-     if (connection_ap_handshake_send_resolve(conn) < 0)
-       return -1;
-   }
--
-+  if (conn->socks_request->port
-+     && (TO_CIRCUIT(circ)->purpose == CIRCUIT_PURPOSE_C_GENERAL))
-+    TO_CIRCUIT(circ)->service = conn->socks_request->port;
-   return 1;
- }
-
diff --git a/doc/spec/proposals/ideas/xxx-what-uses-sha1.txt b/doc/spec/proposals/ideas/xxx-what-uses-sha1.txt
deleted file mode 100644
index 9b6e20c..0000000
--- a/doc/spec/proposals/ideas/xxx-what-uses-sha1.txt
+++ /dev/null
@@ -1,140 +0,0 @@
-Filename: xxx-what-uses-sha1.txt
-Title: Where does Tor use SHA-1 today?
-Version: $Revision$
-Last-Modified: $Date$
-Author: Nick Mathewson
-Created: 30-Dec-2008
-Status: Meta
-
-
-Introduction:
-
-   Tor uses SHA-1 as a message digest. SHA-1 is showing its age:
-   theoretical attacks for finding collisions against it get better
-   every year or two, and it will likely be broken in practice before
-   too long.
-
-   According to smart crypto people, the SHA-2 functions (SHA-256, etc)
-   share too much of SHA-1's structure to be very good.  Some people
-   like other hash functions; most of these have not seen enough
-   analysis to be widely regarded as an extra-good idea.
-
-   By 2012, the NIST SHA-3 competition will be done, and with luck we'll
-   have something good to switch too.  But it's probably a bad idea to
-   wait until 2012 to figure out _how_ to migrate to a new hash
-   function, for two reasons:
-         1) It's not inconceivable we'll want to migrate in a hurry
-            some time before then.
-         2) It's likely that migrating to a new hash function will
-            require protocol changes, and it's easiest to make protocol
-            changes backward compatible if we lay the groundwork in
-            advance.  It would suck to have to break compatibility with
-            a big hard-to-test "flag day" protocol change.
-
-   This document attempts to list everything Tor uses SHA-1 for today.
-   This is the first step in getting all the design work done to switch
-   to something else.
-
-   This document SHOULD NOT be a clearinghouse of what to do about our
-   use of SHA-1.  That's better left for other individual proposals.
-
-
-Why now?
-
-   The recent publication of "MD5 considered harmful today: Creating a
-   rogue CA certificate" by Alexander Sotirov, Marc Stevens, Jacob
-   Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, and Benne de
-   Weger has reminded me that:
-
-       * You can't rely on theoretical attacks to stay theoretical.
-       * It's quite unpleasant when theoretical attacks become practical
-         and public on days you were planning to leave for vacation.
-       * Broken hash functions (which SHA-1 is not quite yet AFAIU)
-         should be dropped like hot potatoes.  Failure to do so can make
-         one look silly.
-
-
-
-What Tor uses hashes for today:
-
-1. Infrastructure.
-
-   A. Our X.509 certificates are signed with SHA-1.
-   B. TLS uses SHA-1 (and MD5) internally to generate keys.
-   C. Some of the TLS ciphersuites we allow use SHA-1.
-   D. When we sign our code with GPG, it might be using SHA-1.
-   E. Our GPG keys might be authenticated with SHA-1.
-   F. OpenSSL's random number generator uses SHA-1, I believe.
-
-2. The Tor protocol
-
-   A. Everything we sign, we sign using SHA-1-based OAEP-MGF1.
-   B. Our CREATE cell format uses SHA-1 for: OAEP padding.
-   C. Our EXTEND cells use SHA-1 to hash the identity key of the
-      target server.
-   D. Our CREATED cells use SHA-1 to hash the derived key data.
-   E. The data we use in CREATE_FAST cells to generate a key is the
-      length of a SHA-1.
-   F. The data we send back in a CREATED/CREATED_FAST cell is the length
-      of a SHA-1.
-   G. We use SHA-1 to derive our circuit keys from the negotiated g^xy value.
-   H. We use SHA-1 to derive the digest field of each RELAY cell, but that's
-      used more as a checksum than as a strong digest.
-
-3. Directory services
-
-   A. All signatures are generated on the SHA-1 of their corresponding
-      documents, using PKCS1 padding.
-   B. Router descriptors identify their corresponding extra-info documents
-      by their SHA-1 digest.
-   C. Fingerprints in router descriptors are taken using SHA-1.
-   D. Fingerprints in authority certs are taken using SHA-1.
-   E. Fingerprints in dir-source lines of votes and consensuses are taken
-      using SHA-1.
-   F. Networkstatuses refer to routers identity keys and descriptors by their
-      SHA-1 digests.
-   G. Directory-signature lines identify which key is doing the signing by
-      the SHA-1 digests of the authority's signing key and its identity key.
-   H. The following items are downloaded by the SHA-1 of their contents:
-      XXXX list them
-   I. The following items are downloaded by the SHA-1 of an identity key:
-      XXXX list them too.
-
-4. The rendezvous protocol
-
-   A. Hidden servers use SHA-1 to establish introduction points on relays,
-      and relays use SHA-1 to check incoming introduction point
-      establishment requests.
-   B. Hidden servers use SHA-1 in multiple places when generating hidden
-      service descriptors.
-   C. Hidden servers performing basic-type client authorization for their
-      services use SHA-1 when encrypting introduction points contained in
-      hidden service descriptors.
-   D. Hidden service directories use SHA-1 to check whether a given hidden
-      service descriptor may be published under a given descriptor
-      identifier or not.
-   E. Hidden servers use SHA-1 to derive .onion addresses of their
-      services.
-   F. Clients use SHA-1 to generate the current hidden service descriptor
-      identifiers for a given .onion address.
-   G. Hidden servers use SHA-1 to remember digests of the first parts of
-      Diffie-Hellman handshakes contained in introduction requests in order
-      to detect replays.
-   H. Hidden servers use SHA-1 during the Diffie-Hellman key exchange with
-      a connecting client.
-
-5. The bridge protocol
-
-   XXXX write me
-
-6. The Tor user interface
-
-   A. We log information about servers based on SHA-1 hashes of their
-      identity keys.
-   B. The controller identifies servers based on SHA-1 hashes of their
-      identity keys.
-   C. Nearly all of our configuration options that list servers allow SHA-1
-      hashes of their identity keys.
-   E. The deprecated .exit notation uses SHA-1 hashes of identity keys
-
-
diff --git a/doc/spec/proposals/reindex.py b/doc/spec/proposals/reindex.py
deleted file mode 100755
index 2b4c025..0000000
--- a/doc/spec/proposals/reindex.py
+++ /dev/null
@@ -1,117 +0,0 @@
-#!/usr/bin/python
-
-import re, os
-class Error(Exception): pass
-
-STATUSES = """DRAFT NEEDS-REVISION NEEDS-RESEARCH OPEN ACCEPTED META FINISHED
-   CLOSED SUPERSEDED DEAD""".split()
-REQUIRED_FIELDS = [ "Filename", "Status", "Title" ]
-CONDITIONAL_FIELDS = { "OPEN" : [ "Target" ],
-                       "ACCEPTED" : [ "Target "],
-                       "CLOSED" : [ "Implemented-In" ],
-                       "FINISHED" : [ "Implemented-In" ] }
-FNAME_RE = re.compile(r'^(\d\d\d)-.*[^\~]$')
-DIR = "."
-OUTFILE = "000-index.txt"
-TMPFILE = OUTFILE+".tmp"
-
-def indexed(seq):
-    n = 0
-    for i in seq:
-        yield n, i
-        n += 1
-
-def readProposal(fn):
-    fields = { }
-    f = open(fn, 'r')
-    lastField = None
-    try:
-        for lineno, line in indexed(f):
-            line = line.rstrip()
-            if not line:
-                return fields
-            if line[0].isspace():
-                fields[lastField] += " %s"%(line.strip())
-            else:
-                parts = line.split(":", 1)
-                if len(parts) != 2:
-                    raise Error("%s:%s:  Neither field nor continuation"%
-                                (fn,lineno))
-                else:
-                    fields[parts[0]] = parts[1].strip()
-                    lastField = parts[0]
-
-        return fields
-    finally:
-        f.close()
-
-def checkProposal(fn, fields):
-    status = fields.get("Status")
-    need_fields = REQUIRED_FIELDS + CONDITIONAL_FIELDS.get(status, [])
-    for f in need_fields:
-        if not fields.has_key(f):
-            raise Error("%s has no %s field"%(fn, f))
-    if fn != fields['Filename']:
-        print `fn`, `fields['Filename']`
-        raise Error("Mismatched Filename field in %s"%fn)
-    if fields['Title'][-1] == '.':
-        fields['Title'] = fields['Title'][:-1]
-
-    status = fields['Status'] = status.upper()
-    if status not in STATUSES:
-        raise Error("I've never heard of status %s in %s"%(status,fn))
-    if status in [ "SUPERSEDED", "DEAD" ]:
-        for f in [ 'Implemented-In', 'Target' ]:
-            if fields.has_key(f): del fields[f]
-
-def readProposals():
-    res = []
-    for fn in os.listdir(DIR):
-        m = FNAME_RE.match(fn)
-        if not m: continue
-        if not fn.endswith(".txt"):
-            raise Error("%s doesn't end with .txt"%fn)
-        num = m.group(1)
-        fields = readProposal(fn)
-        checkProposal(fn, fields)
-        fields['num'] = num
-        res.append(fields)
-    return res
-
-def writeIndexFile(proposals):
-    proposals.sort(key=lambda f:f['num'])
-    seenStatuses = set()
-    for p in proposals:
-        seenStatuses.add(p['Status'])
-
-    out = open(TMPFILE, 'w')
-    inf = open(OUTFILE, 'r')
-    for line in inf:
-        out.write(line)
-        if line.startswith("====="): break
-    inf.close()
-
-    out.write("Proposals by number:\n\n")
-    for prop in proposals:
-        out.write("%(num)s  %(Title)s [%(Status)s]\n"%prop)
-    out.write("\n\nProposals by status:\n\n")
-    for s in STATUSES:
-        if s not in seenStatuses: continue
-        out.write(" %s:\n"%s)
-        for prop in proposals:
-            if s == prop['Status']:
-                out.write("   %(num)s  %(Title)s"%prop)
-                if prop.has_key('Target'):
-                    out.write(" [for %(Target)s]"%prop)
-                if prop.has_key('Implemented-In'):
-                    out.write(" [in %(Implemented-In)s]"%prop)
-                out.write("\n")
-    out.close()
-    os.rename(TMPFILE, OUTFILE)
-
-try:
-    os.unlink(TMPFILE)
-except OSError:
-    pass
-
-writeIndexFile(readProposals())
diff --git a/doc/spec/rend-spec.txt b/doc/spec/rend-spec.txt
deleted file mode 100644
index e3fbe22..0000000
--- a/doc/spec/rend-spec.txt
+++ /dev/null
@@ -1,768 +0,0 @@
-$Id$
-
-                    Tor Rendezvous Specification
-
-0. Overview and preliminaries
-
-   Read
-   https://www.torproject.org/doc/design-paper/tor-design.html#sec:rendezvous
-   before you read this specification. It will make more sense.
-
-   Rendezvous points provide location-hidden services (server
-   anonymity) for the onion routing network. With rendezvous points,
-   Bob can offer a TCP service (say, a webserver) via the onion
-   routing network, without revealing the IP of that service.
-
-   Bob does this by anonymously advertising a public key for his
-   service, along with a list of onion routers to act as "Introduction
-   Points" for his service.  He creates forward circuits to those
-   introduction points, and tells them about his public key.  To
-   connect to Bob, Alice first builds a circuit to an OR to act as
-   her "Rendezvous Point." She then connects to one of Bob's chosen
-   introduction points, optionally provides authentication or
-   authorization information, and asks it to tell him about her Rendezvous
-   Point (RP).  If Bob chooses to answer, he builds a circuit to her
-   RP, and tells it to connect him to Alice.  The RP joins their
-   circuits together, and begins relaying cells.  Alice's 'BEGIN'
-   cells are received directly by Bob's OP, which passes data to
-   and from the local server implementing Bob's service.
-
-   Below we describe a network-level specification of this service,
-   along with interfaces to make this process transparent to Alice
-   (so long as she is using an OP).
-
-0.1. Notation, conventions and prerequisites
-
-   In the specifications below, we use the same notation and terminology
-   as in "tor-spec.txt".  The service specified here also requires the
-   existence of an onion routing network as specified in that file.
-
-        H(x) is a SHA1 digest of x.
-        PKSign(SK,x) is a PKCS.1-padded RSA signature of x with SK.
-        PKEncrypt(SK,x) is a PKCS.1-padded RSA encryption of x with SK.
-        Public keys are all RSA, and encoded in ASN.1.
-        All integers are stored in network (big-endian) order.
-        All symmetric encryption uses AES in counter mode, except where
-            otherwise noted.
-
-   In all discussions, "Alice" will refer to a user connecting to a
-   location-hidden service, and "Bob" will refer to a user running a
-   location-hidden service.
-
-   An OP is (as defined elsewhere) an "Onion Proxy" or Tor client.
-
-   An OR is (as defined elsewhere) an "Onion Router" or Tor server.
-
-   An "Introduction point" is a Tor server chosen to be Bob's medium-term
-   'meeting place'.  A "Rendezvous point" is a Tor server chosen by Alice to
-   be a short-term communication relay between her and Bob.  All Tor servers
-   potentially act as introduction and rendezvous points.
-
-0.2. Protocol outline
-
-   1. Bob->Bob's OP: "Offer IP:Port as
-      public-key-name:Port". [configuration]
-      (We do not specify this step; it is left to the implementor of
-      Bob's OP.)
-
-   2. Bob's OP generates keypair and rendezvous service descriptor:
-        "Meet public-key X at introduction point A, B, or C." (signed)
-
-   3. Bob's OP->Introduction point via Tor: [introduction setup]
-        "This pk is me."
-
-   4. Bob's OP->directory service via Tor: publishes Bob's service
-      descriptor [advertisement]
-
-   5. Out of band, Alice receives a [x.y.]z.onion:port address.
-      She opens a SOCKS connection to her OP, and requests
-      x.y.z.onion:port.
-
-   6. Alice's OP retrieves Bob's descriptor via Tor. [descriptor lookup.]
-
-   7. Alice's OP chooses a rendezvous point, opens a circuit to that
-      rendezvous point, and establishes a rendezvous circuit. [rendezvous
-      setup.]
-
-   8. Alice connects to the Introduction point via Tor, and tells it about
-      her rendezvous point and optional authentication/authorization
-      information.  (Encrypted to Bob.)  [Introduction 1]
-
-   9. The Introduction point passes this on to Bob's OP via Tor, along the
-      introduction circuit. [Introduction 2]
-
-  10. Bob's OP decides whether to connect to Alice, and if so, creates a
-      circuit to Alice's RP via Tor.  Establishes a shared circuit.
-      [Rendezvous.]
-
-  11. Alice's OP sends begin cells to Bob's OP.  [Connection]
-
-0.3. Constants and new cell types
-
-  Relay cell types
-      32 -- RELAY_ESTABLISH_INTRO
-      33 -- RELAY_ESTABLISH_RENDEZVOUS
-      34 -- RELAY_INTRODUCE1
-      35 -- RELAY_INTRODUCE2
-      36 -- RELAY_RENDEZVOUS1
-      37 -- RELAY_RENDEZVOUS2
-      38 -- RELAY_INTRO_ESTABLISHED
-      39 -- RELAY_RENDEZVOUS_ESTABLISHED
-      40 -- RELAY_COMMAND_INTRODUCE_ACK
-
-0.4. Version overview
-
-   There are several parts in the hidden service protocol that have
-   changed over time, each of them having its own version number, whereas
-   other parts remained the same. The following list of potentially
-   versioned protocol parts should help reduce some confusion:
-
-   - Hidden service descriptor: the binary-based v0 was the default for
-     a long time, and an ascii-based v2 has been added by proposal
-     114. See 1.2.
-
-   - Hidden service descriptor propagation mechanism: currently related to
-     the hidden service descriptor version -- v0 publishes to the original
-     hs directory authorities, whereas v2 publishes to a rotating subset
-     of relays with the "hsdir" flag; see 1.4 and 1.6.
-
-   - Introduction protocol for how to generate an introduction cell:
-     v0 specified a nickname for the rendezvous point and assumed the
-     relay would know about it, whereas v2 now specifies IP address,
-     port, and onion key so the relay doesn't need to already recognize
-     it. See 1.8.
-
-1. The Protocol
-
-1.1. Bob configures his local OP.
-
-   We do not specify a format for the OP configuration file.  However,
-   OPs SHOULD allow Bob to provide more than one advertised service
-   per OP, and MUST allow Bob to specify one or more virtual ports per
-   service.  Bob provides a mapping from each of these virtual ports
-   to a local IP:Port pair.
-
-1.2. Bob's OP generates service descriptors.
-
-   The first time the OP provides an advertised service, it generates
-   a public/private keypair (stored locally).  Periodically, the OP
-   generates and publishes a descriptor of type "V0".
-
-   The "V0" descriptor contains:
-
-         KL    Key length                            [2 octets]
-         PK    Bob's public key                      [KL octets]
-         TS    A timestamp                           [4 octets]
-         NI    Number of introduction points         [2 octets]
-         Ipt   A list of NUL-terminated ORs          [variable]
-         SIG   Signature of above fields             [variable]
-
-   KL is the length of PK, in octets.
-   TS is the number of seconds elapsed since Jan 1, 1970.
-
-   The members of Ipt may be either (a) nicknames, or (b) identity key
-   digests, encoded in hex, and prefixed with a '$'.  Clients must
-   accept both forms. Services must only generate the second form.
-   Once 0.0.9.x is obsoleted, we can drop the first form.
-
-   [It's ok for Bob to advertise 0 introduction points. He might want
-    to do that if he previously advertised some introduction points,
-    and now he doesn't have any. -RD]
-
-   Beginning with 0.2.0.10-alpha, Bob's OP encodes "V2" descriptors in
-   addition to "V0" descriptors. The format of a "V2" descriptor is as
-   follows:
-
-     "rendezvous-service-descriptor" descriptor-id NL
-
-       [At start, exactly once]
-
-       Indicates the beginning of the descriptor. "descriptor-id" is a
-       periodically changing identifier of 160 bits formatted as 32 base32
-       chars that is calculated by the hidden service and its clients. If
-       the optional "descriptor-cookie" is used, this "descriptor-id"
-       cannot be computed by anyone else. (Everyone can verify that this
-       "descriptor-id" belongs to the rest of the descriptor, even without
-       knowing the optional "descriptor-cookie", as described below.) The
-       "descriptor-id" is calculated by performing the following operation:
-
-         descriptor-id =
-             H(permanent-id | H(time-period | descriptor-cookie | replica))
-
-       "permanent-id" is the permanent identifier of the hidden service,
-       consisting of 80 bits. It can be calculated by computing the hash value
-       of the public hidden service key and truncating after the first 80 bits:
-
-         permanent-id = H(public-key)[:10]
-
-       "H(time-period | descriptor-cookie | replica)" is the (possibly
-       secret) id part that is
-       necessary to verify that the hidden service is the true originator
-       of this descriptor. It can only be created by the hidden service
-       and its clients, but the "signature" below can only be created by
-       the service.
-
-       "descriptor-cookie" is an optional secret password of 128 bits that
-       is shared between the hidden service provider and its clients.
-
-       "replica" denotes the number of the non-consecutive replica.
-
-        (Each descriptor is replicated on a number of _consecutive_ nodes
-         in the identifier ring by making every storing node responsible
-         for the identifier intervals starting from its 3rd predecessor's
-         ID to its own ID. In addition to that, every service publishes
-         multiple descriptors with different descriptor IDs in order to
-         distribute them to different places on the ring. Therefore,
-         "replica" chooses one of the _non-consecutive_ replicas. -KL)
-
-       The "time-period" changes periodically depending on the global time and
-       as a function of "permanent-id". The current value for "time-period" can
-       be calculated using the following formula:
-
-         time-period = (current-time + permanent-id-byte * 86400 / 256)
-                         / 86400
-
-       "current-time" contains the current system time in seconds since
-       1970-01-01 00:00, e.g. 1188241957. "permanent-id-byte" is the first
-       (unsigned) byte of the permanent identifier (which is in network
-       order), e.g. 143. Adding the product of "permanent-id-byte" and
-       86400 (seconds per day), divided by 256, prevents "time-period" from
-       changing for all descriptors at the same time of the day. The result
-       of the overall operation is a (network-ordered) 32-bit integer, e.g.
-       13753 or 0x000035B9 with the example values given above.
-
-     "version" version-number NL
-
-       [Exactly once]
-
-       The version number of this descriptor's format.  In this case: 2.
-
-     "permanent-key" NL a public key in PEM format
-
-       [Exactly once]
-
-       The public key of the hidden service which is required to verify the
-       "descriptor-id" and the "signature".
-
-     "secret-id-part" secret-id-part NL
-
-       [Exactly once]
-
-       The result of the following operation as explained above, formatted as
-       32 base32 chars. Using this secret id part, everyone can verify that
-       the signed descriptor belongs to "descriptor-id".
-
-         secret-id-part = H(time-period | descriptor-cookie | replica)
-
-     "publication-time" YYYY-MM-DD HH:MM:SS NL
-
-       [Exactly once]
-
-       A timestamp when this descriptor has been created.
-
-     "protocol-versions" version-string NL
-
-       [Exactly once]
-
-       A comma-separated list of recognized and permitted version numbers
-       for use in INTRODUCE cells; these versions are described in section
-       1.8 below.
-
-     "introduction-points" NL encrypted-string
-
-       [At most once]
-
-       A list of introduction points. If the optional "descriptor-cookie" is
-       used, this list is encrypted with AES in CTR mode with a random
-       initialization vector of 128 bits that is written to
-       the beginning of the encrypted string, and the "descriptor-cookie" as
-       secret key of 128 bits length.
-
-       The string containing the introduction point data (either encrypted
-       or not) is encoded in base64, and surrounded with
-       "-----BEGIN MESSAGE-----" and "-----END MESSAGE-----".
-
-       The unencrypted string may begin with:
-
-        ["service-authentication" auth-type NL auth-data ... reserved]
-
-           [At start, any number]
-
-           The service-specific authentication data can be used to perform
-           client authentication. This data is independent of the selected
-           introduction point as opposed to "intro-authentication" below.
-
-       Subsequently, an arbitrary number of introduction point entries may
-       follow, each containing the following data:
-
-         "introduction-point" identifier NL
-
-           [At start, exactly once]
-
-           The identifier of this introduction point: the base-32 encoded
-           hash of this introduction point's identity key.
-
-         "ip-address" ip-address NL
-
-           [Exactly once]
-
-           The IP address of this introduction point.
-
-         "onion-port" port NL
-
-           [Exactly once]
-
-           The TCP port on which the introduction point is listening for
-           incoming onion requests.
-
-         "onion-key" NL a public key in PEM format
-
-           [Exactly once]
-
-           The public key that can be used to encrypt messages to this
-           introduction point.
-
-         "service-key" NL a public key in PEM format
-
-           [Exactly once]
-
-           The public key that can be used to encrypt messages to the hidden
-           service.
-
-        ["intro-authentication" auth-type NL auth-data ... reserved]
-
-           [Any number]
-
-           The introduction-point-specific authentication data can be used
-           to perform client authentication. This data depends on the
-           selected introduction point as opposed to "service-authentication"
-           above.
-
-        (This ends the fields in the encrypted portion of the descriptor.)
-
-     "signature" NL signature-string
-
-       [At end, exactly once]
-
-       A signature of all fields above with the private key of the hidden
-       service.
-
-1.2.1. Other descriptor formats we don't use.
-
-   The V1 descriptor format was understood and accepted from
-   0.1.1.5-alpha-cvs to 0.2.0.6-alpha-dev, but no Tors generated it and
-   it was removed:
-
-         V     Format byte: set to 255               [1 octet]
-         V     Version byte: set to 1                [1 octet]
-         KL    Key length                            [2 octets]
-         PK    Bob's public key                      [KL octets]
-         TS    A timestamp                           [4 octets]
-         PROTO Protocol versions: bitmask            [2 octets]
-         NI    Number of introduction points         [2 octets]
-         For each introduction point: (as in INTRODUCE2 cells)
-             IP     Introduction point's address     [4 octets]
-             PORT   Introduction point's OR port     [2 octets]
-             ID     Introduction point identity ID   [20 octets]
-             KLEN   Length of onion key              [2 octets]
-             KEY    Introduction point onion key     [KLEN octets]
-         SIG   Signature of above fields             [variable]
-
-   A hypothetical "V1" descriptor, that has never been used but might
-   be useful for historical reasons, contains:
-
-         V     Format byte: set to 255               [1 octet]
-         V     Version byte: set to 1                [1 octet]
-         KL    Key length                            [2 octets]
-         PK    Bob's public key                      [KL octets]
-         TS    A timestamp                           [4 octets]
-         PROTO Rendezvous protocol versions: bitmask [2 octets]
-         NA    Number of auth mechanisms accepted    [1 octet]
-         For each auth mechanism:
-             AUTHT  The auth type that is supported  [2 octets]
-             AUTHL  Length of auth data              [1 octet]
-             AUTHD  Auth data                        [variable]
-         NI    Number of introduction points         [2 octets]
-         For each introduction point: (as in INTRODUCE2 cells)
-             ATYPE  An address type (typically 4)    [1 octet]
-             ADDR   Introduction point's IP address  [4 or 16 octets]
-             PORT   Introduction point's OR port     [2 octets]
-             AUTHT  The auth type that is supported  [2 octets]
-             AUTHL  Length of auth data              [1 octet]
-             AUTHD  Auth data                        [variable]
-             ID     Introduction point identity ID   [20 octets]
-             KLEN   Length of onion key              [2 octets]
-             KEY    Introduction point onion key     [KLEN octets]
-         SIG   Signature of above fields             [variable]
-
-   AUTHT specifies which authentication/authorization mechanism is
-   required by the hidden service or the introduction point. AUTHD
-   is arbitrary data that can be associated with an auth approach.
-   Currently only AUTHT of [00 00] is supported, with an AUTHL of 0.
-   See section 2 of this document for details on auth mechanisms.
-
-1.3. Bob's OP establishes his introduction points.
-
-   The OP establishes a new introduction circuit to each introduction
-   point.  These circuits MUST NOT be used for anything but hidden service
-   introduction.  To establish the introduction, Bob sends a
-   RELAY_ESTABLISH_INTRO cell, containing:
-
-        KL   Key length                             [2 octets]
-        PK   Bob's public key                       [KL octets]
-        HS   Hash of session info                   [20 octets]
-        SIG  Signature of above information         [variable]
-
-   [XXX011, need to add auth information here. -RD]
-
-   To prevent replay attacks, the HS field contains a SHA-1 hash based on the
-   shared secret KH between Bob's OP and the introduction point, as
-   follows:
-       HS = H(KH | "INTRODUCE")
-   That is:
-       HS = H(KH | [49 4E 54 52 4F 44 55 43 45])
-   (KH, as specified in tor-spec.txt, is H(g^xy | [00]) .)
-
-   Upon receiving such a cell, the OR first checks that the signature is
-   correct with the included public key.  If so, it checks whether HS is
-   correct given the shared state between Bob's OP and the OR.  If either
-   check fails, the OP discards the cell; otherwise, it associates the
-   circuit with Bob's public key, and dissociates any other circuits
-   currently associated with PK.  On success, the OR sends Bob a
-   RELAY_INTRO_ESTABLISHED cell with an empty payload.
-
-   If a hidden service is configured to publish only v2 hidden service
-   descriptors, Bob's OP does not include its own public key in the
-   RELAY_ESTABLISH_INTRO cell, but the public key of a freshly generated
-   key pair. The OP also includes these fresh public keys in the v2 hidden
-   service descriptor together with the other introduction point
-   information. The reason is that the introduction point does not need to
-   and therefore should not know for which hidden service it works, so as
-   to prevent it from tracking the hidden service's activity. If the hidden
-   service is configured to publish both, v0 and v2 descriptors, two
-   separate sets of introduction points are established.
-
-1.4. Bob's OP advertises his service descriptor(s).
-
-   Bob's OP opens a stream to each directory server's directory port via Tor.
-   (He may re-use old circuits for this.)  Over this stream, Bob's OP makes
-   an HTTP 'POST' request, to a URL "/tor/rendezvous/publish" relative to the
-   directory server's root, containing as its body Bob's service descriptor.
-
-   Bob should upload a service descriptor for each version format that
-   is supported in the current Tor network.
-
-   Upon receiving a descriptor, the directory server checks the signature,
-   and discards the descriptor if the signature does not match the enclosed
-   public key.  Next, the directory server checks the timestamp.  If the
-   timestamp is more than 24 hours in the past or more than 1 hour in the
-   future, or the directory server already has a newer descriptor with the
-   same public key, the server discards the descriptor.  Otherwise, the
-   server discards any older descriptors with the same public key and
-   version format, and associates the new descriptor with the public key.
-   The directory server remembers this descriptor for at least 24 hours
-   after its timestamp.  At least every 18 hours, Bob's OP uploads a
-   fresh descriptor.
-
-   If Bob's OP is configured to publish v2 descriptors instead of or in
-   addition to v0 descriptors, it does so to a changing subset of all v2
-   hidden service directories instead of the authoritative directory
-   servers. Therefore, Bob's OP opens a stream via Tor to each
-   responsible hidden service directory. (He may re-use old circuits
-   for this.) Over this stream, Bob's OP makes an HTTP 'POST' request to a
-   URL "/tor/rendezvous2/publish" relative to the hidden service
-   directory's root, containing as its body Bob's service descriptor.
-
-   At any time, there are 6 hidden service directories responsible for
-   keeping replicas of a descriptor; they consist of 2 sets of 3 hidden
-   service directories with consecutive onion IDs. Bob's OP learns about
-   the complete list of hidden service directories by filtering the
-   consensus status document received from the directory authorities. A
-   hidden service directory is deemed responsible for all descriptor IDs in
-   the interval from its direct predecessor, exclusive, to its own ID,
-   inclusive; it further holds replicas for its 2 predecessors. A
-   participant only trusts its own routing list and never learns about
-   routing information from other parties.
-
-   Bob's OP publishes a new v2 descriptor once an hour or whenever its
-   content changes. V2 descriptors can be found by clients within a given
-   time period of 24 hours, after which they change their ID as described
-   under 1.2. If a published descriptor would be valid for less than 60
-   minutes (= 2 x 30 minutes to allow the server to be 30 minutes behind
-   and the client 30 minutes ahead), Bob's OP publishes the descriptor
-   under the ID of both, the current and the next publication period.
-
-1.5. Alice receives a x.y.z.onion address.
-
-   When Alice receives a pointer to a location-hidden service, it is as a
-   hostname of the form "z.onion" or "y.z.onion" or "x.y.z.onion", where
-   z is a base-32 encoding of a 10-octet hash of Bob's service's public
-   key, computed as follows:
-
-         1. Let H = H(PK).
-         2. Let H' = the first 80 bits of H, considering each octet from
-            most significant bit to least significant bit.
-         2. Generate a 16-character encoding of H', using base32 as defined
-            in RFC 3548.
-
-   (We only use 80 bits instead of the 160 bits from SHA1 because we
-   don't need to worry about arbitrary collisions, and because it will
-   make handling the url's more convenient.)
-
-   The string "x", if present, is the base-32 encoding of the
-   authentication/authorization required by the introduction point.
-   The string "y", if present, is the base-32 encoding of the
-   authentication/authorization required by the hidden service.
-   Omitting a string is taken to mean auth type [00 00].
-   See section 2 of this document for details on auth mechanisms.
-
-   [Yes, numbers are allowed at the beginning.  See RFC 1123. -NM]
-
-1.6. Alice's OP retrieves a service descriptor.
-
-   Alice opens a stream to a directory server via Tor, and makes an HTTP GET
-   request for the document '/tor/rendezvous/<z>', where '<z>' is replaced
-   with the encoding of Bob's public key as described above. (She may re-use
-   old circuits for this.) The directory replies with a 404 HTTP response if
-   it does not recognize <z>, and otherwise returns Bob's most recently
-   uploaded service descriptor.
-
-   If Alice's OP receives a 404 response, it tries the other directory
-   servers, and only fails the lookup if none recognize the public key hash.
-
-   Upon receiving a service descriptor, Alice verifies with the same process
-   as the directory server uses, described above in section 1.4.
-
-   The directory server gives a 400 response if it cannot understand Alice's
-   request.
-
-   Alice should cache the descriptor locally, but should not use
-   descriptors that are more than 24 hours older than their timestamp.
-   [Caching may make her partitionable, but she fetched it anonymously,
-    and we can't very well *not* cache it. -RD]
-
-   Alice's OP fetches v2 descriptors in parallel to v0 descriptors. Similarly
-   to the description in section 1.4, the OP fetches a v2 descriptor from a
-   randomly chosen hidden service directory out of the changing subset of
-   6 nodes. If the request is unsuccessful, Alice retries the other
-   remaining responsible hidden service directories in a random order.
-   Alice relies on Bob to care about a potential clock skew between the two
-   by possibly storing two sets of descriptors (see end of section 1.4).
-
-   Alice's OP opens a stream via Tor to the chosen v2 hidden service
-   directory. (She may re-use old circuits for this.) Over this stream,
-   Alice's OP makes an HTTP 'GET' request for the document
-   "/tor/rendezvous2/<z>", where z is replaced with the encoding of the
-   descriptor ID. The directory replies with a 404 HTTP response if it does
-   not recognize <z>, and otherwise returns Bob's most recently uploaded
-   service descriptor.
-
-1.7. Alice's OP establishes a rendezvous point.
-
-   When Alice requests a connection to a given location-hidden service,
-   and Alice's OP does not have an established circuit to that service,
-   the OP builds a rendezvous circuit.  It does this by establishing
-   a circuit to a randomly chosen OR, and sending a
-   RELAY_ESTABLISH_RENDEZVOUS cell to that OR.  The body of that cell
-   contains:
-
-        RC   Rendezvous cookie    [20 octets]
-
-   [XXX011 this looks like an auth mechanism. should we generalize here? -RD]
-
-   The rendezvous cookie is an arbitrary 20-byte value, chosen randomly by
-   Alice's OP.
-
-   Upon receiving a RELAY_ESTABLISH_RENDEZVOUS cell, the OR associates the
-   RC with the circuit that sent it.  It replies to Alice with an empty
-   RELAY_RENDEZVOUS_ESTABLISHED cell to indicate success.
-
-   Alice's OP MUST NOT use the circuit which sent the cell for any purpose
-   other than rendezvous with the given location-hidden service.
-
-1.8. Introduction: from Alice's OP to Introduction Point
-
-   Alice builds a separate circuit to one of Bob's chosen introduction
-   points, and sends it a RELAY_INTRODUCE1 cell containing:
-
-       Cleartext
-          PK_ID  Identifier for Bob's PK      [20 octets]
-       Encrypted to Bob's PK: (in the v0 intro protocol)
-          RP     Rendezvous point's nickname  [20 octets]
-          RC     Rendezvous cookie            [20 octets]
-          g^x    Diffie-Hellman data, part 1 [128 octets]
-        OR (in the v1 intro protocol)
-          VER    Version byte: set to 1.        [1 octet]
-          RP     Rendezvous point nick or ID  [42 octets]
-          RC     Rendezvous cookie            [20 octets]
-          g^x    Diffie-Hellman data, part 1 [128 octets]
-        OR (in the v2 intro protocol)
-          VER    Version byte: set to 2.        [1 octet]
-          IP     Rendezvous point's address    [4 octets]
-          PORT   Rendezvous point's OR port    [2 octets]
-          ID     Rendezvous point identity ID [20 octets]
-          KLEN   Length of onion key           [2 octets]
-          KEY    Rendezvous point onion key [KLEN octets]
-          RC     Rendezvous cookie            [20 octets]
-          g^x    Diffie-Hellman data, part 1 [128 octets]
-
-   PK_ID is the hash of Bob's public key.  RP is NUL-padded and
-   terminated. In version 0, it must contain a nickname. In version 1,
-   it must contain EITHER a nickname or an identity key digest that is
-   encoded in hex and prefixed with a '$'.
-
-   The hybrid encryption to Bob's PK works just like the hybrid
-   encryption in CREATE cells (see tor-spec). Thus the payload of the
-   version 0 RELAY_INTRODUCE1 cell on the wire will contain
-   20+42+16+20+20+128=246 bytes, and the version 1 and version 2
-   introduction formats have other sizes.
-
-   Through Tor 0.2.0.6-alpha, clients only generated the v0 introduction
-   format, whereas hidden services have understood and accepted v0,
-   v1, and v2 since 0.1.1.x. As of Tor 0.2.0.7-alpha and 0.1.2.18,
-   clients switched to using the v2 intro format.
-
-   If Alice has downloaded a v2 descriptor, she uses the contained public
-   key ("service-key") instead of Bob's public key to create the
-   RELAY_INTRODUCE1 cell as described above.
-
-1.8.1. Other introduction formats we don't use.
-
-    We briefly speculated about using the following format for the
-    "encrypted to Bob's PK" part of the introduction, but no Tors have
-    ever generated these.
-
-          VER    Version byte: set to 3.           [1 octet]
-          ATYPE  An address type (typically 4)     [1 octet]
-          ADDR   Rendezvous point's IP address     [4 or 16 octets]
-          PORT   Rendezvous point's OR port        [2 octets]
-          AUTHT  The auth type that is supported   [2 octets]
-          AUTHL  Length of auth data               [1 octet]
-          AUTHD  Auth data                        [variable]
-          ID     Rendezvous point identity ID    [20 octets]
-          KLEN  Length of onion key               [2 octets]
-          KEY    Rendezvous point onion key    [KLEN octets]
-          RC     Rendezvous cookie               [20 octets]
-          g^x    Diffie-Hellman data, part 1    [128 octets]
-
-1.9. Introduction: From the Introduction Point to Bob's OP
-
-   If the Introduction Point recognizes PK_ID as a public key which has
-   established a circuit for introductions as in 1.3 above, it sends the body
-   of the cell in a new RELAY_INTRODUCE2 cell down the corresponding circuit.
-   (If the PK_ID is unrecognized, the RELAY_INTRODUCE1 cell is discarded.)
-
-   After sending the RELAY_INTRODUCE2 cell, the OR replies to Alice with an
-   empty RELAY_COMMAND_INTRODUCE_ACK cell.  If no RELAY_INTRODUCE2 cell can
-   be sent, the OR replies to Alice with a non-empty cell to indicate an
-   error.  (The semantics of the cell body may be determined later; the
-   current implementation sends a single '1' byte on failure.)
-
-   When Bob's OP receives the RELAY_INTRODUCE2 cell, it decrypts it with
-   the private key for the corresponding hidden service, and extracts the
-   rendezvous point's nickname, the rendezvous cookie, and the value of g^x
-   chosen by Alice.
-
-1.10. Rendezvous
-
-   Bob's OP builds a new Tor circuit ending at Alice's chosen rendezvous
-   point, and sends a RELAY_RENDEZVOUS1 cell along this circuit, containing:
-       RC       Rendezvous cookie  [20 octets]
-       g^y      Diffie-Hellman     [128 octets]
-       KH       Handshake digest   [20 octets]
-
-   (Bob's OP MUST NOT use this circuit for any other purpose.)
-
-   If the RP recognizes RC, it relays the rest of the cell down the
-   corresponding circuit in a RELAY_RENDEZVOUS2 cell, containing:
-
-       g^y      Diffie-Hellman     [128 octets]
-       KH       Handshake digest   [20 octets]
-
-   (If the RP does not recognize the RC, it discards the cell and
-   tears down the circuit.)
-
-   When Alice's OP receives a RELAY_RENDEZVOUS2 cell on a circuit which
-   has sent a RELAY_ESTABLISH_RENDEZVOUS cell but which has not yet received
-   a reply, it uses g^y and H(g^xy) to complete the handshake as in the Tor
-   circuit extend process: they establish a 60-octet string as
-       K = SHA1(g^xy | [00]) | SHA1(g^xy | [01]) | SHA1(g^xy | [02])
-   and generate
-       KH = K[0..15]
-       Kf = K[16..31]
-       Kb = K[32..47]
-
-   Subsequently, the rendezvous point passes relay cells, unchanged, from
-   each of the two circuits to the other.  When Alice's OP sends
-   RELAY cells along the circuit, it first encrypts them with the
-   Kf, then with all of the keys for the ORs in Alice's side of the circuit;
-   and when Alice's OP receives RELAY cells from the circuit, it decrypts
-   them with the keys for the ORs in Alice's side of the circuit, then
-   decrypts them with Kb.  Bob's OP does the same, with Kf and Kb
-   interchanged.
-
-1.11. Creating streams
-
-   To open TCP connections to Bob's location-hidden service, Alice's OP sends
-   a RELAY_BEGIN cell along the established circuit, using the special
-   address "", and a chosen port.  Bob's OP chooses a destination IP and
-   port, based on the configuration of the service connected to the circuit,
-   and opens a TCP stream.  From then on, Bob's OP treats the stream as an
-   ordinary exit connection.
-   [ Except he doesn't include addr in the connected cell or the end
-     cell. -RD]
-
-   Alice MAY send multiple RELAY_BEGIN cells along the circuit, to open
-   multiple streams to Bob.  Alice SHOULD NOT send RELAY_BEGIN cells for any
-   other address along her circuit to Bob; if she does, Bob MUST reject them.
-
-2. Authentication and authorization.
-
-Foo.
-
-3. Hidden service directory operation
-
-   This section has been introduced with the v2 hidden service descriptor
-   format. It describes all operations of the v2 hidden service descriptor
-   fetching and propagation mechanism that are required for the protocol
-   described in section 1 to succeed with v2 hidden service descriptors.
-
-3.1. Configuring as hidden service directory
-
-   Every onion router that has its directory port open can decide whether it
-   wants to store and serve hidden service descriptors. An onion router which
-   is configured as such includes the "hidden-service-dir" flag in its router
-   descriptors that it sends to directory authorities.
-
-   The directory authorities include a new flag "HSDir" for routers that
-   decided to provide storage for hidden service descriptors and that
-   have been running for at least 24 hours.
-
-3.2. Accepting publish requests
-
-   Hidden service directory nodes accept publish requests for v2 hidden service
-   descriptors and store them to their local memory. (It is not necessary to
-   make descriptors persistent, because after restarting, the onion router
-   would not be accepted as a storing node anyway, because it has not been
-   running for at least 24 hours.) All requests and replies are formatted as
-   HTTP messages. Requests are initiated via BEGIN_DIR cells directed to
-   the router's directory port, and formatted as HTTP POST requests to the URL
-   "/tor/rendezvous2/publish" relative to the hidden service directory's root,
-   containing as its body a v2 service descriptor.
-
-   A hidden service directory node parses every received descriptor and only
-   stores it when it thinks that it is responsible for storing that descriptor
-   based on its own routing table. See section 1.4 for more information on how
-   to determine responsibility for a certain descriptor ID.
-
-3.3. Processing fetch requests
-
-   Hidden service directory nodes process fetch requests for hidden service
-   descriptors by looking them up in their local memory. (They do not need to
-   determine if they are responsible for the passed ID, because it does no harm
-   if they deliver a descriptor for which they are not (any more) responsible.)
-   All requests and replies are formatted as HTTP messages. Requests are
-   initiated via BEGIN_DIR cells directed to the router's directory port,
-   and formatted as HTTP GET requests for the document "/tor/rendezvous2/<z>",
-   where z is replaced with the encoding of the descriptor ID.
-
diff --git a/doc/spec/socks-extensions.txt b/doc/spec/socks-extensions.txt
deleted file mode 100644
index 8d58987..0000000
--- a/doc/spec/socks-extensions.txt
+++ /dev/null
@@ -1,79 +0,0 @@
-$Id$
-Tor's extensions to the SOCKS protocol
-
-1. Overview
-
-  The SOCKS protocol provides a generic interface for TCP proxies.  Client
-  software connects to a SOCKS server via TCP, and requests a TCP connection
-  to another address and port.  The SOCKS server establishes the connection,
-  and reports success or failure to the client.  After the connection has
-  been established, the client application uses the TCP stream as usual.
-
-  Tor supports SOCKS4 as defined in [1], SOCKS4A as defined in [2], and
-  SOCKS5 as defined in [3].
-
-  The stickiest issue for Tor in supporting clients, in practice, is forcing
-  DNS lookups to occur at the OR side: if clients do their own DNS lookup,
-  the DNS server can learn which addresses the client wants to reach.
-  SOCKS4 supports addressing by IPv4 address; SOCKS4A is a kludge on top of
-  SOCKS4 to allow addressing by hostname; SOCKS5 supports IPv4, IPv6, and
-  hostnames.
-
-1.1. Extent of support
-
-  Tor supports the SOCKS4, SOCKS4A, and SOCKS5 standards, except as follows:
-
-  BOTH:
-  - The BIND command is not supported.
-
-  SOCKS4,4A:
-  - SOCKS4 usernames are ignored.
-
-  SOCKS5:
-  - The (SOCKS5) "UDP ASSOCIATE" command is not supported.
-  - IPv6 is not supported in CONNECT commands.
-  - Only the "NO AUTHENTICATION" (SOCKS5) authentication method [00] is
-    supported.
-
-2. Name lookup
-
-  As an extension to SOCKS4A and SOCKS5, Tor implements a new command value,
-  "RESOLVE" [F0].  When Tor receives a "RESOLVE" SOCKS command, it initiates
-  a remote lookup of the hostname provided as the target address in the SOCKS
-  request.  The reply is either an error (if the address couldn't be
-  resolved) or a success response.  In the case of success, the address is
-  stored in the portion of the SOCKS response reserved for remote IP address.
-
-  (We support RESOLVE in SOCKS4 too, even though it is unnecessary.)
-
-  For SOCKS5 only, we support reverse resolution with a new command value,
-  "RESOLVE_PTR" [F1]. In response to a "RESOLVE_PTR" SOCKS5 command with
-  an IPv4 address as its target, Tor attempts to find the canonical
-  hostname for that IPv4 record, and returns it in the "server bound
-  address" portion of the reply.
-  (This command was not supported before Tor 0.1.2.2-alpha.)
-
-3. Other command extensions.
-
-  Tor 0.1.2.4-alpha added a new command value: "CONNECT_DIR" [F2].
-  In this case, Tor will open an encrypted direct TCP connection to the
-  directory port of the Tor server specified by address:port (the port
-  specified should be the ORPort of the server). It uses a one-hop tunnel
-  and a "BEGIN_DIR" relay cell to accomplish this secure connection.
-
-  The F2 command value was removed in Tor 0.2.0.10-alpha in favor of a
-  new use_begindir flag in edge_connection_t.
-
-4. HTTP-resistance
-
-  Tor checks the first byte of each SOCKS request to see whether it looks
-  more like an HTTP request (that is, it starts with a "G", "H", or "P").  If
-  so, Tor returns a small webpage, telling the user that his/her browser is
-  misconfigured.  This is helpful for the many users who mistakenly try to
-  use Tor as an HTTP proxy instead of a SOCKS proxy.
-
-References:
- [1] http://archive.socks.permeo.com/protocol/socks4.protocol
- [2] http://archive.socks.permeo.com/protocol/socks4a.protocol
- [3] SOCKS5: RFC1928
-
diff --git a/doc/spec/tor-spec.txt b/doc/spec/tor-spec.txt
deleted file mode 100644
index a321aa8..0000000
--- a/doc/spec/tor-spec.txt
+++ /dev/null
@@ -1,993 +0,0 @@
-$Id$
-
-                         Tor Protocol Specification
-
-                              Roger Dingledine
-                               Nick Mathewson
-
-Note: This document aims to specify Tor as implemented in 0.2.1.x.  Future
-versions of Tor may implement improved protocols, and compatibility is not
-guaranteed.  Compatibility notes are given for versions 0.1.1.15-rc and
-later; earlier versions are not compatible with the Tor network as of this
-writing.
-
-This specification is not a design document; most design criteria
-are not examined.  For more information on why Tor acts as it does,
-see tor-design.pdf.
-
-0. Preliminaries
-
-0.1.  Notation and encoding
-
-   PK -- a public key.
-   SK -- a private key.
-   K  -- a key for a symmetric cypher.
-
-   a|b -- concatenation of 'a' and 'b'.
-
-   [A0 B1 C2] -- a three-byte sequence, containing the bytes with
-   hexadecimal values A0, B1, and C2, in that order.
-
-   All numeric values are encoded in network (big-endian) order.
-
-   H(m) -- a cryptographic hash of m.
-
-0.2. Security parameters
-
-   Tor uses a stream cipher, a public-key cipher, the Diffie-Hellman
-   protocol, and a hash function.
-
-   KEY_LEN -- the length of the stream cipher's key, in bytes.
-
-   PK_ENC_LEN -- the length of a public-key encrypted message, in bytes.
-   PK_PAD_LEN -- the number of bytes added in padding for public-key
-     encryption, in bytes. (The largest number of bytes that can be encrypted
-     in a single public-key operation is therefore PK_ENC_LEN-PK_PAD_LEN.)
-
-   DH_LEN -- the number of bytes used to represent a member of the
-     Diffie-Hellman group.
-   DH_SEC_LEN -- the number of bytes used in a Diffie-Hellman private key (x).
-
-   HASH_LEN -- the length of the hash function's output, in bytes.
-
-   PAYLOAD_LEN -- The longest allowable cell payload, in bytes. (509)
-
-   CELL_LEN -- The length of a Tor cell, in bytes.
-
-0.3. Ciphers
-
-   For a stream cipher, we use 128-bit AES in counter mode, with an IV of all
-   0 bytes.
-
-   For a public-key cipher, we use RSA with 1024-bit keys and a fixed
-   exponent of 65537.  We use OAEP-MGF1 padding, with SHA-1 as its digest
-   function.  We leave the optional "Label" parameter unset. (For OAEP
-   padding, see ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf)
-
-   For Diffie-Hellman, we use a generator (g) of 2.  For the modulus (p), we
-   use the 1024-bit safe prime from rfc2409 section 6.2 whose hex
-   representation is:
-
-     "FFFFFFFFFFFFFFFFC90FDAA22168C234C4C6628B80DC1CD129024E08"
-     "8A67CC74020BBEA63B139B22514A08798E3404DDEF9519B3CD3A431B"
-     "302B0A6DF25F14374FE1356D6D51C245E485B576625E7EC6F44C42E9"
-     "A637ED6B0BFF5CB6F406B7EDEE386BFB5A899FA5AE9F24117C4B1FE6"
-     "49286651ECE65381FFFFFFFFFFFFFFFF"
-
-   As an optimization, implementations SHOULD choose DH private keys (x) of
-   320 bits.  Implementations that do this MUST never use any DH key more
-   than once.
-   [May other implementations reuse their DH keys?? -RD]
-   [Probably not. Conceivably, you could get away with changing DH keys once
-   per second, but there are too many oddball attacks for me to be
-   comfortable that this is safe. -NM]
-
-   For a hash function, we use SHA-1.
-
-   KEY_LEN=16.
-   DH_LEN=128; DH_SEC_LEN=40.
-   PK_ENC_LEN=128; PK_PAD_LEN=42.
-   HASH_LEN=20.
-
-   When we refer to "the hash of a public key", we mean the SHA-1 hash of the
-   DER encoding of an ASN.1 RSA public key (as specified in PKCS.1).
-
-   All "random" values should be generated with a cryptographically strong
-   random number generator, unless otherwise noted.
-
-   The "hybrid encryption" of a byte sequence M with a public key PK is
-   computed as follows:
-      1. If M is less than PK_ENC_LEN-PK_PAD_LEN, pad and encrypt M with PK.
-      2. Otherwise, generate a KEY_LEN byte random key K.
-         Let M1 = the first PK_ENC_LEN-PK_PAD_LEN-KEY_LEN bytes of M,
-         and let M2 = the rest of M.
-         Pad and encrypt K|M1 with PK.  Encrypt M2 with our stream cipher,
-         using the key K.  Concatenate these encrypted values.
-   [XXX Note that this "hybrid encryption" approach does not prevent
-   an attacker from adding or removing bytes to the end of M. It also
-   allows attackers to modify the bytes not covered by the OAEP --
-   see Goldberg's PET2006 paper for details. We will add a MAC to this
-   scheme one day. -RD]
-
-0.4. Other parameter values
-
-   CELL_LEN=512
-
-1. System overview
-
-   Tor is a distributed overlay network designed to anonymize
-   low-latency TCP-based applications such as web browsing, secure shell,
-   and instant messaging. Clients choose a path through the network and
-   build a ``circuit'', in which each node (or ``onion router'' or ``OR'')
-   in the path knows its predecessor and successor, but no other nodes in
-   the circuit.  Traffic flowing down the circuit is sent in fixed-size
-   ``cells'', which are unwrapped by a symmetric key at each node (like
-   the layers of an onion) and relayed downstream.
-
-1.1. Keys and names
-
-   Every Tor server has multiple public/private keypairs:
-
-    - A long-term signing-only "Identity key" used to sign documents and
-      certificates, and used to establish server identity.
-    - A medium-term "Onion key" used to decrypt onion skins when accepting
-      circuit extend attempts.  (See 5.1.)  Old keys MUST be accepted for at
-      least one week after they are no longer advertised.  Because of this,
-      servers MUST retain old keys for a while after they're rotated.
-    - A short-term "Connection key" used to negotiate TLS connections.
-      Tor implementations MAY rotate this key as often as they like, and
-      SHOULD rotate this key at least once a day.
-
-   Tor servers are also identified by "nicknames"; these are specified in
-   dir-spec.txt.
-
-2. Connections
-
-   Connections between two Tor servers, or between a client and a server,
-   use TLS/SSLv3 for link authentication and encryption.  All
-   implementations MUST support the SSLv3 ciphersuite
-   "SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA", and SHOULD support the TLS
-   ciphersuite "TLS_DHE_RSA_WITH_AES_128_CBC_SHA" if it is available.
-
-   There are three acceptable ways to perform a TLS handshake when
-   connecting to a Tor server: "certificates up-front", "renegotiation", and
-   "backwards-compatible renegotiation".  ("Backwards-compatible
-   renegotiation" is, as the name implies, compatible with both other
-   handshake types.)
-
-   Before Tor 0.2.0.21, only "certificates up-front" was supported.  In Tor
-   0.2.0.21 or later, "backwards-compatible renegotiation" is used.
-
-   In "certificates up-front", the connection initiator always sends a
-   two-certificate chain, consisting of an X.509 certificate using a
-   short-term connection public key and a second, self- signed X.509
-   certificate containing its identity key.  The other party sends a similar
-   certificate chain.  The initiator's ClientHello MUST NOT include any
-   ciphersuites other than:
-     TLS_DHE_RSA_WITH_AES_256_CBC_SHA
-     TLS_DHE_RSA_WITH_AES_128_CBC_SHA
-     SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
-     SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
-
-   In "renegotiation", the connection initiator sends no certificates, and
-   the responder sends a single connection certificate.  Once the TLS
-   handshake is complete, the initiator renegotiates the handshake, with each
-   parties sending a two-certificate chain as in "certificates up-front".
-   The initiator's ClientHello MUST include at least once ciphersuite not in
-   the list above.  The responder SHOULD NOT select any ciphersuite besides
-   those in the list above.
-     [The above "should not" is because some of the ciphers that
-     clients list may be fake.]
-
-   In "backwards-compatible renegotiation", the connection initiator's
-   ClientHello MUST include at least one ciphersuite other than those listed
-   above. The connection responder examines the initiator's ciphersuite list
-   to see whether it includes any ciphers other than those included in the
-   list above.  If extra ciphers are included, the responder proceeds as in
-   "renegotiation": it sends a single certificate and does not request
-   client certificates.  Otherwise (in the case that no extra ciphersuites
-   are included in the ClientHello) the responder proceeds as in
-   "certificates up-front": it requests client certificates, and sends a
-   two-certificate chain.  In either case, once the responder has sent its
-   certificate or certificates, the initiator counts them.  If two
-   certificates have been sent, it proceeds as in "certificates up-front";
-   otherwise, it proceeds as in "renegotiation".
-
-   All new implementations of the Tor server protocol MUST support
-   "backwards-compatible renegotiation"; clients SHOULD do this too.  If
-   this is not possible, new client implementations MUST support both
-   "renegotiation" and "certificates up-front" and use the router's
-   published link protocols list (see dir-spec.txt on the "protocols" entry)
-   to decide which to use.
-
-   In all of the above handshake variants, certificates sent in the clear
-   SHOULD NOT include any strings to identify the host as a Tor server.  In
-   the "renegotation" and "backwards-compatible renegotiation", the
-   initiator SHOULD chose a list of ciphersuites and TLS extensions chosen
-   to mimic one used by a popular web browser.
-
-   Responders MUST NOT select any TLS ciphersuite that lacks ephemeral keys,
-   or whose symmetric keys are less then KEY_LEN bits, or whose digests are
-   less than HASH_LEN bits.  Responders SHOULD NOT select any SSLv3
-   ciphersuite other than those listed above.
-
-   Even though the connection protocol is identical, we will think of the
-   initiator as either an onion router (OR) if it is willing to relay
-   traffic for other Tor users, or an onion proxy (OP) if it only handles
-   local requests. Onion proxies SHOULD NOT provide long-term-trackable
-   identifiers in their handshakes.
-
-   In all handshake variants, once all certificates are exchanged, all
-   parties receiving certificates must confirm that the identity key is as
-   expected.  (When initiating a connection, the expected identity key is
-   the one given in the directory; when creating a connection because of an
-   EXTEND cell, the expected identity key is the one given in the cell.)  If
-   the key is not as expected, the party must close the connection.
-
-   When connecting to an OR, all parties SHOULD reject the connection if that
-   OR has a malformed or missing certificate.  When accepting an incoming
-   connection, an OR SHOULD NOT reject incoming connections from parties with
-   malformed or missing certificates.  (However, an OR should not believe
-   that an incoming connection is from another OR unless the certificates
-   are present and well-formed.)
-
-   [Before version 0.1.2.8-rc, ORs rejected incoming connections from ORs and
-   OPs alike if their certificates were missing or malformed.]
-
-   Once a TLS connection is established, the two sides send cells
-   (specified below) to one another.  Cells are sent serially.  All
-   cells are CELL_LEN bytes long.  Cells may be sent embedded in TLS
-   records of any size or divided across TLS records, but the framing
-   of TLS records MUST NOT leak information about the type or contents
-   of the cells.
-
-   TLS connections are not permanent. Either side MAY close a connection
-   if there are no circuits running over it and an amount of time
-   (KeepalivePeriod, defaults to 5 minutes) has passed since the last time
-   any traffic was transmitted over the TLS connection.  Clients SHOULD
-   also hold a TLS connection with no circuits open, if it is likely that a
-   circuit will be built soon using that connection.
-
-   (As an exception, directory servers may try to stay connected to all of
-   the ORs -- though this will be phased out for the Tor 0.1.2.x release.)
-
-   To avoid being trivially distinguished from servers, client-only Tor
-   instances are encouraged but not required to use a two-certificate chain
-   as well.  Clients SHOULD NOT keep using the same certificates when
-   their IP address changes.  Clients MAY send no certificates at all.
-
-3. Cell Packet format
-
-   The basic unit of communication for onion routers and onion
-   proxies is a fixed-width "cell".
-
-   On a version 1 connection, each cell contains the following
-   fields:
-
-        CircID                                [2 bytes]
-        Command                               [1 byte]
-        Payload (padded with 0 bytes)         [PAYLOAD_LEN bytes]
-
-   On a version 2 connection, all cells are as in version 1 connections,
-   except for the initial VERSIONS cell, whose format is:
-
-        Circuit                               [2 octets; set to 0]
-        Command                               [1 octet; set to 7 for VERSIONS]
-        Length                                [2 octets; big-endian integer]
-        Payload                               [Length bytes]
-
-   The CircID field determines which circuit, if any, the cell is
-   associated with.
-
-   The 'Command' field holds one of the following values:
-         0 -- PADDING     (Padding)                 (See Sec 7.2)
-         1 -- CREATE      (Create a circuit)        (See Sec 5.1)
-         2 -- CREATED     (Acknowledge create)      (See Sec 5.1)
-         3 -- RELAY       (End-to-end data)         (See Sec 5.5 and 6)
-         4 -- DESTROY     (Stop using a circuit)    (See Sec 5.4)
-         5 -- CREATE_FAST (Create a circuit, no PK) (See Sec 5.1)
-         6 -- CREATED_FAST (Circuit created, no PK) (See Sec 5.1)
-         7 -- VERSIONS    (Negotiate proto version) (See Sec 4)
-         8 -- NETINFO     (Time and address info)   (See Sec 4)
-         9 -- RELAY_EARLY (End-to-end data; limited) (See sec 5.6)
-
-   The interpretation of 'Payload' depends on the type of the cell.
-      PADDING: Payload is unused.
-      CREATE:  Payload contains the handshake challenge.
-      CREATED: Payload contains the handshake response.
-      RELAY:   Payload contains the relay header and relay body.
-      DESTROY: Payload contains a reason for closing the circuit.
-               (see 5.4)
-   Upon receiving any other value for the command field, an OR must
-   drop the cell.  Since more cell types may be added in the future, ORs
-   should generally not warn when encountering unrecognized commands.
-
-   The payload is padded with 0 bytes.
-
-   PADDING cells are currently used to implement connection keepalive.
-   If there is no other traffic, ORs and OPs send one another a PADDING
-   cell every few minutes.
-
-   CREATE, CREATED, and DESTROY cells are used to manage circuits;
-   see section 5 below.
-
-   RELAY cells are used to send commands and data along a circuit; see
-   section 6 below.
-
-   VERSIONS and NETINFO cells are used to set up connections.  See section 4
-   below.
-
-4. Negotiating and initializing connections
-
-4.1. Negotiating versions with VERSIONS cells
-
-   There are multiple instances of the Tor link connection protocol.  Any
-   connection negotiated using the "certificates up front" handshake (see
-   section 2 above) is "version 1".  In any connection where both parties
-   have behaved as in the "renegotiation" handshake, the link protocol
-   version is 2 or higher.
-
-   To determine the version, in any connection where the "renegotiation"
-   handshake was used (that is, where the server sent only one certificate
-   at first and where the client did not send any certificates until
-   renegotiation), both parties MUST send a VERSIONS cell immediately after
-   the renegotiation is finished, before any other cells are sent.  Parties
-   MUST NOT send any other cells on a connection until they have received a
-   VERSIONS cell.
-
-   The payload in a VERSIONS cell is a series of big-endian two-byte
-   integers.  Both parties MUST select as the link protocol version the
-   highest number contained both in the VERSIONS cell they sent and in the
-   versions cell they received.  If they have no such version in common,
-   they cannot communicate and MUST close the connection.
-
-   Since the version 1 link protocol does not use the "renegotiation"
-   handshake, implementations MUST NOT list version 1 in their VERSIONS
-   cell.
-
-4.2. NETINFO cells
-
-   If version 2 or higher is negotiated, each party sends the other a
-   NETINFO cell.  The cell's payload is:
-
-         Timestamp              [4 bytes]
-         Other OR's address     [variable]
-         Number of addresses    [1 byte]
-         This OR's addresses    [variable]
-
-   The address format is a type/length/value sequence as given in section
-   6.4 below.  The timestamp is a big-endian unsigned integer number of
-   seconds since the unix epoch.
-
-   Implementations MAY use the timestamp value to help decide if their
-   clocks are skewed.  Initiators MAY use "other OR's address" to help
-   learn which address their connections are originating from, if they do
-   not know it.  Initiators SHOULD use "this OR's address" to make sure
-   that they have connected to another OR at its canonical address.
-
-   [As of 0.2.0.23-rc, implementations use none of the above values.]
-
-
-5. Circuit management
-
-5.1. CREATE and CREATED cells
-
-   Users set up circuits incrementally, one hop at a time. To create a
-   new circuit, OPs send a CREATE cell to the first node, with the
-   first half of the DH handshake; that node responds with a CREATED
-   cell with the second half of the DH handshake plus the first 20 bytes
-   of derivative key data (see section 5.2). To extend a circuit past
-   the first hop, the OP sends an EXTEND relay cell (see section 5)
-   which instructs the last node in the circuit to send a CREATE cell
-   to extend the circuit.
-
-   The payload for a CREATE cell is an 'onion skin', which consists
-   of the first step of the DH handshake data (also known as g^x).
-   This value is hybrid-encrypted (see 0.3) to Bob's onion key, giving
-   an onion-skin of:
-       PK-encrypted:
-         Padding                       [PK_PAD_LEN bytes]
-         Symmetric key                 [KEY_LEN bytes]
-         First part of g^x             [PK_ENC_LEN-PK_PAD_LEN-KEY_LEN bytes]
-       Symmetrically encrypted:
-         Second part of g^x            [DH_LEN-(PK_ENC_LEN-PK_PAD_LEN-KEY_LEN)
-                                           bytes]
-
-   The relay payload for an EXTEND relay cell consists of:
-         Address                       [4 bytes]
-         Port                          [2 bytes]
-         Onion skin                    [DH_LEN+KEY_LEN+PK_PAD_LEN bytes]
-         Identity fingerprint          [HASH_LEN bytes]
-
-   The port and address field denote the IPV4 address and port of the next
-   onion router in the circuit; the public key hash is the hash of the PKCS#1
-   ASN1 encoding of the next onion router's identity (signing) key.  (See 0.3
-   above.)  Including this hash allows the extending OR verify that it is
-   indeed connected to the correct target OR, and prevents certain
-   man-in-the-middle attacks.
-
-   The payload for a CREATED cell, or the relay payload for an
-   EXTENDED cell, contains:
-         DH data (g^y)                 [DH_LEN bytes]
-         Derivative key data (KH)      [HASH_LEN bytes]   <see 5.2 below>
-
-   The CircID for a CREATE cell is an arbitrarily chosen 2-byte integer,
-   selected by the node (OP or OR) that sends the CREATE cell.  To prevent
-   CircID collisions, when one node sends a CREATE cell to another, it chooses
-   from only one half of the possible values based on the ORs' public
-   identity keys: if the sending node has a lower key, it chooses a CircID with
-   an MSB of 0; otherwise, it chooses a CircID with an MSB of 1.
-
-   (An OP with no public key MAY choose any CircID it wishes, since an OP
-   never needs to process a CREATE cell.)
-
-   Public keys are compared numerically by modulus.
-
-   As usual with DH, x and y MUST be generated randomly.
-
-5.1.1. CREATE_FAST/CREATED_FAST cells
-
-   When initializing the first hop of a circuit, the OP has already
-   established the OR's identity and negotiated a secret key using TLS.
-   Because of this, it is not always necessary for the OP to perform the
-   public key operations to create a circuit.  In this case, the
-   OP MAY send a CREATE_FAST cell instead of a CREATE cell for the first
-   hop only.  The OR responds with a CREATED_FAST cell, and the circuit is
-   created.
-
-   A CREATE_FAST cell contains:
-
-       Key material (X)    [HASH_LEN bytes]
-
-   A CREATED_FAST cell contains:
-
-       Key material (Y)    [HASH_LEN bytes]
-       Derivative key data [HASH_LEN bytes] (See 5.2 below)
-
-   The values of X and Y must be generated randomly.
-
-   If an OR sees a circuit created with CREATE_FAST, the OR is sure to be the
-   first hop of a circuit.  ORs SHOULD reject attempts to create streams with
-   RELAY_BEGIN exiting the circuit at the first hop: letting Tor be used as a
-   single hop proxy makes exit nodes a more attractive target for compromise.
-
-5.2. Setting circuit keys
-
-   Once the handshake between the OP and an OR is completed, both can
-   now calculate g^xy with ordinary DH.  Before computing g^xy, both client
-   and server MUST verify that the received g^x or g^y value is not degenerate;
-   that is, it must be strictly greater than 1 and strictly less than p-1
-   where p is the DH modulus.  Implementations MUST NOT complete a handshake
-   with degenerate keys.  Implementations MUST NOT discard other "weak"
-   g^x values.
-
-   (Discarding degenerate keys is critical for security; if bad keys
-   are not discarded, an attacker can substitute the server's CREATED
-   cell's g^y with 0 or 1, thus creating a known g^xy and impersonating
-   the server. Discarding other keys may allow attacks to learn bits of
-   the private key.)
-
-   If CREATE or EXTEND is used to extend a circuit, the client and server
-   base their key material on K0=g^xy, represented as a big-endian unsigned
-   integer.
-
-   If CREATE_FAST is used, the client and server base their key material on
-   K0=X|Y.
-
-   From the base key material K0, they compute KEY_LEN*2+HASH_LEN*3 bytes of
-   derivative key data as
-       K = H(K0 | [00]) | H(K0 | [01]) | H(K0 | [02]) | ...
-
-   The first HASH_LEN bytes of K form KH; the next HASH_LEN form the forward
-   digest Df; the next HASH_LEN 41-60 form the backward digest Db; the next
-   KEY_LEN 61-76 form Kf, and the final KEY_LEN form Kb.  Excess bytes from K
-   are discarded.
-
-   KH is used in the handshake response to demonstrate knowledge of the
-   computed shared key. Df is used to seed the integrity-checking hash
-   for the stream of data going from the OP to the OR, and Db seeds the
-   integrity-checking hash for the data stream from the OR to the OP. Kf
-   is used to encrypt the stream of data going from the OP to the OR, and
-   Kb is used to encrypt the stream of data going from the OR to the OP.
-
-5.3. Creating circuits
-
-   When creating a circuit through the network, the circuit creator
-   (OP) performs the following steps:
-
-      1. Choose an onion router as an exit node (R_N), such that the onion
-         router's exit policy includes at least one pending stream that
-         needs a circuit (if there are any).
-
-      2. Choose a chain of (N-1) onion routers
-         (R_1...R_N-1) to constitute the path, such that no router
-         appears in the path twice.
-
-      3. If not already connected to the first router in the chain,
-         open a new connection to that router.
-
-      4. Choose a circID not already in use on the connection with the
-         first router in the chain; send a CREATE cell along the
-         connection, to be received by the first onion router.
-
-      5. Wait until a CREATED cell is received; finish the handshake
-         and extract the forward key Kf_1 and the backward key Kb_1.
-
-      6. For each subsequent onion router R (R_2 through R_N), extend
-         the circuit to R.
-
-   To extend the circuit by a single onion router R_M, the OP performs
-   these steps:
-
-      1. Create an onion skin, encrypted to R_M's public onion key.
-
-      2. Send the onion skin in a relay EXTEND cell along
-         the circuit (see section 5).
-
-      3. When a relay EXTENDED cell is received, verify KH, and
-         calculate the shared keys.  The circuit is now extended.
-
-   When an onion router receives an EXTEND relay cell, it sends a CREATE
-   cell to the next onion router, with the enclosed onion skin as its
-   payload.  As special cases, if the extend cell includes a digest of
-   all zeroes, or asks to extend back to the relay that sent the extend
-   cell, the circuit will fail and be torn down. The initiating onion
-   router chooses some circID not yet used on the connection between the
-   two onion routers.  (But see section 5.1. above, concerning choosing
-   circIDs based on lexicographic order of nicknames.)
-
-   When an onion router receives a CREATE cell, if it already has a
-   circuit on the given connection with the given circID, it drops the
-   cell.  Otherwise, after receiving the CREATE cell, it completes the
-   DH handshake, and replies with a CREATED cell.  Upon receiving a
-   CREATED cell, an onion router packs it payload into an EXTENDED relay
-   cell (see section 5), and sends that cell up the circuit.  Upon
-   receiving the EXTENDED relay cell, the OP can retrieve g^y.
-
-   (As an optimization, OR implementations may delay processing onions
-   until a break in traffic allows time to do so without harming
-   network latency too greatly.)
-
-5.3.1. Canonical connections
-
-   It is possible for an attacker to launch a man-in-the-middle attack
-   against a connection by telling OR Alice to extend to OR Bob at some
-   address X controlled by the attacker.  The attacker cannot read the
-   encrypted traffic, but the attacker is now in a position to count all
-   bytes sent between Alice and Bob (assuming Alice was not already
-   connected to Bob.)
-
-   To prevent this, when an OR we gets an extend request, it SHOULD use an
-   existing OR connection if the ID matches, and ANY of the following
-   conditions hold:
-       - The IP matches the requested IP.
-       - The OR knows that the IP of the connection it's using is canonical
-         because it was listed in the NETINFO cell.
-       - The OR knows that the IP of the connection it's using is canonical
-         because it was listed in the server descriptor.
-
-   [This is not implemented in Tor 0.2.0.23-rc.]
-
-5.4. Tearing down circuits
-
-   Circuits are torn down when an unrecoverable error occurs along
-   the circuit, or when all streams on a circuit are closed and the
-   circuit's intended lifetime is over.  Circuits may be torn down
-   either completely or hop-by-hop.
-
-   To tear down a circuit completely, an OR or OP sends a DESTROY
-   cell to the adjacent nodes on that circuit, using the appropriate
-   direction's circID.
-
-   Upon receiving an outgoing DESTROY cell, an OR frees resources
-   associated with the corresponding circuit. If it's not the end of
-   the circuit, it sends a DESTROY cell for that circuit to the next OR
-   in the circuit. If the node is the end of the circuit, then it tears
-   down any associated edge connections (see section 6.1).
-
-   After a DESTROY cell has been processed, an OR ignores all data or
-   destroy cells for the corresponding circuit.
-
-   To tear down part of a circuit, the OP may send a RELAY_TRUNCATE cell
-   signaling a given OR (Stream ID zero).  That OR sends a DESTROY
-   cell to the next node in the circuit, and replies to the OP with a
-   RELAY_TRUNCATED cell.
-
-   When an unrecoverable error occurs along one connection in a
-   circuit, the nodes on either side of the connection should, if they
-   are able, act as follows:  the node closer to the OP should send a
-   RELAY_TRUNCATED cell towards the OP; the node farther from the OP
-   should send a DESTROY cell down the circuit.
-
-   The payload of a RELAY_TRUNCATED or DESTROY cell contains a single octet,
-   describing why the circuit is being closed or truncated.  When sending a
-   TRUNCATED or DESTROY cell because of another TRUNCATED or DESTROY cell,
-   the error code should be propagated.  The origin of a circuit always sets
-   this error code to 0, to avoid leaking its version.
-
-   The error codes are:
-     0 -- NONE            (No reason given.)
-     1 -- PROTOCOL        (Tor protocol violation.)
-     2 -- INTERNAL        (Internal error.)
-     3 -- REQUESTED       (A client sent a TRUNCATE command.)
-     4 -- HIBERNATING     (Not currently operating; trying to save bandwidth.)
-     5 -- RESOURCELIMIT   (Out of memory, sockets, or circuit IDs.)
-     6 -- CONNECTFAILED   (Unable to reach server.)
-     7 -- OR_IDENTITY     (Connected to server, but its OR identity was not
-                           as expected.)
-     8 -- OR_CONN_CLOSED  (The OR connection that was carrying this circuit
-                           died.)
-     9 -- FINISHED        (The circuit has expired for being dirty or old.)
-    10 -- TIMEOUT         (Circuit construction took too long)
-    11 -- DESTROYED       (The circuit was destroyed w/o client TRUNCATE)
-    12 -- NOSUCHSERVICE   (Request for unknown hidden service)
-
-5.5. Routing relay cells
-
-   When an OR receives a RELAY or RELAY_EARLY cell, it checks the cell's
-   circID and determines whether it has a corresponding circuit along that
-   connection.  If not, the OR drops the cell.
-
-   Otherwise, if the OR is not at the OP edge of the circuit (that is,
-   either an 'exit node' or a non-edge node), it de/encrypts the payload
-   with the stream cipher, as follows:
-        'Forward' relay cell (same direction as CREATE):
-            Use Kf as key; decrypt.
-        'Back' relay cell (opposite direction from CREATE):
-            Use Kb as key; encrypt.
-   Note that in counter mode, decrypt and encrypt are the same operation.
-
-   The OR then decides whether it recognizes the relay cell, by
-   inspecting the payload as described in section 6.1 below.  If the OR
-   recognizes the cell, it processes the contents of the relay cell.
-   Otherwise, it passes the decrypted relay cell along the circuit if
-   the circuit continues.  If the OR at the end of the circuit
-   encounters an unrecognized relay cell, an error has occurred: the OR
-   sends a DESTROY cell to tear down the circuit.
-
-   When a relay cell arrives at an OP, the OP decrypts the payload
-   with the stream cipher as follows:
-         OP receives data cell:
-            For I=N...1,
-                Decrypt with Kb_I.  If the payload is recognized (see
-                section 6..1), then stop and process the payload.
-
-   For more information, see section 6 below.
-
-5.6. Handling relay_early cells
-
-   A RELAY_EARLY cell is designed to limit the length any circuit can reach.
-   When an OR receives a RELAY_EARLY cell, and the next node in the circuit
-   is speaking v2 of the link protocol or later, the OR relays the cell as a
-   RELAY_EARLY cell.  Otherwise, it relays it as a RELAY cell.
-
-   If a node ever receives more than 8 RELAY_EARLY cells on a given
-   outbound circuit, it SHOULD close the circuit. (For historical reasons,
-   we don't limit the number of inbound RELAY_EARLY cells; they should
-   be harmless anyway because clients won't accept extend requests. See
-   bug 1038.)
-
-   When speaking v2 of the link protocol or later, clients MUST only send
-   EXTEND cells inside RELAY_EARLY cells.  Clients SHOULD send the first ~8
-   RELAY cells that are not targeted at the first hop of any circuit as
-   RELAY_EARLY cells too, in order to partially conceal the circuit length.
-
-   [In a future version of Tor, servers will reject any EXTEND cell not
-   received in a RELAY_EARLY cell.  See proposal 110.]
-
-6. Application connections and stream management
-
-6.1. Relay cells
-
-   Within a circuit, the OP and the exit node use the contents of
-   RELAY packets to tunnel end-to-end commands and TCP connections
-   ("Streams") across circuits.  End-to-end commands can be initiated
-   by either edge; streams are initiated by the OP.
-
-   The payload of each unencrypted RELAY cell consists of:
-         Relay command           [1 byte]
-         'Recognized'            [2 bytes]
-         StreamID                [2 bytes]
-         Digest                  [4 bytes]
-         Length                  [2 bytes]
-         Data                    [CELL_LEN-14 bytes]
-
-   The relay commands are:
-         1 -- RELAY_BEGIN     [forward]
-         2 -- RELAY_DATA      [forward or backward]
-         3 -- RELAY_END       [forward or backward]
-         4 -- RELAY_CONNECTED [backward]
-         5 -- RELAY_SENDME    [forward or backward] [sometimes control]
-         6 -- RELAY_EXTEND    [forward]             [control]
-         7 -- RELAY_EXTENDED  [backward]            [control]
-         8 -- RELAY_TRUNCATE  [forward]             [control]
-         9 -- RELAY_TRUNCATED [backward]            [control]
-        10 -- RELAY_DROP      [forward or backward] [control]
-        11 -- RELAY_RESOLVE   [forward]
-        12 -- RELAY_RESOLVED  [backward]
-        13 -- RELAY_BEGIN_DIR [forward]
-
-        32..40 -- Used for hidden services; see rend-spec.txt.
-
-   Commands labelled as "forward" must only be sent by the originator
-   of the circuit. Commands labelled as "backward" must only be sent by
-   other nodes in the circuit back to the originator. Commands marked
-   as either can be sent either by the originator or other nodes.
-
-   The 'recognized' field in any unencrypted relay payload is always set
-   to zero; the 'digest' field is computed as the first four bytes of
-   the running digest of all the bytes that have been destined for
-   this hop of the circuit or originated from this hop of the circuit,
-   seeded from Df or Db respectively (obtained in section 5.2 above),
-   and including this RELAY cell's entire payload (taken with the digest
-   field set to zero).
-
-   When the 'recognized' field of a RELAY cell is zero, and the digest
-   is correct, the cell is considered "recognized" for the purposes of
-   decryption (see section 5.5 above).
-
-   (The digest does not include any bytes from relay cells that do
-   not start or end at this hop of the circuit. That is, it does not
-   include forwarded data. Therefore if 'recognized' is zero but the
-   digest does not match, the running digest at that node should
-   not be updated, and the cell should be forwarded on.)
-
-   All RELAY cells pertaining to the same tunneled stream have the
-   same stream ID.  StreamIDs are chosen arbitrarily by the OP.  RELAY
-   cells that affect the entire circuit rather than a particular
-   stream use a StreamID of zero -- they are marked in the table above
-   as "[control]" style cells. (Sendme cells are marked as "sometimes
-   control" because they can take include a StreamID or not depending
-   on their purpose -- see Section 7.)
-
-   The 'Length' field of a relay cell contains the number of bytes in
-   the relay payload which contain real payload data. The remainder of
-   the payload is padded with NUL bytes.
-
-   If the RELAY cell is recognized but the relay command is not
-   understood, the cell must be dropped and ignored. Its contents
-   still count with respect to the digests, though.
-
-6.2. Opening streams and transferring data
-
-   To open a new anonymized TCP connection, the OP chooses an open
-   circuit to an exit that may be able to connect to the destination
-   address, selects an arbitrary StreamID not yet used on that circuit,
-   and constructs a RELAY_BEGIN cell with a payload encoding the address
-   and port of the destination host.  The payload format is:
-
-         ADDRESS | ':' | PORT | [00]
-
-   where  ADDRESS can be a DNS hostname, or an IPv4 address in
-   dotted-quad format, or an IPv6 address surrounded by square brackets;
-   and where PORT is a decimal integer between 1 and 65535, inclusive.
-
-   [What is the [00] for? -NM]
-   [It's so the payload is easy to parse out with string funcs -RD]
-
-   Upon receiving this cell, the exit node resolves the address as
-   necessary, and opens a new TCP connection to the target port.  If the
-   address cannot be resolved, or a connection can't be established, the
-   exit node replies with a RELAY_END cell.  (See 6.4 below.)
-   Otherwise, the exit node replies with a RELAY_CONNECTED cell, whose
-   payload is in one of the following formats:
-       The IPv4 address to which the connection was made [4 octets]
-       A number of seconds (TTL) for which the address may be cached [4 octets]
-    or
-       Four zero-valued octets [4 octets]
-       An address type (6)     [1 octet]
-       The IPv6 address to which the connection was made [16 octets]
-       A number of seconds (TTL) for which the address may be cached [4 octets]
-   [XXXX No version of Tor currently generates the IPv6 format.]
-
-   [Tor servers before 0.1.2.0 set the TTL field to a fixed value.  Later
-   versions set the TTL to the last value seen from a DNS server, and expire
-   their own cached entries after a fixed interval.  This prevents certain
-   attacks.]
-
-   The OP waits for a RELAY_CONNECTED cell before sending any data.
-   Once a connection has been established, the OP and exit node
-   package stream data in RELAY_DATA cells, and upon receiving such
-   cells, echo their contents to the corresponding TCP stream.
-   RELAY_DATA cells sent to unrecognized streams are dropped.
-
-   Relay RELAY_DROP cells are long-range dummies; upon receiving such
-   a cell, the OR or OP must drop it.
-
-6.2.1. Opening a directory stream
-
-   If a Tor server is a directory server, it should respond to a
-   RELAY_BEGIN_DIR cell as if it had received a BEGIN cell requesting a
-   connection to its directory port.  RELAY_BEGIN_DIR cells ignore exit
-   policy, since the stream is local to the Tor process.
-
-   If the Tor server is not running a directory service, it should respond
-   with a REASON_NOTDIRECTORY RELAY_END cell.
-
-   Clients MUST generate an all-zero payload for RELAY_BEGIN_DIR cells,
-   and servers MUST ignore the payload.
-
-   [RELAY_BEGIN_DIR was not supported before Tor 0.1.2.2-alpha; clients
-   SHOULD NOT send it to routers running earlier versions of Tor.]
-
-6.3. Closing streams
-
-   When an anonymized TCP connection is closed, or an edge node
-   encounters error on any stream, it sends a 'RELAY_END' cell along the
-   circuit (if possible) and closes the TCP connection immediately.  If
-   an edge node receives a 'RELAY_END' cell for any stream, it closes
-   the TCP connection completely, and sends nothing more along the
-   circuit for that stream.
-
-   The payload of a RELAY_END cell begins with a single 'reason' byte to
-   describe why the stream is closing, plus optional data (depending on
-   the reason.)  The values are:
-
-       1 -- REASON_MISC           (catch-all for unlisted reasons)
-       2 -- REASON_RESOLVEFAILED  (couldn't look up hostname)
-       3 -- REASON_CONNECTREFUSED (remote host refused connection) [*]
-       4 -- REASON_EXITPOLICY     (OR refuses to connect to host or port)
-       5 -- REASON_DESTROY        (Circuit is being destroyed)
-       6 -- REASON_DONE           (Anonymized TCP connection was closed)
-       7 -- REASON_TIMEOUT        (Connection timed out, or OR timed out
-                                   while connecting)
-       8 -- (unallocated) [**]
-       9 -- REASON_HIBERNATING    (OR is temporarily hibernating)
-      10 -- REASON_INTERNAL       (Internal error at the OR)
-      11 -- REASON_RESOURCELIMIT  (OR has no resources to fulfill request)
-      12 -- REASON_CONNRESET      (Connection was unexpectedly reset)
-      13 -- REASON_TORPROTOCOL    (Sent when closing connection because of
-                                   Tor protocol violations.)
-      14 -- REASON_NOTDIRECTORY   (Client sent RELAY_BEGIN_DIR to a
-                                   non-directory server.)
-
-   (With REASON_EXITPOLICY, the 4-byte IPv4 address or 16-byte IPv6 address
-   forms the optional data, along with a 4-byte TTL; no other reason
-   currently has extra data.)
-
-   OPs and ORs MUST accept reasons not on the above list, since future
-   versions of Tor may provide more fine-grained reasons.
-
-   Tors SHOULD NOT send any reason except REASON_MISC for a stream that they
-   have originated.
-
-   [*] Older versions of Tor also send this reason when connections are
-       reset.
-   [**] Due to a bug in versions of Tor through 0095, error reason 8 must
-        remain allocated until that version is obsolete.
-
-   --- [The rest of this section describes unimplemented functionality.]
-
-   Because TCP connections can be half-open, we follow an equivalent
-   to TCP's FIN/FIN-ACK/ACK protocol to close streams.
-
-   An exit connection can have a TCP stream in one of three states:
-   'OPEN', 'DONE_PACKAGING', and 'DONE_DELIVERING'.  For the purposes
-   of modeling transitions, we treat 'CLOSED' as a fourth state,
-   although connections in this state are not, in fact, tracked by the
-   onion router.
-
-   A stream begins in the 'OPEN' state.  Upon receiving a 'FIN' from
-   the corresponding TCP connection, the edge node sends a 'RELAY_FIN'
-   cell along the circuit and changes its state to 'DONE_PACKAGING'.
-   Upon receiving a 'RELAY_FIN' cell, an edge node sends a 'FIN' to
-   the corresponding TCP connection (e.g., by calling
-   shutdown(SHUT_WR)) and changing its state to 'DONE_DELIVERING'.
-
-   When a stream in already in 'DONE_DELIVERING' receives a 'FIN', it
-   also sends a 'RELAY_FIN' along the circuit, and changes its state
-   to 'CLOSED'.  When a stream already in 'DONE_PACKAGING' receives a
-   'RELAY_FIN' cell, it sends a 'FIN' and changes its state to
-   'CLOSED'.
-
-   If an edge node encounters an error on any stream, it sends a
-   'RELAY_END' cell (if possible) and closes the stream immediately.
-
-6.4. Remote hostname lookup
-
-   To find the address associated with a hostname, the OP sends a
-   RELAY_RESOLVE cell containing the hostname to be resolved with a nul
-   terminating byte. (For a reverse lookup, the OP sends a RELAY_RESOLVE
-   cell containing an in-addr.arpa address.) The OR replies with a
-   RELAY_RESOLVED cell containing a status byte, and any number of
-   answers. Each answer is of the form:
-       Type   (1 octet)
-       Length (1 octet)
-       Value  (variable-width)
-       TTL    (4 octets)
-   "Length" is the length of the Value field.
-   "Type" is one of:
-      0x00 -- Hostname
-      0x04 -- IPv4 address
-      0x06 -- IPv6 address
-      0xF0 -- Error, transient
-      0xF1 -- Error, nontransient
-
-    If any answer has a type of 'Error', then no other answer may be given.
-
-    The RELAY_RESOLVE cell must use a nonzero, distinct streamID; the
-    corresponding RELAY_RESOLVED cell must use the same streamID.  No stream
-    is actually created by the OR when resolving the name.
-
-7. Flow control
-
-7.1. Link throttling
-
-   Each client or relay should do appropriate bandwidth throttling to
-   keep its user happy.
-
-   Communicants rely on TCP's default flow control to push back when they
-   stop reading.
-
-   The mainline Tor implementation uses token buckets (one for reads,
-   one for writes) for the rate limiting.
-
-   Since 0.2.0.x, Tor has let the user specify an additional pair of
-   token buckets for "relayed" traffic, so people can deploy a Tor relay
-   with strict rate limiting, but also use the same Tor as a client. To
-   avoid partitioning concerns we combine both classes of traffic over a
-   given OR connection, and keep track of the last time we read or wrote
-   a high-priority (non-relayed) cell. If it's been less than N seconds
-   (currently N=30), we give the whole connection high priority, else we
-   give the whole connection low priority. We also give low priority
-   to reads and writes for connections that are serving directory
-   information. See proposal 111 for details.
-
-7.2. Link padding
-
-   Link padding can be created by sending PADDING cells along the
-   connection; relay cells of type "DROP" can be used for long-range
-   padding.
-
-   Currently nodes are not required to do any sort of link padding or
-   dummy traffic. Because strong attacks exist even with link padding,
-   and because link padding greatly increases the bandwidth requirements
-   for running a node, we plan to leave out link padding until this
-   tradeoff is better understood.
-
-7.3. Circuit-level flow control
-
-   To control a circuit's bandwidth usage, each OR keeps track of two
-   'windows', consisting of how many RELAY_DATA cells it is allowed to
-   originate (package for transmission), and how many RELAY_DATA cells
-   it is willing to consume (receive for local streams).  These limits
-   do not apply to cells that the OR receives from one host and relays
-   to another.
-
-   Each 'window' value is initially set to 1000 data cells
-   in each direction (cells that are not data cells do not affect
-   the window).  When an OR is willing to deliver more cells, it sends a
-   RELAY_SENDME cell towards the OP, with Stream ID zero.  When an OR
-   receives a RELAY_SENDME cell with stream ID zero, it increments its
-   packaging window.
-
-   Each of these cells increments the corresponding window by 100.
-
-   The OP behaves identically, except that it must track a packaging
-   window and a delivery window for every OR in the circuit.
-
-   An OR or OP sends cells to increment its delivery window when the
-   corresponding window value falls under some threshold (900).
-
-   If a packaging window reaches 0, the OR or OP stops reading from
-   TCP connections for all streams on the corresponding circuit, and
-   sends no more RELAY_DATA cells until receiving a RELAY_SENDME cell.
-[this stuff is badly worded; copy in the tor-design section -RD]
-
-7.4. Stream-level flow control
-
-   Edge nodes use RELAY_SENDME cells to implement end-to-end flow
-   control for individual connections across circuits. Similarly to
-   circuit-level flow control, edge nodes begin with a window of cells
-   (500) per stream, and increment the window by a fixed value (50)
-   upon receiving a RELAY_SENDME cell. Edge nodes initiate RELAY_SENDME
-   cells when both a) the window is <= 450, and b) there are less than
-   ten cell payloads remaining to be flushed at that edge.
-
-A.1. Differences between spec and implementation
-
-- The current specification requires all ORs to have IPv4 addresses, but
-  allows servers to exit and resolve to IPv6 addresses, and to declare IPv6
-  addresses in their exit policies.  The current codebase has no IPv6
-  support at all.
-
diff --git a/doc/spec/version-spec.txt b/doc/spec/version-spec.txt
deleted file mode 100644
index 842271a..0000000
--- a/doc/spec/version-spec.txt
+++ /dev/null
@@ -1,45 +0,0 @@
-$Id$
-
-                        HOW TOR VERSION NUMBERS WORK
-
-1. The Old Way
-
- Before 0.1.0, versions were of the format:
-     MAJOR.MINOR.MICRO(status(PATCHLEVEL))?(-cvs)?
- where MAJOR, MINOR, MICRO, and PATCHLEVEL are numbers, status is one
- of "pre" (for an alpha release), "rc" (for a release candidate), or
- "." for a release.  As a special case, "a.b.c" was equivalent to
- "a.b.c.0".  We compare the elements in order (major, minor, micro,
- status, patchlevel, cvs), with "cvs" preceding non-cvs.
-
- We would start each development branch with a final version in mind:
- say, "0.0.8".  Our first pre-release would be "0.0.8pre1", followed by
- (for example) "0.0.8pre2-cvs", "0.0.8pre2", "0.0.8pre3-cvs",
- "0.0.8rc1", "0.0.8rc2-cvs", and "0.0.8rc2".  Finally, we'd release
- 0.0.8.  The stable CVS branch would then be versioned "0.0.8.1-cvs",
- and any eventual bugfix release would be "0.0.8.1".
-
-2. The New Way
-
- After 0.1.0, versions are of the format:
-    MAJOR.MINOR.MICRO(.PATCHLEVEL)(-status_tag)
- The stuff in parentheses is optional.  As before, MAJOR, MINOR, MICRO,
- and PATCHLEVEL are numbers, with an absent number equivalent to 0.
- All versions should be distinguishable purely by those four
- numbers. The status tag is purely informational, and lets you know how
- stable we think the release is: "alpha" is pretty unstable; "rc" is a
- release candidate; and no tag at all means that we have a final
- release. If the tag ends with "-cvs" or "-dev", you're looking at a
- development snapshot that came after a given release.  If we *do*
- encounter two versions that differ only by status tag, we compare them
- lexically.
-
- Now, we start each development branch with (say) 0.1.1.1-alpha.  The
- patchlevel increments consistently as the status tag changes, for
- example, as in: 0.1.1.2-alpha, 0.1.1.3-alpha, 0.1.1.4-rc, 0.1.1.5-rc.
- Eventually, we release 0.1.1.6.  The next patch release is 0.1.1.7.
-
- Between these releases, CVS is versioned with a -cvs tag: after
- 0.1.1.1-alpha comes 0.1.1.1-alpha-cvs, and so on. But starting with
- 0.1.2.1-alpha-dev, we switched to SVN and started using the "-dev"
- suffix instead of the "-cvs" suffix.



_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits