20 files changed, 79 insertions, 24 deletions
diff --git a/spec/tor-spec/application-connections-stream-management.md b/spec/tor-spec/application-connections-stream-management.md
index 53b9b97..e30ce8b 100644
--- a/spec/tor-spec/application-connections-stream-management.md
+++ b/spec/tor-spec/application-connections-stream-management.md
@@ -1,3 +1,3 @@
 <a id="tor-spec.txt-6"></a>
-# Application connections and stream management
 
+# Application connections and stream management
diff --git a/spec/tor-spec/cell-packet-format.md b/spec/tor-spec/cell-packet-format.md
index b26f012..2550da3 100644
--- a/spec/tor-spec/cell-packet-format.md
+++ b/spec/tor-spec/cell-packet-format.md
@@ -1,4 +1,5 @@
 <a id="tor-spec.txt-3"></a>
+
 # Cell Packet format
 
 The basic unit of communication for onion routers and onion
@@ -121,4 +122,3 @@ VERSIONS and NETINFO cells are used to set up connections in link
 protocols v2 and higher; in link protocol v3 and higher, CERTS,
 AUTH_CHALLENGE, and AUTHENTICATE may also be used.  See section 4
 below.
-
diff --git a/spec/tor-spec/circuit-management.md b/spec/tor-spec/circuit-management.md
index 3784bab..30e3284 100644
--- a/spec/tor-spec/circuit-management.md
+++ b/spec/tor-spec/circuit-management.md
@@ -1,3 +1,3 @@
 <a id="tor-spec.txt-5"></a>
-# Circuit management
 
+# Circuit management
diff --git a/spec/tor-spec/closing-streams.md b/spec/tor-spec/closing-streams.md
index c85b3cc..9ef1b98 100644
--- a/spec/tor-spec/closing-streams.md
+++ b/spec/tor-spec/closing-streams.md
@@ -1,4 +1,5 @@
 <a id="tor-spec.txt-6.3"></a>
+
 ## Closing streams
 
 When an anonymized TCP connection is closed, or an edge node
@@ -97,4 +98,3 @@ to 'CLOSED'.  When a stream already in 'DONE_PACKAGING' receives a
 
 If an edge node encounters an error on any stream, it sends a
 'RELAY_END' cell (if possible) and closes the stream immediately.
-
diff --git a/spec/tor-spec/connections.md b/spec/tor-spec/connections.md
index d540489..a7ba661 100644
--- a/spec/tor-spec/connections.md
+++ b/spec/tor-spec/connections.md
@@ -1,4 +1,5 @@
 <a id="tor-spec.txt-2"></a>
+
 # Connections
 
 Connections between two Tor relays, or between a client and a relay,
@@ -158,6 +159,7 @@ their IP address changes.  Clients MAY send certificates using any
 of the above handshake variants.
 
 <a id="tor-spec.txt-2.1"></a>
+
 ## Picking TLS ciphersuites
 
 Clients SHOULD send a ciphersuite list chosen to emulate some popular
@@ -217,6 +219,7 @@ less than HASH_LEN bits.  Responders SHOULD NOT select any SSLv3
 ciphersuite other than the DHE+3DES suites listed above.
 
 <a id="tor-spec.txt-2.2"></a>
+
 ## TLS security considerations
 
 Implementations MUST NOT allow TLS session resumption -- it can
@@ -226,4 +229,3 @@ Feb 2013), and it plays havoc with forward secrecy guarantees.
 Implementations SHOULD NOT allow TLS compression -- although we don't
 know a way to apply a CRIME-style attack to current Tor directly,
 it's a waste of resources.
-
diff --git a/spec/tor-spec/create-created-cells.md b/spec/tor-spec/create-created-cells.md
index a6d36a9..56134e4 100644
--- a/spec/tor-spec/create-created-cells.md
+++ b/spec/tor-spec/create-created-cells.md
@@ -1,4 +1,5 @@
 <a id="tor-spec.txt-5.1"></a>
+
 ## CREATE and CREATED cells
 
 Users set up circuits incrementally, one hop at a time. To create a
@@ -69,6 +70,7 @@ DESTROY cell to tear down the circuit.
 [CREATE2 is handled by Tor 0.2.4.7-alpha and later.]
 
 <a id="tor-spec.txt-5.1.1"></a>
