Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2

Conflicts:
	doc/Makefile.am
	doc/spec/Makefile.am
	doc/spec/address-spec.txt
	doc/spec/bridges-spec.txt
	doc/spec/control-spec-v0.txt
	doc/spec/control-spec.txt
	doc/spec/dir-spec-v1.txt
	doc/spec/dir-spec-v2.txt
	doc/spec/dir-spec.txt
	doc/spec/path-spec.txt
	doc/spec/proposals/000-index.txt
	doc/spec/proposals/001-process.txt
	doc/spec/proposals/098-todo.txt
	doc/spec/proposals/099-misc.txt
	doc/spec/proposals/100-tor-spec-udp.txt
	doc/spec/proposals/101-dir-voting.txt
	doc/spec/proposals/102-drop-opt.txt
	doc/spec/proposals/103-multilevel-keys.txt
	doc/spec/proposals/104-short-descriptors.txt
	doc/spec/proposals/105-handshake-revision.txt
	doc/spec/proposals/106-less-tls-constraint.txt
	doc/spec/proposals/107-uptime-sanity-checking.txt
	doc/spec/proposals/108-mtbf-based-stability.txt
	doc/spec/proposals/109-no-sharing-ips.txt
	doc/spec/proposals/110-avoid-infinite-circuits.txt
	doc/spec/proposals/111-local-traffic-priority.txt
	doc/spec/proposals/112-bring-back-pathlencoinweight.txt
	doc/spec/proposals/113-fast-authority-interface.txt
	doc/spec/proposals/114-distributed-storage.txt
	doc/spec/proposals/115-two-hop-paths.txt
	doc/spec/proposals/116-two-hop-paths-from-guard.txt
	doc/spec/proposals/117-ipv6-exits.txt
	doc/spec/proposals/118-multiple-orports.txt
	doc/spec/proposals/119-controlport-auth.txt
	doc/spec/proposals/120-shutdown-descriptors.txt
	doc/spec/proposals/121-hidden-service-authentication.txt
	doc/spec/proposals/122-unnamed-flag.txt
	doc/spec/proposals/123-autonaming.txt
	doc/spec/proposals/124-tls-certificates.txt
	doc/spec/proposals/125-bridges.txt
	doc/spec/proposals/126-geoip-reporting.txt
	doc/spec/proposals/127-dirport-mirrors-downloads.txt
	doc/spec/proposals/128-bridge-families.txt
	doc/spec/proposals/129-reject-plaintext-ports.txt
	doc/spec/proposals/130-v2-conn-protocol.txt
	doc/spec/proposals/131-verify-tor-usage.txt
	doc/spec/proposals/132-browser-check-tor-service.txt
	doc/spec/proposals/134-robust-voting.txt
	doc/spec/proposals/135-private-tor-networks.txt
	doc/spec/proposals/137-bootstrap-phases.txt
	doc/spec/proposals/138-remove-down-routers-from-consensus.txt
	doc/spec/proposals/140-consensus-diffs.txt
	doc/spec/proposals/141-jit-sd-downloads.txt
	doc/spec/proposals/142-combine-intro-and-rend-points.txt
	doc/spec/proposals/143-distributed-storage-improvements.txt
	doc/spec/proposals/145-newguard-flag.txt
	doc/spec/proposals/146-long-term-stability.txt
	doc/spec/proposals/147-prevoting-opinions.txt
	doc/spec/proposals/148-uniform-client-end-reason.txt
	doc/spec/proposals/149-using-netinfo-data.txt
	doc/spec/proposals/150-exclude-exit-nodes.txt
	doc/spec/proposals/151-path-selection-improvements.txt
	doc/spec/proposals/152-single-hop-circuits.txt
	doc/spec/proposals/153-automatic-software-update-protocol.txt
	doc/spec/proposals/154-automatic-updates.txt
	doc/spec/proposals/155-four-hidden-service-improvements.txt
	doc/spec/proposals/156-tracking-blocked-ports.txt
	doc/spec/proposals/157-specific-cert-download.txt
	doc/spec/proposals/158-microdescriptors.txt
	doc/spec/proposals/159-exit-scanning.txt
	doc/spec/proposals/ideas/xxx-hide-platform.txt
	doc/spec/proposals/ideas/xxx-port-knocking.txt
	doc/spec/proposals/ideas/xxx-separate-streams-by-port.txt
	doc/spec/proposals/ideas/xxx-what-uses-sha1.txt
	doc/spec/proposals/reindex.py
	doc/spec/rend-spec.txt
	doc/spec/socks-extensions.txt
	doc/spec/tor-spec.txt
	doc/spec/version-spec.txt

1 files changed, 0 insertions, 128 deletions

diff --git a/doc/spec/proposals/133-unreachable-ors.txt b/doc/spec/proposals/133-unreachable-ors.txt
deleted file mode 100644
index a1c2dd8549..0000000000
--- 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?
-