5 files changed, 21 insertions, 21 deletions
diff --git a/spec/path-spec/cannibalizing-circuits.md b/spec/path-spec/cannibalizing-circuits.md
index 2d15175..3987839 100644
--- a/spec/path-spec/cannibalizing-circuits.md
+++ b/spec/path-spec/cannibalizing-circuits.md
@@ -1,6 +1,6 @@
 <a id="path-spec.txt-2.3"></a>
 
-## Cannibalizing circuits
+# 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
diff --git a/spec/path-spec/handling-failure.md b/spec/path-spec/handling-failure.md
index a05fc58..27bad6a 100644
--- a/spec/path-spec/handling-failure.md
+++ b/spec/path-spec/handling-failure.md
@@ -1,6 +1,6 @@
 <a id="path-spec.txt-2.5"></a>
 
-## Handling failure
+# 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
diff --git a/spec/path-spec/learning-timeouts.md b/spec/path-spec/learning-timeouts.md
index e53ab66..3685274 100644
--- a/spec/path-spec/learning-timeouts.md
+++ b/spec/path-spec/learning-timeouts.md
@@ -1,13 +1,13 @@
 <a id="path-spec.txt-2.4"></a>
 
-## Learning when to give up ("timeout") on circuit construction {#timing-out}
+# Learning when to give up ("timeout") on circuit construction {#timing-out}
 
 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
+## Distribution choice
 
 Based on studies of build times, we found that the distribution of
 circuit build times appears to be a Frechet distribution (and a multi-modal
@@ -19,7 +19,7 @@ distribution with a single Pareto curve.
 
 <a id="path-spec.txt-2.4.2"></a>
 
-### How much data to record {#observations}
+## How much data to record {#observations}
 
 From our observations, the minimum number of circuit build times for a
 reasonable fit appears to be on the order of 100. However, to keep a
@@ -48,7 +48,7 @@ that build time binning is still needed for parameter estimation.
 
 <a id="path-spec.txt-2.4.3"></a>
 
-### Parameter estimation
+## Parameter estimation
 
 Once 'cbtmincircs' build times are recorded, Tor clients update the
 distribution parameters and recompute the timeout every circuit completion
@@ -122,7 +122,7 @@ but at least 60 seconds:
 
 <a id="path-spec.txt-2.4.3"></a>
 
-### Calculating timeouts thresholds for circuits of different lengths {#different-lengths}
+## Calculating timeouts thresholds for circuits of different lengths {#different-lengths}
 
 The timeout_ms and close_ms estimates above are good only for 3-hop
 circuits, since only 3-hop circuits are recorded in the list of build
@@ -145,7 +145,7 @@ required with the Xth hop.
 
 <a id="path-spec.txt-2.4.4"></a>
 
-### How to record timeouts {#recording-timeouts}
+## How to record timeouts {#recording-timeouts}
 
 Pareto estimators begin to lose their accuracy if the tail is omitted.
 Hence, Tor clients actually calculate two timeouts: a usage timeout, and a
@@ -166,7 +166,7 @@ offline.
 
 <a id="path-spec.txt-2.4.5"></a>
 
-### Detecting Changing Network Conditions {#changes-in-network}
+## Detecting Changing Network Conditions {#changes-in-network}
 
 Tor clients attempt to detect both network connectivity loss and drastic
 changes in the timeout characteristics.
@@ -187,7 +187,7 @@ we start with a new, empty state.
 
 <a id="path-spec.txt-2.4.6"></a>
 
-### Consensus parameters governing behavior {#parameters}
+## Consensus parameters governing behavior {#parameters}
 
 Clients that implement circuit build timeout learning should obey the
 following consensus parameters that govern behavior, in order to allow
diff --git a/spec/path-spec/path-selection-constraints.md b/spec/path-spec/path-selection-constraints.md
index 694a052..d31e45f 100644
--- a/spec/path-spec/path-selection-constraints.md
+++ b/spec/path-spec/path-selection-constraints.md
@@ -1,6 +1,6 @@
 <a id="path-spec.txt-2.2"></a>
 
-## Path selection and constraints
+# 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, front to
@@ -88,7 +88,7 @@ mind.  Each kind of request puts certain constraints on paths:
 
 <a id="path-spec.txt-2.2.1"></a>
 
-### Choosing an exit
+## 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
@@ -107,7 +107,7 @@ themselves as listing bad exits.
 
 <a id="path-spec.txt-2.2.2"></a>
 
-### User configuration
+## User configuration
 
 Users can alter the default behavior for path selection with configuration
 options.
diff --git a/spec/path-spec/when-we-build.md b/spec/path-spec/when-we-build.md
index ca9b704..cbcf7da 100644
--- a/spec/path-spec/when-we-build.md
+++ b/spec/path-spec/when-we-build.md
@@ -1,10 +1,10 @@
 <a id="path-spec.txt-2.1"></a>
 
-## When we build
+# When we build
 
 <a id="path-spec.txt-2.1.0"></a>
 
-### We don't build circuits until we have enough directory info
+## We don't build circuits until we have enough directory info
 
 There's a class of possible attacks where our directory servers
 only give us information about the relays that they would like us
@@ -59,7 +59,7 @@ fraction of middle relays.
 
 <a id="path-spec.txt-2.1.1"></a>
 
-### Clients build circuits preemptively
+## 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
@@ -94,7 +94,7 @@ persistent medium.
 
 <a id="path-spec.txt-2.1.2"></a>
 
-### Clients build circuits on demand
+## 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.
@@ -114,7 +114,7 @@ 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
+## Relays build circuits for testing reachability and bandwidth
 
 Tor relays test reachability of their ORPort once they have
 successfully built a circuit (on startup and whenever their IP address
@@ -137,13 +137,13 @@ this purpose.
 
 <a id="path-spec.txt-2.1.4"></a>
 
-### Hidden-service circuits
+## Hidden-service circuits
 
 See section 4 below.
 
 <a id="path-spec.txt-2.1.5"></a>
 
-### Rate limiting of failed circuits
+## 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
@@ -152,7 +152,7 @@ XXXX
 
 <a id="path-spec.txt-2.1.6"></a>
 
-### When to tear down circuits
+## When to tear down circuits
 
 Clients should tear down circuits (in general) only when those circuits
 have no streams on them.  Additionally, clients should tear-down