1 files changed, 12 insertions, 12 deletions
diff --git a/spec/rend-spec-v3/protocol-overview.md b/spec/rend-spec-v3/protocol-overview.md
index 1c03e49..173240e 100644
--- a/spec/rend-spec-v3/protocol-overview.md
+++ b/spec/rend-spec-v3/protocol-overview.md
@@ -47,7 +47,7 @@ communicate data on those streams, and so forth.
 
 <a id="rend-spec-v3.txt-1.2"></a>
 
-## In more detail: naming hidden services [NAMING]
+## In more detail: naming hidden services \[NAMING\]
 
 A hidden service's name is its long term master identity key.  This is
 encoded as a hostname by encoding the entire key in Base 32, including a
@@ -73,7 +73,7 @@ their length. An older name might look like:
 
 <a id="rend-spec-v3.txt-1.3"></a>
 
-## In more detail: Access control [IMD:AC]
+## In more detail: Access control \[IMD:AC\]
 
 Access control for a hidden service is imposed at multiple points through
 the process above. Furthermore, there is also the option to impose
@@ -108,7 +108,7 @@ require the client to prove knowledge of a pre-shared private key.
 
 <a id="rend-spec-v3.txt-1.4"></a>
 
-## In more detail: Distributing hidden service descriptors. [IMD:DIST]
+## In more detail: Distributing hidden service descriptors. \[IMD:DIST\]
 
 Periodically, hidden service descriptors become stored at different
 locations to prevent a single directory or small set of directories
@@ -118,14 +118,14 @@ For each period, the Tor directory authorities agree upon a
 collaboratively generated random value. (See section 2.3 for a
 description of how to incorporate this value into the voting
 practice; generating the value is described in other proposals,
-including [SHAREDRANDOM-REFS].) That value, combined with hidden service
+including \[SHAREDRANDOM-REFS\].) That value, combined with hidden service
 directories' public identity keys, determines each HSDir's position
 in the hash ring for descriptors made in that period.
 
 Each hidden service's descriptors are placed into the ring in
 positions based on the key that was used to sign them. Note that
 hidden service descriptors are not signed with the services' public
-keys directly. Instead, we use a key-blinding system [KEYBLIND] to
+keys directly. Instead, we use a key-blinding system \[KEYBLIND\] to
 create a new key-of-the-day for each hidden service. Any client that
 knows the hidden service's public identity key can derive these blinded
 signing keys for a given period. It should be impossible to derive
@@ -159,7 +159,7 @@ This design is compatible with our current approaches for scaling hidden
 services. Specifically, hidden service operators can use onionbalance to
 achieve high availability between multiple nodes on the HSDir
 layer. Furthermore, operators can use proposal 255 to load balance their
-hidden services on the introduction layer. See [SCALING-REFS] for further
+hidden services on the introduction layer. See \[SCALING-REFS\] for further
 discussions on this topic and alternative designs.
 
 ```text
@@ -183,7 +183,7 @@ which are used to sign descriptor signing keys.
 
 In order to operate a hidden service, the operator can generate in
 advance a number of blinded signing keys and descriptor signing
-keys (and their credentials; see [DESC-OUTER] and [HS-DESC-ENC]
+keys (and their credentials; see \[DESC-OUTER\] and \[HS-DESC-ENC\]
 below), and their corresponding descriptor encryption keys, and
 export those to the hidden service hosts.
 
@@ -215,9 +215,9 @@ discussion.)
 
 ## In more detail: A menagerie of keys
 
-[In the text below, an "encryption keypair" is roughly "a keypair you
+\[In the text below, an "encryption keypair" is roughly "a keypair you
 can do Diffie-Hellman with" and a "signing keypair" is roughly "a
-keypair you can do ECDSA with."]
+keypair you can do ECDSA with."\]
 
 Public/private keypairs defined in this document:
 
@@ -292,7 +292,7 @@ Public/private keypairs defined in this document:
 
 <a id="rend-spec-v3.txt-1.9.1"></a>
 
-### In even more detail: Client authorization keys [CLIENT-AUTH]
+### In even more detail: Client authorization keys \[CLIENT-AUTH\]
 
 When client authorization is enabled, each authorized client of a hidden
 service has two more asymmetric keypairs which are shared with the hidden
@@ -320,9 +320,9 @@ The right way to exchange these keys is to have the client generate keys and
 send the corresponding public keys to the hidden service out-of-band. An
 easier but less secure way of doing this exchange would be to have the
 hidden service generate the keypairs and pass the corresponding private keys
-to its clients. See section [CLIENT-AUTH-MGMT] for more details on how these
+to its clients. See section \[CLIENT-AUTH-MGMT\] for more details on how these
 keys should be managed.
 
-[TODO: Also specify stealth client authorization.]
+\[TODO: Also specify stealth client authorization.\]
 
 (NOTE: client authorization is implemented as of 0.3.5.1-alpha.)