12 files changed, 46 insertions, 49 deletions
diff --git a/spec/tor-spec/closing-streams.md b/spec/tor-spec/closing-streams.md
index 9ef1b98..5fa84a8 100644
--- a/spec/tor-spec/closing-streams.md
+++ b/spec/tor-spec/closing-streams.md
@@ -42,7 +42,7 @@ versions of Tor may provide more fine-grained reasons.
 
 For most reasons, the format of RELAY_END is:
 
-Reason                      [1 byte]
+Reason                      \[1 byte\]
 
 For REASON_EXITPOLICY, the format of RELAY_END is:
 
@@ -72,7 +72,7 @@ how many cells of which types (CONNECTED, SENDME, DATA) that it would have
 accepted on that stream, and SHOULD kill the circuit if it receives more
 than permitted.
 
---- [The rest of this section describes unimplemented functionality.]
+--- \[The rest of this section describes unimplemented functionality.\]
 
 Because TCP connections can be half-open, we follow an equivalent
 to TCP's FIN/FIN-ACK/ACK protocol to close streams.
diff --git a/spec/tor-spec/connections.md b/spec/tor-spec/connections.md
index a7ba661..9495fe4 100644
--- a/spec/tor-spec/connections.md
+++ b/spec/tor-spec/connections.md
@@ -133,8 +133,8 @@ malformed or missing certificates.  (However, an OR should not believe
 that an incoming connection is from another OR unless the certificates
 are present and well-formed.)
 
-[Before version 0.1.2.8-rc, ORs rejected incoming connections from ORs and
-OPs alike if their certificates were missing or malformed.]
+\[Before version 0.1.2.8-rc, ORs rejected incoming connections from ORs and
+OPs alike if their certificates were missing or malformed.\]
 
 Once a TLS connection is established, the two sides send cells
 (specified below) to one another.  Cells are sent serially.  Standard
diff --git a/spec/tor-spec/create-created-cells.md b/spec/tor-spec/create-created-cells.md
index 56134e4..4574f03 100644
--- a/spec/tor-spec/create-created-cells.md
+++ b/spec/tor-spec/create-created-cells.md
@@ -52,7 +52,7 @@ ntor -- 'ntorNTORntorNTOR'
 
 The format of a CREATED cell is:
 
-HDATA     (Server Handshake Data)     [TAP_S_HANDSHAKE_LEN bytes]
+HDATA     (Server Handshake Data)     \[TAP_S_HANDSHAKE_LEN bytes\]
 
 (It's equivalent to a CREATED2 cell with length of TAP_S_HANDSHAKE_LEN.)
 
@@ -67,7 +67,7 @@ Servers always reply to a successful CREATE with a CREATED, and to a
 successful CREATE2 with a CREATED2.  On failure, a server sends a
 DESTROY cell to tear down the circuit.
 
-[CREATE2 is handled by Tor 0.2.4.7-alpha and later.]
+\[CREATE2 is handled by Tor 0.2.4.7-alpha and later.\]
 
 <a id="tor-spec.txt-5.1.1"></a>
 
@@ -144,8 +144,8 @@ instances of specifiers other than 'legacy identity' and
 that include multiple instances of either one of those specifiers.)
 
 For purposes of indistinguishability, implementations SHOULD send
-these link specifiers, if using them, in this order: [00], [02], [03],
-[01].
+these link specifiers, if using them, in this order: \[00\], \[02\], \[03\],
+\[01\].
 
 The relay payload for an EXTEND relay cell consists of:
 
@@ -190,7 +190,7 @@ CREATED cell.
 The payload of an EXTENDED2 cell is the same as the payload of a
 CREATED2 cell.
 
-[Support for EXTEND2/EXTENDED2 was added in Tor 0.2.4.8-alpha.]
+\[Support for EXTEND2/EXTENDED2 was added in Tor 0.2.4.8-alpha.\]
 
 Clients SHOULD use the EXTEND format whenever sending a TAP
 handshake, and MUST use it whenever the EXTEND cell will be handled