+
 ### Choosing circuit IDs in create cells
 
 The CircID for a CREATE/CREATE2 cell is a nonzero integer, selected
@@ -102,6 +104,7 @@ attempting to build new circuits on a channel, if a certain number of
 randomly chosen CircID values are all in use (today's Tor stops after 64).
 
 <a id="tor-spec.txt-5.1.2"></a>
+
 ### EXTEND and EXTENDED cells
 
 To extend an existing circuit, the client sends an EXTEND or EXTEND2
@@ -202,6 +205,7 @@ When encoding a non-TAP handshake in an EXTEND cell, clients SHOULD
 use the format with 'client handshake type tag'.
 
 <a id="tor-spec.txt-5.1.3"></a>
+
 ### The "TAP" handshake
 
 This handshake uses Diffie-Hellman in Z_p and RSA to compute a set of
@@ -255,6 +259,7 @@ Once both parties have g^xy, they derive their shared circuit keys
 and 'derivative key data' value via the KDF-TOR function in 5.2.1.
 
 <a id="tor-spec.txt-5.1.4"></a>
+
 ### The "ntor" handshake
 
 This handshake uses a set of DH handshakes to compute a set of
@@ -333,6 +338,7 @@ into the keys needed for the Tor relay protocol, using the KDF
 described in 5.2.2 and the tag m_expand.
 
 <a id="tor-spec.txt-5.1.4.1"></a>
+
 #### The "ntor-v3" handshake
 
 This handshake extends the ntor handshake to include support
@@ -488,6 +494,7 @@ Now both parties share the same KEYSTREAM, and can use it to generate
 their circuit keys.
 
 <a id="tor-spec.txt-5.1.5"></a>
+
 ### CREATE_FAST/CREATED_FAST cells
 
 When initializing the first hop of a circuit, the OP has already
@@ -521,6 +528,7 @@ networkstatus parameter as described in dir-spec.txt.
 [Tor 0.3.1.1-alpha and later disable CREATE_FAST by default.]
 
 <a id="tor-spec.txt-5.1.6"></a>
+
 ### Additional data in CREATE/CREATED cells
 
 Some handshakes (currently ntor-v3 defined above) allow the client or the
@@ -571,4 +579,3 @@ format:
 
                 sendme_inc        [1 byte]
 ```
-
diff --git a/spec/tor-spec/creating-circuits.md b/spec/tor-spec/creating-circuits.md
index 31bd6a3..c69d2cf 100644
--- a/spec/tor-spec/creating-circuits.md
+++ b/spec/tor-spec/creating-circuits.md
@@ -1,4 +1,5 @@
 <a id="tor-spec.txt-5.3"></a>
+
 ## Creating circuits
 
 When creating a circuit through the network, the circuit creator
@@ -79,6 +80,7 @@ until a break in traffic allows time to do so without harming
 network latency too greatly.)
 
 <a id="tor-spec.txt-5.3.1"></a>
+
 ### Canonical connections
 
 It is possible for an attacker to launch a man-in-the-middle attack
@@ -101,4 +103,3 @@ conditions hold:
     Trusting server IPs makes it easier to covertly impersonate a relay, after
     stealing its keys.
 ```
-
diff --git a/spec/tor-spec/flow-control.md b/spec/tor-spec/flow-control.md
index 4bd8910..960bd21 100644
--- a/spec/tor-spec/flow-control.md
+++ b/spec/tor-spec/flow-control.md
@@ -1,7 +1,9 @@
 <a id="tor-spec.txt-7"></a>
+
 # Flow control
 
 <a id="tor-spec.txt-7.1"></a>
+
 ## Link throttling
 
 Each client or relay should do appropriate bandwidth throttling to
@@ -25,6 +27,7 @@ to reads and writes for connections that are serving directory
 information. See proposal 111 for details.
 
 <a id="tor-spec.txt-7.2"></a>
+
 ## Link padding
 
 Link padding can be created by sending PADDING or VPADDING cells
@@ -60,6 +63,7 @@ zero (to avoid client distinguishability) and ignored by the recipient.
 For more details on padding behavior, see padding-spec.txt.
 
 <a id="tor-spec.txt-7.3"></a>
+
 ## Circuit-level flow control
 
 To control a circuit's bandwidth usage, each OR keeps track of two
@@ -111,6 +115,7 @@ RELAY_DATA cell within one increment window. In other word, every 100 cells
 (increment), random bytes should be introduced in at least one cell.
 
 <a id="tor-spec.txt-7.3.1"></a>
+
 ### SENDME Cell Format
 
 A circuit-level RELAY_SENDME cell always has its StreamID=0.
@@ -163,6 +168,7 @@ If the VERSION is unrecognized or below the minimum accepted version (taken
 from the consensus), the circuit should be torn down.
 
 <a id="tor-spec.txt-7.4"></a>
+
 ## Stream-level flow control
 
 Edge nodes use RELAY_SENDME cells to implement end-to-end flow
@@ -175,4 +181,3 @@ ten cell payloads remaining to be flushed at that edge.
 
 Stream-level RELAY_SENDME cells are distinguished by having nonzero
 StreamID. They are still empty; the body still SHOULD be ignored.
-
diff --git a/spec/tor-spec/handling-relay_early-cells.md b/spec/tor-spec/handling-relay_early-cells.md
index e88c946..9adbced 100644
--- a/spec/tor-spec/handling-relay_early-cells.md
+++ b/spec/tor-spec/handling-relay_early-cells.md
@@ -1,4 +1,5 @@
 <a id="tor-spec.txt-5.6"></a>
+
 ## Handling relay_early cells
 
 A RELAY_EARLY cell is designed to limit the length any circuit can reach.
@@ -17,4 +18,3 @@ RELAY_EARLY cells too, in order to partially conceal the circuit length.
 
 [Starting with Tor 0.2.3.11-alpha, relays should reject any
 EXTEND/EXTEND2 cell not received in a RELAY_EARLY cell.]
-
diff --git a/spec/tor-spec/handling-resource-exhaustion.md b/spec/tor-spec/handling-resource-exhaustion.md
index b8e89eb..7179066 100644
--- a/spec/tor-spec/handling-resource-exhaustion.md
+++ b/spec/tor-spec/handling-resource-exhaustion.md
@@ -1,8 +1,10 @@
 <a id="tor-spec.txt-8"></a>
+
 # Handling resource exhaustion
 
 <a id="tor-spec.txt-8.1"></a>
-## Memory exhaustion.
+
+## Memory exhaustion
 
 (See also dos-spec.md.)
 
@@ -29,4 +31,3 @@ more memory is free again.  We recommend the following algorithm:
             cells in both directions on that circuit.  Count the amount of
             memory we recovered towards the total.
 ```
-
diff --git a/spec/tor-spec/negotiating-initializing-connections.md b/spec/tor-spec/negotiating-initializing-connections.md
index d281761..dd9be1d 100644
--- a/spec/tor-spec/negotiating-initializing-connections.md
+++ b/spec/tor-spec/negotiating-initializing-connections.md
@@ -1,4 +1,5 @@
 <a id="tor-spec.txt-4"></a>
+
 # Negotiating and initializing connections
 
 After Tor instances negotiate handshake with either the "renegotiation" or
@@ -35,6 +36,7 @@ and did not permit any command other than VERSIONS as the first cell of
 the in-protocol handshake.]
 
 <a id="tor-spec.txt-4.1"></a>
+
 ## Negotiating versions with VERSIONS cells
 
 There are multiple instances of the Tor link connection protocol.  Any
@@ -87,6 +89,7 @@ Link protocols differences are:
 ```
 
 <a id="tor-spec.txt-4.2"></a>
+
 ## CERTS cells
 
 The CERTS cell describes the keys that a Tor instance is claiming
@@ -214,6 +217,7 @@ initiator has the ID it claims; to do so, the cells in 4.3 and 4.4
 below must be exchanged.
 
 <a id="tor-spec.txt-4.3"></a>
+
 ## AUTH_CHALLENGE cells
 
 An AUTH_CHALLENGE cell is a variable-length cell with the following
@@ -236,6 +240,7 @@ accept.  Only two authentication methods are defined right now:
 see 4.4.1 and 4.4.2 below.
 
 <a id="tor-spec.txt-4.4"></a>
+
 ## AUTHENTICATE cells
 
 If an initiator wants to authenticate, it responds to the
@@ -266,6 +271,7 @@ verified the certificates presented in the responder's CERTS
 cell, and authenticated the responder.
 
 <a id="tor-spec.txt-4.4.1"></a>
+
 ### Link authentication type 1: RSA-SHA256-TLSSecret
 
 If AuthType is 1 (meaning "RSA-SHA256-TLSSecret"), then the
@@ -315,7 +321,8 @@ claimed to have an Ed25519 identity.
 (There is no AuthType 2: It was reserved but never implemented.)
 
 <a id="tor-spec.txt-4.4.2"></a>
-### Link authentication type 3: Ed25519-SHA256-RFC5705.
+
+### Link authentication type 3: Ed25519-SHA256-RFC5705
 
 If AuthType is 3, meaning "Ed25519-SHA256-RFC5705", the
 Authentication field of the AuthType cell is as below:
@@ -357,6 +364,7 @@ The server MUST ignore any extra bytes in the signed data after
 the RAND field.
 
 <a id="tor-spec.txt-4.5"></a>
+
 ## NETINFO cells
 
 If version 2 or higher is negotiated, each party sends the other a
@@ -400,4 +408,3 @@ since the other party can lie about the time or IP addresses it sees.
 Initiators SHOULD use "this OR's address" to make sure
 that they have connected to another OR at its canonical address.
 (See 5.3.1 below.)
-
diff --git a/spec/tor-spec/opening-streams-transferring-data.md b/spec/tor-spec/opening-streams-transferring-data.md
index dc92d51..8300ace 100644
--- a/spec/tor-spec/opening-streams-transferring-data.md
+++ b/spec/tor-spec/opening-streams-transferring-data.md
@@ -1,4 +1,5 @@
 <a id="tor-spec.txt-6.2"></a>
+
 ## Opening streams and transferring data
 
 To open a new anonymized TCP connection, the OP chooses an open
@@ -88,6 +89,7 @@ Relay RELAY_DROP cells are long-range dummies; upon receiving such
 a cell, the OR or OP must drop it.
 
 <a id="tor-spec.txt-6.2.1"></a>
+
 ### Opening a directory stream
 
 If a Tor relay is a directory server, it should respond to a
@@ -96,6 +98,7 @@ connection to its directory port.  RELAY_BEGIN_DIR cells ignore exit
 policy, since the stream is local to the Tor process.
 
 Directory servers may be:
+
 * authoritative directories (RELAY_BEGIN_DIR, usually non-anonymous),
 * bridge authoritative directories (RELAY_BEGIN_DIR, anonymous),
 * directory mirrors (RELAY_BEGIN_DIR, usually non-anonymous),
@@ -114,4 +117,3 @@ the payload.
 
 [RELAY_BEGIN_DIR was not supported before Tor 0.1.2.2-alpha; clients
 SHOULD NOT send it to routers running earlier versions of Tor.]
-
diff --git a/spec/tor-spec/preliminaries.md b/spec/tor-spec/preliminaries.md
index 5cb0410..c97e774 100644
--- a/spec/tor-spec/preliminaries.md
+++ b/spec/tor-spec/preliminaries.md
@@ -1,4 +1,5 @@
 <a id="tor-spec.txt-0"></a>
+
 # Preliminaries
 
 ```text
@@ -9,6 +10,7 @@
 ```
 
 <a id="tor-spec.txt-0.1"></a>
+
 ## Notation and encoding
 
 ```text
@@ -31,6 +33,7 @@ We use "byte" and "octet" interchangeably.  Possibly we shouldn't.
 Some specs mention "base32".  This means RFC4648, without "=" padding.
 
 <a id="tor-spec.txt-0.1.1"></a>
+
 ### Encoding integers
 
 Unless we explicitly say otherwise below, all numeric values in the
@@ -39,6 +42,7 @@ integer" means a big-endian 32-bit integer; a "2-byte" integer means
 a big-endian 16-bit integer, and so forth.
 
 <a id="tor-spec.txt-0.2"></a>
+
 ## Security parameters
 
 Tor uses a stream cipher, a public-key cipher, the Diffie-Hellman
@@ -67,6 +71,7 @@ KEY_LEN -- the length of the stream cipher's key, in bytes.
 ```
 
 <a id="tor-spec.txt-0.3"></a>
+
 ## Ciphers
 
 These are the ciphers we use _unless otherwise specified_.  Several of
@@ -122,7 +127,8 @@ strong pseudorandom number generator seeded from a strong entropy
 source, unless otherwise noted.
 
 <a id="tor-spec.txt-0.4"></a>
-## A bad hybrid encryption algorithm, for legacy purposes.
+
+## A bad hybrid encryption algorithm, for legacy purposes
 
 Some specifications will refer to the "legacy hybrid encryption" of a
 byte sequence M with a public key KP.  It is computed as follows:
@@ -143,4 +149,3 @@ allows attackers to modify the bytes not covered by the OAEP --
 see Goldberg's PET2006 paper for details.  Do not use it as the basis
 for new protocols! Also note that as used in Tor's protocols, case 1
 never occurs.
-
diff --git a/spec/tor-spec/relay-cells.md b/spec/tor-spec/relay-cells.md
index 2f89832..68e0391 100644
--- a/spec/tor-spec/relay-cells.md
+++ b/spec/tor-spec/relay-cells.md
@@ -1,4 +1,5 @@
 <a id="tor-spec.txt-6.1"></a>
+
 ## Relay cells
 
 Within a circuit, the OP and the end node use the contents of
@@ -7,6 +8,7 @@ RELAY packets to tunnel end-to-end commands and TCP connections
 by either edge; streams are initiated by the OP.
 
 End nodes that accept streams may be:
+
 * exit relays (RELAY_BEGIN, anonymous),
 * directory servers (RELAY_BEGIN_DIR, anonymous or non-anonymous),
 * onion services (RELAY_BEGIN, anonymous via a rendezvous point).
@@ -113,6 +115,7 @@ understood, the cell must be dropped and ignored. Its contents
 still count with respect to the digests and flow control windows, though.
 
 <a id="tor-spec.txt-6.1.1"></a>
+
 ### Calculating the 'Digest' field
 
 The 'Digest' field itself serves the purpose to check if a cell has been
@@ -156,4 +159,3 @@ The caveat itself is that only the binary data with the digest bytes set to
 zero are being taken into account when calculating the running digest.  The
 final plain-text cells (with the digest field set to its actual value) are
 not taken into the running digest.
-
diff --git a/spec/tor-spec/remote-hostname-lookup.md b/spec/tor-spec/remote-hostname-lookup.md
index 3abb2cf..ba78cf1 100644
--- a/spec/tor-spec/remote-hostname-lookup.md
+++ b/spec/tor-spec/remote-hostname-lookup.md
@@ -1,4 +1,5 @@
 <a id="tor-spec.txt-6.4"></a>
+
 ## Remote hostname lookup
 
 To find the address associated with a hostname, the OP sends a
@@ -40,4 +41,3 @@ of the form:
     corresponding RELAY_RESOLVED cell must use the same streamID.  No stream
     is actually created by the OR when resolving the name.
 ```
-
diff --git a/spec/tor-spec/routing-relay-cells.md b/spec/tor-spec/routing-relay-cells.md
index 95888f7..e2c784c 100644
--- a/spec/tor-spec/routing-relay-cells.md
+++ b/spec/tor-spec/routing-relay-cells.md
@@ -1,7 +1,9 @@
 <a id="tor-spec.txt-5.5"></a>
+
 ## Routing relay cells
 
 <a id="tor-spec.txt-5.5.1"></a>
+
 ### Circuit ID Checks
 
 When a node wants to send a RELAY or RELAY_EARLY cell, it checks the cell's
@@ -13,12 +15,14 @@ circID and determines whether it has a corresponding circuit along
 that connection. If not, the node drops the cell.
 
 <a id="tor-spec.txt-5.5.2"></a>
+
 ### Forward Direction
 
 The forward direction is the direction that CREATE/CREATE2 cells
 are sent.
 
 <a id="tor-spec.txt-5.5.2.1"></a>
+
 #### Routing from the Origin
 
 When a relay cell is sent from an OP, the OP encrypts the payload
@@ -32,6 +36,7 @@ with the stream cipher as follows:
 ```
 
 <a id="tor-spec.txt-5.5.2.2"></a>
+
 #### Relaying Forward at Onion Routers
 
 When a forward relay cell is received by an OR, it decrypts the payload
@@ -53,12 +58,14 @@ sends a DESTROY cell to tear down the circuit.
 For more information, see section 6 below.
 
 <a id="tor-spec.txt-5.5.3"></a>
+
 ### Backward Direction
 
 The backward direction is the opposite direction from
 CREATE/CREATE2 cells.
 
 <a id="tor-spec.txt-5.5.3.1"></a>
+
 #### Relaying Backward at Onion Routers
 
 When a backward relay cell is received by an OR, it encrypts the payload
@@ -70,6 +77,7 @@ with the stream cipher, as follows:
 ```
 
 <a id="tor-spec.txt-5.5.3"></a>
+
 ### Routing to the Origin
 
 When a relay cell arrives at an OP, the OP decrypts the payload
@@ -83,4 +91,3 @@ with the stream cipher as follows:
                     The sending node is I.
                     Stop and process the payload.
 ```
-
diff --git a/spec/tor-spec/setting-circuit-keys.md b/spec/tor-spec/setting-circuit-keys.md
index d566ff6..b49f75d 100644
--- a/spec/tor-spec/setting-circuit-keys.md
+++ b/spec/tor-spec/setting-circuit-keys.md
@@ -1,7 +1,9 @@
 <a id="tor-spec.txt-5.2"></a>
+
 ## Setting circuit keys
 
 <a id="tor-spec.txt-5.2.1"></a>
+
 ### KDF-TOR
 
 This key derivation function is used by the TAP and CREATE_FAST
@@ -33,6 +35,7 @@ is used to encrypt the stream of data going from the OP to the OR, and
 Kb is used to encrypt the stream of data going from the OR to the OP.
 
 <a id="tor-spec.txt-5.2.2"></a>
+
 ### KDF-RFC5869
 
 For newer KDF needs, Tor uses the key derivation function HKDF from
@@ -57,4 +60,3 @@ forward digest Df; the next HASH_LEN form the backward digest Db; the
 next KEY_LEN form Kf, the next KEY_LEN form Kb, and the final
 DIGEST_LEN bytes are taken as a nonce to use in the place of KH in the
 hidden service protocol.  Excess bytes from K are discarded.
-
diff --git a/spec/tor-spec/subprotocol-versioning.md b/spec/tor-spec/subprotocol-versioning.md
index 0fd5388..3611c73 100644
--- a/spec/tor-spec/subprotocol-versioning.md
+++ b/spec/tor-spec/subprotocol-versioning.md
@@ -1,4 +1,5 @@
 <a id="tor-spec.txt-9"></a>
+
 # Subprotocol versioning
 
 This section specifies the Tor subprotocol versioning. They are broken down
@@ -57,6 +58,7 @@ For relays, we will additionally Recommend all protocols which we
 recommend for clients.
 
 <a id="tor-spec.txt-9.1"></a>
+
 ## "Link"
 
 The "link" protocols are those used by clients and relays to initiate and
@@ -72,6 +74,7 @@ information. All current Tor versions support "1-3"; versions from
 support "1-5". Eventually we will drop "1" and "2".
 
 <a id="tor-spec.txt-9.2"></a>
+
 ## "LinkAuth"
 
 LinkAuth protocols correspond to varieties of Authenticate cells used for
@@ -86,6 +89,7 @@ Current versions are:
 "3" is the ed25519 link authentication described in 4.4.2 above.
 
 <a id="tor-spec.txt-9.3"></a>
+
 ## "Relay"
 
 The "relay" protocols are those used to handle CREATE/CREATE2
@@ -159,6 +163,7 @@ Current versions are:
 ```
 
 <a id="tor-spec.txt-9.4"></a>
+
 ## "HSIntro"
 
 The "HSIntro" protocol handles introduction points.
@@ -175,6 +180,7 @@ The "HSIntro" protocol handles introduction points.
 ```
 
 <a id="tor-spec.txt-9.5"></a>
+
 ## "HSRend"
 
 The "HSRend" protocol handles rendezvous points.
@@ -187,6 +193,7 @@ The "HSRend" protocol handles rendezvous points.
 ```
 
 <a id="tor-spec.txt-9.6"></a>
+
 ## "HSDir"
 
 The "HSDir" protocols are the set of hidden service document types that can
@@ -201,6 +208,7 @@ of URLs available to fetch them.
 ```
 
 <a id="tor-spec.txt-9.7"></a>
+
 ## "DirCache"
 
 The "DirCache" protocols are the set of documents available for download
@@ -212,6 +220,7 @@ fetch them.  (This excludes URLs for hidden service objects.)
 "2" -- adds support for consensus diffs in Tor 0.3.1.1-alpha.
 
 <a id="tor-spec.txt-9.8"></a>
+
 ## "Desc"
 
 Describes features present or absent in descriptors.
@@ -226,6 +235,7 @@ to understand ed25519 identities.
 identities.
 
 <a id="tor-spec.txt-9.9"></a>
+
 ## "Microdesc"
 
 Describes features present or absent in microdescriptors.
@@ -239,6 +249,7 @@ consensus methods.
 "2" -- consensus method 21 (adds ed25519 keys to microdescs).
 
 <a id="tor-spec.txt-9.10"></a>
+
 ## "Cons"
 
 Describes features present or absent in consensus documents.
@@ -253,6 +264,7 @@ These correspond more or less with consensus methods.
 "2" -- consensus method 21 (adds ed25519 keys to microdescs).
 
 <a id="tor-spec.txt-9.11"></a>
+
 ## "Padding"
 
 Describes the padding capabilities of the relay.
@@ -268,6 +280,7 @@ Describes the padding capabilities of the relay.
 ```
 
 <a id="tor-spec.txt-9.12"></a>
+
 ## "FlowCtrl"
 
 Describes the flow control protocol at the circuit and stream level. If
@@ -284,6 +297,7 @@ control features (version 0).
 ```
 
 <a id="tor-spec.txt-9.13"></a>
+
 ## "Datagram"
 
 Describes the UDP protocol capabilities of a relay.
@@ -293,4 +307,3 @@ Describes the UDP protocol capabilities of a relay.
           CONNECT_UDP, CONNECTED_UDP and DATAGRAM. See proposal
           339 for more details. (Not yet advertised, reserved)
 ```
-
diff --git a/spec/tor-spec/system-overview.md b/spec/tor-spec/system-overview.md
index 4897d95..8577928 100644
--- a/spec/tor-spec/system-overview.md
+++ b/spec/tor-spec/system-overview.md
@@ -1,16 +1,18 @@
 <a id="tor-spec.txt-1"></a>
+
 # System overview
 
 Tor is a distributed overlay network designed to anonymize
 low-latency TCP-based applications such as web browsing, secure shell,
 and instant messaging. Clients choose a path through the network and
-build a ``circuit'', in which each node (or ``onion router'' or ``OR'')
+build a ``circuit'', in which each node (or``onion router'' or ``OR'')
 in the path knows its predecessor and successor, but no other nodes in
 the circuit.  Traffic flowing down the circuit is sent in fixed-size
 ``cells'', which are unwrapped by a symmetric key at each node (like
 the layers of an onion) and relayed downstream.
 
 <a id="tor-spec.txt-1.1"></a>
+
 ## Keys and names
 
 Every Tor relay has multiple public/private keypairs:
@@ -70,4 +72,3 @@ The same key or keypair should never be used for separate roles within
 the Tor protocol suite, unless specifically stated.  For example,
 a relay's identity keys K_relayid should not also be used as the
 identity keypair for a hidden service K_hs_id (see rend-spec-v3.txt).
-
diff --git a/spec/tor-spec/tearing-down-circuits.md b/spec/tor-spec/tearing-down-circuits.md
index 52f1cc8..3008c05 100644
--- a/spec/tor-spec/tearing-down-circuits.md
+++ b/spec/tor-spec/tearing-down-circuits.md
@@ -1,4 +1,5 @@
 <a id="tor-spec.txt-5.4"></a>
+
 ## Tearing down circuits
 
 Circuits are torn down when an unrecoverable error occurs along
@@ -104,4 +105,3 @@ The error codes are:
     11 -- DESTROYED       (The circuit was destroyed w/o client TRUNCATE)
     12 -- NOSUCHSERVICE   (Request for unknown hidden service)
 ```
-