1 files changed, 45 insertions, 36 deletions
diff --git a/spec/guard-spec-intro.md b/spec/guard-spec-intro.md
index e94a4f2..b7d1836 100644
--- a/spec/guard-spec-intro.md
+++ b/spec/guard-spec-intro.md
@@ -1,39 +1,48 @@
-Tor Guard Specification
+# Tor Guard Specification
+
+<a id="guard-spec.txt-1"></a>
+
+## Introduction and motivation
+
+Tor uses entry guards to prevent an attacker who controls some
+fraction of the network from observing a fraction of every user's
+traffic. If users chose their entries and exits uniformly at
+random from the list of servers every time they build a circuit,
+then an adversary who had (k/N) of the network would deanonymize
+F=(k/N)^2 of all circuits... and after a given user had built C
+circuits, the attacker would see them at least once with
+probability 1-(1-F)^C.  With large C, the attacker would get a
+sample of every user's traffic with probability 1.
+
+To prevent this from happening, Tor clients choose a small number
+of guard nodes (e.g. 3).  These guard nodes are the only
+nodes that the client will connect to directly.  If they are not
+compromised, the user's paths are not compromised.
+
+This specification outlines Tor's guard housekeeping algorithm,
+which tries to meet the following goals:
 
 ```text
-                           Isis Lovecruft
-                         George Kadianakis
-                              Ola Bini
-                           Nick Mathewson
-
-Table of Contents
-
-    1. Introduction and motivation
-    2. State instances
-    3. Circuit Creation, Entry Guard Selection (1000 foot view)
-        3.1 Path selection
-            3.1.1 Managing entry guards
-            3.1.2 Middle and exit node selection
-        3.2 Circuit Building
-    4. The algorithm.
-        4.0. The guards listed in the current consensus. [Section:GUARDS]
-        4.1. The Sampled Guard Set. [Section:SAMPLED]
-        4.2. The Usable Sample [Section:FILTERED]
-        4.3. The confirmed-guard list. [Section:CONFIRMED]
-        4.4. The Primary guards [Section:PRIMARY]
-        4.5. Retrying guards. [Section:RETRYING]
-        4.6. Selecting guards for circuits. [Section:SELECTING]
-        4.7. When a circuit fails. [Section:ON_FAIL]
-        4.8. When a circuit succeeds [Section:ON_SUCCESS]
-        4.9. Updating the list of waiting circuits [Section:UPDATE_WAITING]
-        4.10. Whenever we get a new consensus. [Section:ON_CONSENSUS]
-        4.11. Deciding whether to generate a new circuit.
-        4.12. When we are missing descriptors.
-    A. Appendices
-        A.0. Acknowledgements
-        A.1. Parameters with suggested values. [Section:PARAM_VALS]
-        A.2. Random values [Section:RANDOM]
-        A.3. Why not a sliding scale of primaryness? [Section:CVP]
-        A.4. Controller changes
-        A.5. Persistent state format
+    - Heuristics and algorithms for determining how and which guards
+      are chosen should be kept as simple and easy to understand as
+      possible.
+
+    - Clients in censored regions or who are behind a fascist
+      firewall who connect to the Tor network should not experience
+      any significant disadvantage in terms of reachability or
+      usability.
+
+    - Tor should make a best attempt at discovering the most
+      appropriate behavior, with as little user input and
+      configuration as possible.
+
+    - Tor clients should discover usable guards without too much
+      delay.
+
+    - Tor clients should resist (to the extent possible) attacks
+      that try to force them onto compromised guards.
+
+    - Should maintain the load-balancing offered by the path selection
+      algorithm
 ```
+