@@ -269,7 +269,7 @@ original handshake (or with nobody at all).  Here we use the
 "curve25519" group and representation as specified in "Curve25519:
 new Diffie-Hellman speed records" by D. J. Bernstein.
 
-[The ntor handshake was added in Tor 0.2.4.8-alpha.]
+\[The ntor handshake was added in Tor 0.2.4.8-alpha.\]
 
 In this section, define:
 
@@ -330,8 +330,8 @@ private key 'b' to compute:
 ```
 
 Both parties check that none of the EXP() operations produced the
-point at infinity. [NOTE: This is an adequate replacement for
-checking Y for group membership, if the group is curve25519.]
+point at infinity. \[NOTE: This is an adequate replacement for
+checking Y for group membership, if the group is curve25519.\]
 
 Both parties now have a shared value for KEY_SEED.  They expand this
 into the keys needed for the Tor relay protocol, using the KDF
@@ -507,7 +507,7 @@ created.
 
 A CREATE_FAST cell contains:
 
-Key material (X)    [HASH_LEN bytes]
+Key material (X)    \[HASH_LEN bytes\]
 
 A CREATED_FAST cell contains:
 
@@ -525,7 +525,7 @@ The CREATE_FAST handshake is currently deprecated whenever it is not
 necessary; the migration is controlled by the "usecreatefast"
 networkstatus parameter as described in dir-spec.txt.
 
-[Tor 0.3.1.1-alpha and later disable CREATE_FAST by default.]
+\[Tor 0.3.1.1-alpha and later disable CREATE_FAST by default.\]
 
 <a id="tor-spec.txt-5.1.6"></a>
 
diff --git a/spec/tor-spec/flow-control.md b/spec/tor-spec/flow-control.md
index 960bd21..e007529 100644
--- a/spec/tor-spec/flow-control.md
+++ b/spec/tor-spec/flow-control.md
@@ -146,7 +146,7 @@ DATA_LEN and how to handle it. The recognized values are:
 
 0x01: Authenticated SENDME. The DATA section MUST contain:
 
-DIGEST   [20 bytes]
+DIGEST   \[20 bytes\]
 
 ```text
          If the DATA_LEN value is less than 20 bytes, the cell should be
@@ -176,7 +176,7 @@ control for individual connections across circuits. Similarly to
 circuit-level flow control, edge nodes begin with a window of cells
 (500) per stream, and increment the window by a fixed value (50)
 upon receiving a RELAY_SENDME cell. Edge nodes initiate RELAY_SENDME
-cells when both a) the window is <= 450, and b) there are less than
+cells when both a) the window is \<= 450, and b) there are less than
 ten cell payloads remaining to be flushed at that edge.
 
 Stream-level RELAY_SENDME cells are distinguished by having nonzero
diff --git a/spec/tor-spec/handling-relay_early-cells.md b/spec/tor-spec/handling-relay_early-cells.md
index 9adbced..2517dcc 100644
--- a/spec/tor-spec/handling-relay_early-cells.md
+++ b/spec/tor-spec/handling-relay_early-cells.md
@@ -16,5 +16,5 @@ EXTEND/EXTEND2 cells inside RELAY_EARLY cells.  Clients SHOULD send the first
 ~8 RELAY cells that are not targeted at the first hop of any circuit as
 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.]
