1 files changed, 24 insertions, 24 deletions
diff --git a/spec/rend-spec-v3/deriving-blinded-keys-subcredentials-subcred.md b/spec/rend-spec-v3/deriving-blinded-keys-subcredentials-subcred.md
index 2a1cb72..201fc92 100644
--- a/spec/rend-spec-v3/deriving-blinded-keys-subcredentials-subcred.md
+++ b/spec/rend-spec-v3/deriving-blinded-keys-subcredentials-subcred.md
@@ -1,13 +1,13 @@
 <a id="rend-spec-v3.txt-2.1"></a>
 
-## Deriving blinded keys and subcredentials [SUBCRED]
+## Deriving blinded keys and subcredentials \[SUBCRED\]
 
-In each time period (see [TIME-PERIODS] for a definition of time
+In each time period (see \[TIME-PERIODS\] for a definition of time
 periods), a hidden service host uses a different blinded private key
 to sign its directory information, and clients use a different
 blinded public key as the index for fetching that information.
 
-For a candidate for a key derivation method, see Appendix [KEYBLIND].
+For a candidate for a key derivation method, see Appendix \[KEYBLIND\].
 
 Additionally, clients and hosts derive a subcredential for each
 period. Knowledge of the subcredential is needed to decrypt hidden
@@ -58,7 +58,7 @@ Which Tor servers hosts a hidden service depends on:
 
 <a id="rend-spec-v3.txt-2.2.1"></a>
 
-### Dividing time into periods [TIME-PERIODS]
+### Dividing time into periods \[TIME-PERIODS\]
 
 To prevent a single set of hidden service directory from becoming a
 target by adversaries looking to permanently censor a hidden service,
@@ -79,7 +79,7 @@ dividing by the time period (effectively making "our" epoch start at Jan
 
 Example: If the current time is 2016-04-13 11:15:01 UTC, making the seconds
 since the epoch 1460546101, and the number of minutes since the epoch
-24342435.  We then subtract the "rotation time offset" of 12*60 minutes from
+24342435\.  We then subtract the "rotation time offset" of 12\*60 minutes from
 the minutes since the epoch, to get 24341715. If the current time period
 length is 1440 minutes, by doing the division we see that we are currently
 in time period number 16903.
@@ -90,17 +90,17 @@ after the epoch, at 2016-04-12 12:00 UTC, and ended at 16904*1440*60 +
 
 <a id="rend-spec-v3.txt-2.2.2"></a>
 
-### When to publish a hidden service descriptor [WHEN-HSDESC]
+### When to publish a hidden service descriptor \[WHEN-HSDESC\]
 
 Hidden services periodically publish their descriptor to the responsible
 HSDirs. The set of responsible HSDirs is determined as specified in
-[WHERE-HSDESC].
+\[WHERE-HSDESC\].
 
 Specifically, every time a hidden service publishes its descriptor, it also
 sets up a timer for a random time between 60 minutes and 120 minutes in the
 future. When the timer triggers, the hidden service needs to publish its
 descriptor again to the responsible HSDirs for that time period.
-[TODO: Control republish period using a consensus parameter?]
+\[TODO: Control republish period using a consensus parameter?\]
 
 <a id="rend-spec-v3.txt-2.2.2.1"></a>
 
@@ -118,14 +118,14 @@ Hence, services maintain two active descriptors at every point. Clients on
 the other hand, don't have a notion of overlapping descriptors, and instead
 always download the descriptor for the current time period and shared random
 value. It's the job of the service to ensure that descriptors will be
-available for all clients. See section [FETCHUPLOADDESC] for how this is
+available for all clients. See section \[FETCHUPLOADDESC\] for how this is
 achieved.
 
-[TODO: What to do when we run multiple hidden services in a single host?]
+\[TODO: What to do when we run multiple hidden services in a single host?\]
 
 <a id="rend-spec-v3.txt-2.2.3"></a>
 
-### Where to publish a hidden service descriptor [WHERE-HSDESC]
+### Where to publish a hidden service descriptor \[WHERE-HSDESC\]
 
 This section specifies how the HSDir hash ring is formed at any given
 time. Whenever a time value is needed (e.g. to get the current time period
@@ -155,10 +155,10 @@ derived, the uploading or downloading party calculates:
                                      INT_8(period_num) )
 ```
 
-where blinded_public_key is specified in section [KEYBLIND], period_length
+where blinded_public_key is specified in section \[KEYBLIND\], period_length
 is the length of the time period in minutes, and period_num is calculated
 using the current consensus "valid-after" as specified in section
-[TIME-PERIODS].
+\[TIME-PERIODS\].
 
 Then, for each node listed in the current consensus with the HSDir flag,
 we compute a directory index for that node as:
@@ -171,7 +171,7 @@ we compute a directory index for that node as:
 ```
 
 where shared_random_value is the shared value generated by the authorities
-in section [PUB-SHAREDRANDOM], and node_identity is the ed25519 identity
+in section \[PUB-SHAREDRANDOM\], and node_identity is the ed25519 identity
 key of the node.
 
 Finally, for replicanum in 1...hsdir_n_replicas, the hidden service
@@ -190,7 +190,7 @@ choosing the spread for a replica.
 
 <a id="rend-spec-v3.txt-2.2.4"></a>
 
-### Using time periods and SRVs to fetch/upload HS descriptors [FETCHUPLOADDESC]
+### Using time periods and SRVs to fetch/upload HS descriptors \[FETCHUPLOADDESC\]
 
 Hidden services and clients need to make correct use of time periods (TP)
 and shared random values (SRVs) to successfully fetch and upload
@@ -202,7 +202,7 @@ of clients and services due to system clock. Whenever time-based decisions
 are taken in this section, assume that they are consensus times and not
 system times.
 
-As [PUB-SHAREDRANDOM] specifies, consensuses contain two shared random
+As \[PUB-SHAREDRANDOM\] specifies, consensuses contain two shared random
 values (the current one and the previous one). Hidden services and clients
 are asked to match these shared random values with descriptor time periods
 and use the right SRV when fetching/uploading descriptors. This section
@@ -228,7 +228,7 @@ Let's start with an illustration of the system:
 
 <a id="rend-spec-v3.txt-2.2.4.1"></a>
 
-#### Client behavior for fetching descriptors [CLIENTFETCH]
+#### Client behavior for fetching descriptors \[CLIENTFETCH\]
 
 And here is how clients use TPs and SRVs to fetch descriptors:
 
@@ -258,7 +258,7 @@ after SRV#2, it will still use TP#1 and SRV#1.
 
 <a id="rend-spec-v3.txt-2.2.4.2"></a>
 
-#### Service behavior for uploading descriptors [SERVICEUPLOAD]
+#### Service behavior for uploading descriptors \[SERVICEUPLOAD\]
 
 As discussed above, services maintain two active descriptors at any time. We
 call these the "first" and "second" service descriptors. Services rotate
@@ -272,7 +272,7 @@ values based on their position in the graph above. Here is the logic:
 
 <a id="rend-spec-v3.txt-2.2.4.2.1"></a>
 
-##### First descriptor upload logic [FIRSTDESCUPLOAD]
+##### First descriptor upload logic \[FIRSTDESCUPLOAD\]
 
 Here is the service logic for uploading its first descriptor:
 
@@ -308,7 +308,7 @@ first descriptor using TP#1 and SRV#1.
 
 <a id="rend-spec-v3.txt-2.2.4.2.2"></a>
 
-##### Second descriptor upload logic [SECONDDESCUPLOAD]
+##### Second descriptor upload logic \[SECONDDESCUPLOAD\]
 
 Here is the service logic for uploading its second descriptor:
 
@@ -342,7 +342,7 @@ second descriptor using TP#2 and SRV#2.
 
 <a id="rend-spec-v3.txt-2.2.4.3"></a>
 
-#### Directory behavior for handling descriptor uploads [DIRUPLOAD]
+#### Directory behavior for handling descriptor uploads \[DIRUPLOAD\]
 
 Upon receiving a hidden service descriptor publish request, directories MUST
 check the following:
@@ -368,12 +368,12 @@ necessary client credentials (for decrypting the second layer).
 
 <a id="rend-spec-v3.txt-2.2.5"></a>
 
-### Expiring hidden service descriptors [EXPIRE-DESC]
+### Expiring hidden service descriptors \[EXPIRE-DESC\]
 
 Hidden services set their descriptor's "descriptor-lifetime" field to 180
 minutes (3 hours). Hidden services ensure that their descriptor will remain
 valid in the HSDir caches, by republishing their descriptors periodically as
-specified in [WHEN-HSDESC].
+specified in \[WHEN-HSDESC\].
 
 Hidden services MUST also keep their introduction circuits alive for as long
 as descriptors including those intro points are valid (even if that's after
@@ -415,4 +415,4 @@ The right way for clients to detect such fraudulent addresses (which should
 only occur malevolently and never naturally) is to extract the ed25519
 public key from the onion address and multiply it by the ed25519 group order
 and ensure that the result is the ed25519 identity element. For more
-details, please see [TORSION-REFS].
+details, please see \[TORSION-REFS\].