Run markdownlint --fix on spec.

13 files changed, 44 insertions, 17 deletions

diff --git a/spec/path-spec/attaching-streams-to-circuits.md b/spec/path-spec/attaching-streams-to-circuits.md
index a603b98..e03414e 100644
--- a/spec/path-spec/attaching-streams-to-circuits.md
+++ b/spec/path-spec/attaching-streams-to-circuits.md
@@ -1,4 +1,5 @@
 <a id="path-spec.txt-3"></a>
+
 # Attaching streams to circuits
 
 When a circuit that might support a request is built, Tor tries to attach
@@ -16,4 +17,3 @@ 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.
-
diff --git a/spec/path-spec/building-circuits.md b/spec/path-spec/building-circuits.md
index 2382a88..af0b5cc 100644
--- a/spec/path-spec/building-circuits.md
+++ b/spec/path-spec/building-circuits.md
@@ -1,3 +1,3 @@
 <a id="path-spec.txt-2"></a>
-# Building circuits
 
+# Building circuits
diff --git a/spec/path-spec/cannibalizing-circuits.md b/spec/path-spec/cannibalizing-circuits.md
index 8d07489..2d15175 100644
--- a/spec/path-spec/cannibalizing-circuits.md
+++ b/spec/path-spec/cannibalizing-circuits.md
@@ -1,4 +1,5 @@
 <a id="path-spec.txt-2.3"></a>
+
 ## Cannibalizing circuits
 
 If we need a circuit and have a clean one already established, in
@@ -12,4 +13,3 @@ 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.
-
diff --git a/spec/path-spec/detecting-route-manipulation-by-guard-nodes-path.md b/spec/path-spec/detecting-route-manipulation-by-guard-nodes-path.md
index 1191efc..c7ff50c 100644
--- a/spec/path-spec/detecting-route-manipulation-by-guard-nodes-path.md
+++ b/spec/path-spec/detecting-route-manipulation-by-guard-nodes-path.md
@@ -1,4 +1,5 @@
 <a id="path-spec.txt-7"></a>
+
 # Detecting route manipulation by Guard nodes (Path Bias)
 
 The Path Bias defense is designed to defend against a type of route
@@ -33,6 +34,7 @@ restrict the defense to being informational only at this stage (see
 section 7.5).
 
 <a id="path-spec.txt-7.1"></a>
+
 ## Measuring path construction success rates
 
 Clients maintain two counts for each of their guards: a count of the
@@ -49,6 +51,7 @@ If a circuit closes prematurely after construction but before being
 requested to close by the client, this is counted as a failure.
 
 <a id="path-spec.txt-7.2"></a>
+
 ## Measuring path usage success rates
 
 Clients maintain two usage counts for each of their guards: a count
@@ -84,6 +87,7 @@ Prematurely closed circuits are not probed, and are counted as usage
 failures.
 
 <a id="path-spec.txt-7.3"></a>
+
 ## Scaling success counts
 
 To provide a moving average of recent Guard activity while
@@ -99,6 +103,7 @@ currently open circuits are subtracted from the usage counts before
 scaling, and added back after scaling.
 
 <a id="path-spec.txt-7.4"></a>
+
 ## Parametrization
 
 The following consensus parameters tune various aspects of the