+\[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/negotiating-initializing-connections.md b/spec/tor-spec/negotiating-initializing-connections.md
index dd9be1d..2b8ebd6 100644
--- a/spec/tor-spec/negotiating-initializing-connections.md
+++ b/spec/tor-spec/negotiating-initializing-connections.md
@@ -31,9 +31,9 @@ those specified, except for VPADDING cells.
 The AUTHORIZE cell type is reserved for future use by scanning-resistance
 designs.
 
-[Tor versions before 0.2.3.11-alpha did not recognize the AUTHORIZE cell,
+\[Tor versions before 0.2.3.11-alpha did not recognize the AUTHORIZE cell,
 and did not permit any command other than VERSIONS as the first cell of
-the in-protocol handshake.]
+the in-protocol handshake.\]
 
 <a id="tor-spec.txt-4.1"></a>
 
diff --git a/spec/tor-spec/opening-streams-transferring-data.md b/spec/tor-spec/opening-streams-transferring-data.md
index 8300ace..956e2c8 100644
--- a/spec/tor-spec/opening-streams-transferring-data.md
+++ b/spec/tor-spec/opening-streams-transferring-data.md
@@ -60,10 +60,10 @@ payload is in one of the following formats:
        A number of seconds (TTL) for which the address may be cached [4 octets]
 ```
 
-[Tor exit nodes before 0.1.2.0 set the TTL field to a fixed value.  Later
+\[Tor exit nodes before 0.1.2.0 set the TTL field to a fixed value.  Later
 versions set the TTL to the last value seen from a DNS server, and expire
 their own cached entries after a fixed interval.  This prevents certain
-attacks.]
+attacks.\]
 
 Once a connection has been established, the OP and exit node
 package stream data in RELAY_DATA cells, and upon receiving such
@@ -99,10 +99,10 @@ 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),
-* onion service directories (RELAY_BEGIN_DIR, anonymous).
+- authoritative directories (RELAY_BEGIN_DIR, usually non-anonymous),
+- bridge authoritative directories (RELAY_BEGIN_DIR, anonymous),
+- directory mirrors (RELAY_BEGIN_DIR, usually non-anonymous),
+- onion service directories (RELAY_BEGIN_DIR, anonymous).
 
 If the Tor relay is not running a directory service, it should respond
 with a REASON_NOTDIRECTORY RELAY_END cell.
@@ -115,5 +115,5 @@ RELAY_CONNECTED cell on success, or a RELAY_END cell on failure. They
 MUST send a RELAY_CONNECTED cell all-zero payload, and clients MUST ignore
 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.]
+\[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 c97e774..7967fcd 100644
--- a/spec/tor-spec/preliminaries.md
+++ b/spec/tor-spec/preliminaries.md
@@ -23,7 +23,7 @@
    a|b -- concatenation of 'a' and 'b'.
 ```
 
-[A0 B1 C2] -- a three-byte sequence, containing the bytes with
+\[A0 B1 C2\] -- a three-byte sequence, containing the bytes with
 hexadecimal values A0, B1, and C2, in that order.
 
 H(m) -- a cryptographic hash of m.
@@ -104,10 +104,10 @@ rfc2409 section 6.2 whose hex representation is:
 As an optimization, implementations SHOULD choose DH private keys (x) of
 320 bits.  Implementations that do this MUST never use any DH key more
 than once.
-[May other implementations reuse their DH keys?? -RD]
-[Probably not. Conceivably, you could get away with changing DH keys once
+\[May other implementations reuse their DH keys?? -RD\]
+\[Probably not. Conceivably, you could get away with changing DH keys once
 per second, but there are too many oddball attacks for me to be
-comfortable that this is safe. -NM]
+comfortable that this is safe. -NM\]
 
 For a hash function, unless otherwise specified, we use SHA-1.
 
diff --git a/spec/tor-spec/relay-cells.md b/spec/tor-spec/relay-cells.md
index 68e0391..364d2d2 100644
--- a/spec/tor-spec/relay-cells.md
+++ b/spec/tor-spec/relay-cells.md
@@ -9,9 +9,9 @@ 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).
+- exit relays (RELAY_BEGIN, anonymous),
+- directory servers (RELAY_BEGIN_DIR, anonymous or non-anonymous),
+- onion services (RELAY_BEGIN, anonymous via a rendezvous point).
 
 The payload of each unencrypted RELAY cell consists of:
 
@@ -91,7 +91,7 @@ All RELAY cells pertaining to the same tunneled stream have the same
 stream ID.  StreamIDs are chosen arbitrarily by the OP.  No stream
 may have a StreamID of zero. Rather, RELAY cells that affect the
 entire circuit rather than a particular stream use a StreamID of zero
--- they are marked in the table above as "[control]" style
+-- they are marked in the table above as "\[control\]" style
 cells. (Sendme cells are marked as "sometimes control" because they
 can include a StreamID or not depending on their purpose -- see
 Section 7.)
