1 files changed, 0 insertions, 94 deletions
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 941f5ad6b0..0000000000
--- 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.