@@ -183,6 +188,7 @@ defense.
 ```
 
 <a id="path-spec.txt-7.5"></a>
+
 ## Known barriers to enforcement
 
 Due to intermittent CPU overload at relays, the normal rate of
@@ -190,4 +196,3 @@ successful circuit completion is highly variable. The Guard-dropping
 version of the defense is unlikely to be deployed until the ntor
 circuit handshake is enabled, or the nature of CPU overload induced
 failure is better understood.
-
diff --git a/spec/path-spec/general-operation.md b/spec/path-spec/general-operation.md
index 7a1c281..e1632af 100644
--- a/spec/path-spec/general-operation.md
+++ b/spec/path-spec/general-operation.md
@@ -1,4 +1,5 @@
 <a id="path-spec.txt-1"></a>
+
 # General operation
 
 Tor begins building circuits as soon as it has enough directory
@@ -44,6 +45,7 @@ ATTACHSTREAM commands).  Paths constructed through these means may
 violate some constraints given below.
 
 <a id="path-spec.txt-1.1"></a>
+
 ## Terminology
 
 A "path" is an ordered sequence of nodes, not yet built as a circuit.
@@ -74,6 +76,7 @@ is unknown (usually its target IP), but we believe the path probably
 supports the request according to the rules given below.
 
 <a id="path-spec.txt-1.2"></a>
+
 ## A relay's bandwidth
 
 Old versions of Tor did not report bandwidths in network status
@@ -91,4 +94,3 @@ value.
 For more recent versions of Tor, we take the bandwidth value declared
 in the consensus, and fall back to the clipped advertised bandwidth
 only if the consensus does not have bandwidths listed.
-
diff --git a/spec/path-spec/guard-nodes.md b/spec/path-spec/guard-nodes.md
index 6b7bc8b..77f7fdf 100644
--- a/spec/path-spec/guard-nodes.md
+++ b/spec/path-spec/guard-nodes.md
@@ -1,4 +1,5 @@
 <a id="path-spec.txt-5"></a>
+
 # Guard nodes
 
 We use Guard nodes (also called "helper nodes" in the research
@@ -7,6 +8,7 @@ our Guard selection algorithm -- which has grown rather complex -- see
 guard-spec.txt.
 
 <a id="path-spec.txt-5.1"></a>
+
 ## How consensus bandwidth weights factor into entry guard selection
 
 When weighting a list of routers for choosing an entry guard, the following
@@ -29,7 +31,7 @@ If a router has been marked as both an entry guard and an exit, then we
 prefer to use it more, with our preference for doing so (roughly) linearly
 increasing w.r.t. the router's non-guard bandwidth and bandwidth weight
 (calculated without taking the guard flag into account).  From proposal
-#236:
+# 236:
 
 |
 | Let Wpf denote the weight from the 'bandwidth-weights' line a
@@ -40,4 +42,3 @@ increasing w.r.t. the router's non-guard bandwidth and bandwidth weight
 | choose N proportionally to F*Wpf*B + (1-F)*Wpn*B.
 
 where F is the weight as calculated using the above parameters.
-
diff --git a/spec/path-spec/handling-failure.md b/spec/path-spec/handling-failure.md
index d7bb80f..a05fc58 100644
--- a/spec/path-spec/handling-failure.md
+++ b/spec/path-spec/handling-failure.md
@@ -1,4 +1,5 @@
 <a id="path-spec.txt-2.5"></a>
+
 ## Handling failure
 
 If an attempt to extend a circuit fails (either because the first create
@@ -14,4 +15,3 @@ a fresh descriptor for it.
 
 Excessive amounts of either type of failure can indicate an
 attack on anonymity. See section 7 for how excessive failure is handled.
-
diff --git a/spec/path-spec/hidden-service-related-circuits.md b/spec/path-spec/hidden-service-related-circuits.md
index e0e78e3..fc6e30d 100644
--- a/spec/path-spec/hidden-service-related-circuits.md
+++ b/spec/path-spec/hidden-service-related-circuits.md
@@ -1,5 +1,5 @@
 <a id="path-spec.txt-4"></a>
+
 # Hidden-service related circuits
 
 XXX Tracking expected hidden service use (client-side and hidserv-side)
-
diff --git a/spec/path-spec/learning-when-to-give-up-timeout-on-circuit-construction.md b/spec/path-spec/learning-when-to-give-up-timeout-on-circuit-construction.md
index 75f8641..06f6914 100644
--- a/spec/path-spec/learning-when-to-give-up-timeout-on-circuit-construction.md
+++ b/spec/path-spec/learning-when-to-give-up-timeout-on-circuit-construction.md
@@ -1,10 +1,12 @@
 <a id="path-spec.txt-2.4"></a>
+
 ## Learning when to give up ("timeout") on circuit construction
 
 Since version 0.2.2.8-alpha, Tor clients attempt to learn when to give
 up on circuits based on network conditions.
 
 <a id="path-spec.txt-2.4.1"></a>
+
 ### Distribution choice
 
 Based on studies of build times, we found that the distribution of
@@ -16,6 +18,7 @@ in the accuracy of the tail, clients approximate the tail of the multi-modal
 distribution with a single Pareto curve.
 
 <a id="path-spec.txt-2.4.2"></a>
+
 ### How much data to record
 
 From our observations, the minimum number of circuit build times for a
@@ -44,6 +47,7 @@ choose a different persistence mechanism than this histogram, but be aware
 that build time binning is still needed for parameter estimation.
 
 <a id="path-spec.txt-2.4.3"></a>
+
 ### Parameter estimation
 
 Once 'cbtmincircs' build times are recorded, Tor clients update the
@@ -53,7 +57,7 @@ too many circuits timing out).
 
 Tor clients calculate the parameters for a Pareto distribution fitting the
 data using the maximum likelihood estimator. For derivation, see:
-https://en.wikipedia.org/wiki/Pareto_distribution#Estimation_of_parameters
+<https://en.wikipedia.org/wiki/Pareto_distribution#Estimation_of_parameters>
 
 Because build times are not a true Pareto distribution, we alter how Xm is
 computed. In a max likelihood estimator, the mode of the distribution is
@@ -117,6 +121,7 @@ but at least 60 seconds:
 ```
 
 <a id="path-spec.txt-2.4.3"></a>