diff --git a/spec/tor-spec/setting-circuit-keys.md b/spec/tor-spec/setting-circuit-keys.md
index b49f75d..f299f81 100644
--- a/spec/tor-spec/setting-circuit-keys.md
+++ b/spec/tor-spec/setting-circuit-keys.md
@@ -20,7 +20,7 @@ K0=X|Y.
 From the base key material K0, they compute KEY_LEN*2+HASH_LEN*3 bytes of
 derivative key data as
 
-K = H(K0 | [00]) | H(K0 | [01]) | H(K0 | [02]) | ...
+K = H(K0 | \[00\]) | H(K0 | \[01\]) | H(K0 | \[02\]) | ...
 
 The first HASH_LEN bytes of K form KH; the next HASH_LEN form the forward
 digest Df; the next HASH_LEN 41-60 form the backward digest Db; the next
diff --git a/spec/tor-spec/system-overview.md b/spec/tor-spec/system-overview.md
index 8577928..f05b893 100644
--- a/spec/tor-spec/system-overview.md
+++ b/spec/tor-spec/system-overview.md
@@ -5,10 +5,7 @@
 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'')
-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
+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>
@@ -60,7 +57,7 @@ These are 1024-bit RSA keys:
       KP_link_ed, KS_link_ed.
 ```
 
-KP_relayid_* together identify a router uniquely.  Once a router
+KP_relayid\_\* together identify a router uniquely.  Once a router
 has used a KP_relayid_ed (an Ed25519 master identity key)
 together with a given KP_relayid_rsa (RSA identity key), neither of
 those keys may ever be used with a different key.
diff --git a/spec/tor-spec/tearing-down-circuits.md b/spec/tor-spec/tearing-down-circuits.md
index 3008c05..f06b231 100644
--- a/spec/tor-spec/tearing-down-circuits.md
+++ b/spec/tor-spec/tearing-down-circuits.md
@@ -8,10 +8,10 @@ circuit's intended lifetime is over.
 
 ORs SHOULD also tear down circuits which attempt to create:
 
-* streams with RELAY_BEGIN, or
-* rendezvous points with ESTABLISH_RENDEZVOUS,
-ending at the first hop. Letting Tor be used as a single hop proxy makes
-exit and rendezvous nodes a more attractive target for compromise.
+- streams with RELAY_BEGIN, or
+- rendezvous points with ESTABLISH_RENDEZVOUS,
+  ending at the first hop. Letting Tor be used as a single hop proxy makes
+  exit and rendezvous nodes a more attractive target for compromise.
 
 ORs MAY use multiple methods to check if they are the first hop:
 
@@ -45,13 +45,13 @@ signaling a given OR (Stream ID zero).  That OR sends a DESTROY
 cell to the next node in the circuit, and replies to the OP with a
 RELAY_TRUNCATED cell.
 
-[Note: If an OR receives a TRUNCATE cell and it has any RELAY cells
+\[Note: If an OR receives a TRUNCATE cell and it has any RELAY cells
 still queued on the circuit for the next node it will drop them
 without sending them.  This is not considered conformant behavior,
 but it probably won't get fixed until a later version of Tor.  Thus,
 clients SHOULD NOT send a TRUNCATE cell to a node running any current
 version of Tor if a) they have sent relay cells through that node,
-and b) they aren't sure whether those cells have been sent on yet.]
+and b) they aren't sure whether those cells have been sent on yet.\]
 
 ```text
    When an unrecoverable error occurs along one a circuit, the nodes
@@ -79,7 +79,7 @@ towards the client, not RELAY_TRUNCATED.
 
 The payload of a DESTROY and RELAY_TRUNCATED cell contains a single
 octet, describing the reason that the circuit was
-closed. RELAY_TRUNCATED cells, and DESTROY cells sent _towards the
+closed. RELAY_TRUNCATED cells, and DESTROY cells sent \_towards the
 client, should contain the actual reason from the list of error codes
 below.  Reasons in DESTROY cell SHOULD NOT be propagated downward or
 upward, due to potential side channel risk: An OR receiving a DESTROY