Run mdformat on the spec files.

2 files changed, 15 insertions, 15 deletions

diff --git a/spec/padding-spec/circuit-level-padding.md b/spec/padding-spec/circuit-level-padding.md
index 575f248..a220507 100644
--- a/spec/padding-spec/circuit-level-padding.md
+++ b/spec/padding-spec/circuit-level-padding.md
@@ -3,13 +3,13 @@
 # Circuit-level padding
 
 The circuit padding system in Tor is an extension of the WTF-PAD
-event-driven state machine design[15]. At a high level, this design places
+event-driven state machine design\[15\]. At a high level, this design places
 one or more padding state machines at the client, and one or more padding
 state machines at a relay, on each circuit.
 
 State transition and histogram generation has been generalized to be fully
 programmable, and probability distribution support was added to support more
-compact representations like APE[16]. Additionally, packet count limits,
+compact representations like APE\[16\]. Additionally, packet count limits,
 rate limiting, and circuit application conditions have been added.
 
 At present, Tor uses this system to deploy two pairs of circuit padding
@@ -19,7 +19,7 @@ onion service circuits, up to the first 10 cells.
 This specification covers only the resulting behavior of these padding
 machines, and thus does not cover the state machine implementation details or
 operation. For full details on using the circuit padding system to develop
-future padding defenses, see the research developer documentation[17].
+future padding defenses, see the research developer documentation\[17\].
 
 <a id="padding-spec.txt-3.1"></a>
 
@@ -133,16 +133,16 @@ Note that inter-arrival timing is not obfuscated by this defense.
 
 Most general Tor circuits used to surf the web or download directory
 information start with the following 6-cell relay cell sequence (cells
-surrounded in [brackets] are outgoing, the others are incoming):
+surrounded in \[brackets\] are outgoing, the others are incoming):
 
-[EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 -> [BEGIN] -> CONNECTED
+\[EXTEND2\] -> EXTENDED2 -> \[EXTEND2\] -> EXTENDED2 -> \[BEGIN\] -> CONNECTED
 
 When this is done, the client has established a 3-hop circuit and also opened
 a stream to the other end. Usually after this comes a series of DATA cell that
 either fetches pages, establishes an SSL connection or fetches directory
 information:
 
-[DATA] -> [DATA] -> DATA -> DATA...(inbound cells continue)
+\[DATA\] -> \[DATA\] -> DATA -> DATA...(inbound cells continue)
 
 The above stream of 10 relay cells defines the grand majority of general
 circuits that come out of Tor browser during our testing, and it's what we use
@@ -165,7 +165,7 @@ machine terminates at the second hop and does not get forwarded to the actual
 introduction point.
 
 From Section 3.3.1 above, most general circuits have the following initial
-relay cell sequence (outgoing cells marked in [brackets]):
+relay cell sequence (outgoing cells marked in \[brackets\]):
 
 ```text
   [EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 -> [BEGIN] -> CONNECTED
@@ -181,12 +181,12 @@ This means that up to the sixth cell (first line of each sequence above),
 both general and intro circuits have identical cell sequences. After that
 we want to mimic the second line sequence of
 
--> [DATA] -> [DATA] -> DATA -> DATA...(inbound data cells continue)
+-> \[DATA\] -> \[DATA\] -> DATA -> DATA...(inbound data cells continue)
 
 We achieve this by starting padding INTRODUCE1 has been sent. With padding
 negotiation cells, in the common case of the second line looks like:
 
--> [INTRO1] -> [PADDING_NEGOTIATE] -> PADDING_NEGOTIATED -> INTRO_ACK
+-> \[INTRO1\] -> \[PADDING_NEGOTIATE\] -> PADDING_NEGOTIATED -> INTRO_ACK
 
 Then, the middle node will send between INTRO_MACHINE_MINIMUM_PADDING (7) and
 INTRO_MACHINE_MAXIMUM_PADDING (10) cells, to match the "...(inbound data cells
@@ -218,7 +218,7 @@ circuits which usually look like this:
 This means that up to the sixth cell (the first line), both general and
 rend circuits have identical cell sequences.
 
-After that we want to mimic a [DATA] -> [DATA] -> DATA -> DATA sequence.
+After that we want to mimic a \[DATA\] -> \[DATA\] -> DATA -> DATA sequence.
 
 With padding negotiation right after the REND_ESTABLISHED, the sequence
 becomes:
@@ -243,7 +243,7 @@ will look alike.
 ### Circuit setup machine overhead
 
 For the intro circuit case, we see that the origin-side machine just sends a
-single [PADDING_NEGOTIATE] cell, whereas the origin-side machine sends a
+single \[PADDING_NEGOTIATE\] cell, whereas the origin-side machine sends a
 PADDING_NEGOTIATED cell and between 7 to 10 DROP cells. This means that the
 average overhead of this machine is 11 padding cells per introduction circuit.
 
diff --git a/spec/padding-spec/connection-level-padding.md b/spec/padding-spec/connection-level-padding.md
index b0450d7..5c01f38 100644
--- a/spec/padding-spec/connection-level-padding.md
+++ b/spec/padding-spec/connection-level-padding.md
@@ -13,7 +13,7 @@ Such metadata retention is implemented by Internet routers in the form of
 Netflow, jFlow, Netstream, or IPFIX records.  These records are emitted by
 gateway routers in a raw form and then exported (often over plaintext) to a
 "collector" that either records them verbatim, or reduces their granularity
-further[1].
+further\[1\].
 
 Netflow records and the associated data collection and retention tools are
 very configurable, and have many modes of operation, especially when
@@ -147,7 +147,7 @@ bidirectional padding packet rate is now a third random variable:
 Z = min(Y,Y).
 
 The distribution of Z is slightly bell-shaped, but mostly flat around the
-mean. It also turns out that Exp[Z] ~= Exp[X]. Here's a table of average
+mean. It also turns out that Exp\[Z\] ~= Exp\[X\]. Here's a table of average
 values for each random variable:
 
 ```text
@@ -178,7 +178,7 @@ in each direction (309KB total).
 
 With 2.5M completely idle clients connected simultaneously, 52 bytes per
 second amounts to 130MB/second in each direction network-wide, which is
-roughly the current amount of Tor directory traffic[11]. Of course, our
+roughly the current amount of Tor directory traffic\[11\]. Of course, our
 2.5M daily users will neither be connected simultaneously, nor entirely
 idle, so we expect the actual overhead to be much lower than this.
 
@@ -192,7 +192,7 @@ clients to relays. This cell is used to instruct relays to cease sending
 padding.
 
 If the client has opted to use reduced padding, it continues to send
-padding cells sampled from the range [9000,14000] milliseconds (subject to
+padding cells sampled from the range \[9000,14000\] milliseconds (subject to
 consensus parameter alteration as per Section 2.6), still using the
 Y=max(X,X) distribution. Since the padding is now unidirectional, the
 expected frequency of padding cells is now governed by the Y distribution