+
 ### Calculating timeouts thresholds for circuits of different lengths
 
 The timeout_ms and close_ms estimates above are good only for 3-hop
@@ -139,6 +144,7 @@ the client should add X to Actions(N) for every round-trip communication
 required with the Xth hop.
 
 <a id="path-spec.txt-2.4.4"></a>
+
 ### How to record timeouts
 
 Pareto estimators begin to lose their accuracy if the tail is omitted.
@@ -159,6 +165,7 @@ should be ignored, as this typically means one of the relays in the path is
 offline.
 
 <a id="path-spec.txt-2.4.5"></a>
+
 ### Detecting Changing Network Conditions
 
 Tor clients attempt to detect both network connectivity loss and drastic
@@ -179,6 +186,7 @@ recent 'cbrrecentcount') are not stored as persistent state.  On reload,
 we start with a new, empty state.
 
 <a id="path-spec.txt-2.4.6"></a>
+
 ### Consensus parameters governing behavior
 
 Clients that implement circuit build timeout learning should obey the
@@ -290,4 +298,3 @@ the listed default values should be used instead.
         Effect: This is the maximum number of circuits that can be open at
                 at the same time during the circuit build time learning phase.
 ```
-
diff --git a/spec/path-spec/old-notes.md b/spec/path-spec/old-notes.md
index 10623c1..34734fb 100644
--- a/spec/path-spec/old-notes.md
+++ b/spec/path-spec/old-notes.md
@@ -1,7 +1,9 @@
 <a id="path-spec.txt-X"></a>
+
 # Old notes
 
 <a id="path-spec.txt-X.1"></a>
+
 ## Do we actually do this?
 
 ```text
@@ -28,7 +30,8 @@ How to deal with network down.
 remove it. -NM]
 
 <a id="path-spec.txt-X.2"></a>
-## A thing we could do to deal with reachability.
+
+## 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
@@ -39,7 +42,8 @@ likely (though not certain) that some of the originals will become useful.
 Is that smart or just complex?
 
 <a id="path-spec.txt-X.3"></a>
-## Some stuff that worries me about entry guards. 2006 Jun, Nickm.
+
+## 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
@@ -57,4 +61,3 @@ our location (IP? subnet?) changes, we have two bad options.  We could
 
 [Do we do any of this now? If not, this should move into 099-misc or
 098-todo. -NM]
