4 files changed, 18 insertions, 4 deletions
diff --git a/spec/padding-spec/acknowledgments.md b/spec/padding-spec/acknowledgments.md
index 7213127..5a594da 100644
--- a/spec/padding-spec/acknowledgments.md
+++ b/spec/padding-spec/acknowledgments.md
@@ -1,4 +1,5 @@
 <a id="padding-spec.txt-A"></a>
+
 # Acknowledgments
 
 This research was supported in part by NSF grants CNS-1111539,
@@ -25,4 +26,3 @@ CNS-1314637, CNS-1526306, CNS-1619454, and CNS-1640548.
 18. https://www.usenix.org/node/190967
     https://blog.torproject.org/technical-summary-usenix-fingerprinting-paper
 ```
-
diff --git a/spec/padding-spec/circuit-level-padding.md b/spec/padding-spec/circuit-level-padding.md
index 5f821ca..575f248 100644
--- a/spec/padding-spec/circuit-level-padding.md
+++ b/spec/padding-spec/circuit-level-padding.md
@@ -1,4 +1,5 @@
 <a id="padding-spec.txt-3"></a>
+
 # Circuit-level padding
 
 The circuit padding system in Tor is an extension of the WTF-PAD
@@ -21,6 +22,7 @@ operation. For full details on using the circuit padding system to develop
 future padding defenses, see the research developer documentation[17].
 
 <a id="padding-spec.txt-3.1"></a>
+
 ## Circuit Padding Negotiation
 
 Circuit padding machines are advertised as "Padding" subprotocol versions
@@ -93,6 +95,7 @@ If the machine_ctr does not match the current machine instance count
 on the circuit, the command is ignored.
 
 <a id="padding-spec.txt-3.2"></a>
+
 ## Circuit Padding Machine Message Management
 
 Clients MAY send padding cells towards the relay before receiving the
@@ -108,6 +111,7 @@ from unexpected relay sources are protocol violations, and clients MAY
 immediately tear down such circuits to avoid side channel risk.
 
 <a id="padding-spec.txt-3.3"></a>
+
 ## Obfuscating client-side onion service circuit setup
 
 The circuit padding currently deployed in Tor attempts to hide client-side
@@ -124,6 +128,7 @@ of general circuits.
 Note that inter-arrival timing is not obfuscated by this defense.
 
 <a id="padding-spec.txt-3.3.1"></a>
+
 ### Common general circuit construction sequences
 
 Most general Tor circuits used to surf the web or download directory
@@ -150,6 +155,7 @@ depend on the type of guard used and are not an effective fingerprint for a
 network/guard-level adversary.
 
 <a id="padding-spec.txt-3.3.2"></a>
+
 ### Client-side onion service introduction circuit obfuscation
 
 Two circuit padding machines work to hide client-side introduction circuits:
@@ -192,6 +198,7 @@ the same duration as normal web circuits before they expire (usually 10
 minutes).
 
 <a id="padding-spec.txt-3.3.3"></a>
+
 ### Client-side rendezvous circuit hiding
 
 Following a similar argument as for intro circuits, we are aiming for padded
@@ -232,6 +239,7 @@ general circuits (their purpose is to surf the web), we can expect that they
 will look alike.
 
 <a id="padding-spec.txt-3.3.4"></a>
+
 ### Circuit setup machine overhead
 
 For the intro circuit case, we see that the origin-side machine just sends a
@@ -243,6 +251,7 @@ For the rend circuit case, this machine is quite light. Both sides send 2
 padding cells, for a total of 4 padding cells.
 
 <a id="padding-spec.txt-3.4"></a>
+
 ## Circuit padding consensus parameters
 
 The circuit padding system has a handful of consensus parameters that can
@@ -278,4 +287,3 @@ at relays and clients.
       before padding stops being sent on that circuit.
     - Default: CIRCWINDOW_START_MAX (1000)
 ```
-
diff --git a/spec/padding-spec/connection-level-padding.md b/spec/padding-spec/connection-level-padding.md
index 3bb7f12..b0450d7 100644
--- a/spec/padding-spec/connection-level-padding.md
+++ b/spec/padding-spec/connection-level-padding.md
@@ -1,7 +1,9 @@
 <a id="padding-spec.txt-2"></a>
+
 # Connection-level padding
 
 <a id="padding-spec.txt-2.1"></a>
+
 ## Background
 
 Tor clients and relays make use of CELL_PADDING to reduce the resolution of
@@ -87,6 +89,7 @@ measurement is unidirectional, and so traffic must be sent by both parties
 in order to prevent record splitting.
 
 <a id="padding-spec.txt-2.2"></a>
+
 ## Implementation
 
 Tor clients currently maintain one TLS connection to their Guard node to
@@ -129,6 +132,7 @@ queue that they practically can, and if this queue is already nonempty,
 padding should not be scheduled until after the queue does become empty.)
 
 <a id="padding-spec.txt-2.3"></a>
+
 ## Padding Cell Timeout Distribution Statistics
 
 To limit the amount of padding sent, instead of sampling each endpoint
@@ -160,6 +164,7 @@ values for each random variable:
 ```
 
 <a id="padding-spec.txt-2.4"></a>
+
 ## Maximum overhead bounds
 
 With the default parameters and the above distribution, we expect a
@@ -178,6 +183,7 @@ roughly the current amount of Tor directory traffic[11]. Of course, our
 idle, so we expect the actual overhead to be much lower than this.
 
 <a id="padding-spec.txt-2.5"></a>
+
 ## Reducing or Disabling Padding via Negotiation
 
 To allow mobile clients to either disable or reduce their padding overhead,
@@ -222,6 +228,7 @@ Clients and bridges MUST reject padding negotiation messages from relays,
 and close the channel if they receive one.
 
 <a id="padding-spec.txt-2.6"></a>
+
 ## Consensus Parameters Governing Behavior
 
 Connection-level padding is controlled by the following consensus parameters:
@@ -280,4 +287,3 @@ Connection-level padding is controlled by the following consensus parameters:
         open.
       - Default: 3600
 ```
-
diff --git a/spec/padding-spec/overview.md b/spec/padding-spec/overview.md
index 76c8865..0abe739 100644
--- a/spec/padding-spec/overview.md
+++ b/spec/padding-spec/overview.md
@@ -1,4 +1,5 @@
 <a id="padding-spec.txt-1"></a>
+
 # Overview
 
 Tor supports two classes of cover traffic: connection-level padding, and
@@ -25,4 +26,3 @@ connection-level padding. The connection-level padding system regards
 circuit-level padding as normal data traffic, and hence the connection-level
 padding system will not add any additional overhead while the circuit-level
 padding system is actively padding.
-