-
diff --git a/spec/path-spec/path-selection-constraints.md b/spec/path-spec/path-selection-constraints.md
index f590b36..694a052 100644
--- a/spec/path-spec/path-selection-constraints.md
+++ b/spec/path-spec/path-selection-constraints.md
@@ -1,4 +1,5 @@
 <a id="path-spec.txt-2.2"></a>
+
 ## Path selection and constraints
 
 We choose the path for each new circuit before we build it.  We choose the
@@ -86,6 +87,7 @@ mind.  Each kind of request puts certain constraints on paths:
 ```
 
 <a id="path-spec.txt-2.2.1"></a>
+
 ### Choosing an exit
 
 If we know what IP address we want to connect to or resolve, we can
@@ -104,6 +106,7 @@ flagged as "BadExit" by more than half of the authorities who advertise
 themselves as listing bad exits.
 
 <a id="path-spec.txt-2.2.2"></a>
+
 ### User configuration
 
 Users can alter the default behavior for path selection with configuration
@@ -127,4 +130,3 @@ options.
      in the path. They also allow the guard node to be chosen as the RP, IP,
      and HSDIR, and as the hop before those positions.
 ```
-
diff --git a/spec/path-spec/server-descriptor-purposes.md b/spec/path-spec/server-descriptor-purposes.md
index 6e3a71e..3a7dca0 100644
--- a/spec/path-spec/server-descriptor-purposes.md
+++ b/spec/path-spec/server-descriptor-purposes.md
@@ -1,4 +1,5 @@
 <a id="path-spec.txt-6"></a>
+
 # Server descriptor purposes
 
 There are currently three "purposes" supported for server descriptors:
@@ -16,4 +17,3 @@ 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.
-
diff --git a/spec/path-spec/when-we-build.md b/spec/path-spec/when-we-build.md
index 4320c58..ca9b704 100644
--- a/spec/path-spec/when-we-build.md
+++ b/spec/path-spec/when-we-build.md
@@ -1,7 +1,9 @@
 <a id="path-spec.txt-2.1"></a>
+
 ## When we build
 
 <a id="path-spec.txt-2.1.0"></a>
+
 ### We don't build circuits until we have enough directory info
 
 There's a class of possible attacks where our directory servers
@@ -56,6 +58,7 @@ If the consensus lists zero exit-flagged relays, Tor instead uses the
 fraction of middle relays.
 
 <a id="path-spec.txt-2.1.1"></a>
+
 ### Clients build circuits preemptively
 
 When running as a client, Tor tries to maintain at least a certain
@@ -90,6 +93,7 @@ The Tor client SHOULD NOT store its list of predicted requests to a
 persistent medium.
 
 <a id="path-spec.txt-2.1.2"></a>
+
 ### Clients build circuits on demand
 
 Additionally, when a client request exists that no circuit (built or
@@ -109,6 +113,7 @@ In some cases we can reuse an already established circuit if it's
 clean; see Section 2.3 (cannibalizing circuits) for details.
 
 <a id="path-spec.txt-2.1.3"></a>
+
 ### Relays build circuits for testing reachability and bandwidth
 
 Tor relays test reachability of their ORPort once they have
@@ -131,11 +136,13 @@ established a circuit, but they use an ordinary exit circuit for
 this purpose.
 
 <a id="path-spec.txt-2.1.4"></a>
+
 ### Hidden-service circuits
 
 See section 4 below.
 
 <a id="path-spec.txt-2.1.5"></a>
+
 ### Rate limiting of failed circuits
 
 If we fail to build a circuit N times in a X second period (see Section
@@ -144,6 +151,7 @@ have elapsed.
 XXXX
 
 <a id="path-spec.txt-2.1.6"></a>
+
 ### When to tear down circuits
 
 Clients should tear down circuits (in general) only when those circuits
@@ -158,4 +166,3 @@ stream-less circuits only under one of the following conditions:
      - The circuit is dirty (has had a stream attached), and it has been
        dirty for at least MaxCircuitDirtiness.
 ```
-