4 files changed, 29 insertions, 29 deletions
diff --git a/spec/rend-spec/deriving-keys.md b/spec/rend-spec/deriving-keys.md
index cbf62fe..e3cca79 100644
--- a/spec/rend-spec/deriving-keys.md
+++ b/spec/rend-spec/deriving-keys.md
@@ -1,6 +1,6 @@
 <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
 periods), a hidden service host uses a different blinded private key
@@ -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,
@@ -90,7 +90,7 @@ 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
@@ -104,7 +104,7 @@ descriptor again to the responsible HSDirs for that time period.
 
 <a id="rend-spec-v3.txt-2.2.2.1"></a>
 
-#### Overlapping descriptors {#OVERLAPPING-DESCS}
+### Overlapping descriptors {#OVERLAPPING-DESCS}
 
 Hidden services need to upload multiple descriptors so that they can be
 reachable to clients with older or newer consensuses than them. Services
@@ -125,7 +125,7 @@ achieved.
 
 <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
@@ -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
@@ -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,7 +368,7 @@ 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
@@ -381,7 +381,7 @@ the time period has changed).
 
 <a id="rend-spec-v3.txt-2.2.6"></a>
 
-### URLs for anonymous uploading and downloading {#urls}
+## URLs for anonymous uploading and downloading {#urls}
 
 Hidden service descriptors conforming to this specification are uploaded
 with an HTTP POST request to the URL `/tor/hs/<version>/publish` relative to
@@ -395,7 +395,7 @@ anything else.
 
 <a id="rend-spec-v3.txt-2.2.7"></a>
 
-### Client-side validation of onion addresses {#addr-validation}
+## Client-side validation of onion addresses {#addr-validation}
 
 When a Tor client receives a prop224 onion address from the user, it
 MUST first validate the onion address before attempting to connect or
diff --git a/spec/rend-spec/hsdesc-encrypt.md b/spec/rend-spec/hsdesc-encrypt.md
index 10a7d77..06713a2 100644
--- a/spec/rend-spec/hsdesc-encrypt.md
+++ b/spec/rend-spec/hsdesc-encrypt.md
@@ -1,6 +1,6 @@
 <a id="rend-spec-v3.txt-2.5"></a>
 
-## Hidden service descriptors: encryption format {#HS-DESC-ENC}
+# Hidden service descriptors: encryption format {#HS-DESC-ENC}
 
 Hidden service descriptors are protected by two layers of encryption.
 Clients need to decrypt both layers to connect to the hidden service.
@@ -12,7 +12,7 @@ and protects against entities that do not possess valid client credentials.
 
 <a id="rend-spec-v3.txt-2.5.1"></a>
 
-### First layer of encryption {#HS-DESC-FIRST-LAYER}
+## First layer of encryption {#HS-DESC-FIRST-LAYER}
 
 The first layer of HS descriptor encryption is designed to protect
 descriptor confidentiality against entities who don't know the public
@@ -20,7 +20,7 @@ identity key of the hidden service.
 
 <a id="rend-spec-v3.txt-2.5.1.1"></a>
 
-#### First layer encryption logic {#first-layer-logic}
+### First layer encryption logic {#first-layer-logic}
 
 The encryption keys and format for the first layer of encryption are
 generated as specified in \[HS-DESC-ENCRYPTION-KEYS\] with customization
@@ -43,7 +43,7 @@ multiple of 10k bytes.
 
 <a id="rend-spec-v3.txt-2.5.1.2"></a>
 
-#### First layer plaintext format {#first-layer-plaintext}
+### First layer plaintext format {#first-layer-plaintext}
 
 After clients decrypt the first layer of encryption, they need to parse the
 plaintext to get to the second layer ciphertext which is contained in the
@@ -138,7 +138,7 @@ Here are all the supported fields:
 
 <a id="rend-spec-v3.txt-2.5.1.3"></a>
 
-#### Client behavior {#FIRST-LAYER-CLIENT-BEHAVIOR}
+### Client behavior {#FIRST-LAYER-CLIENT-BEHAVIOR}
 
 ```text
     The goal of clients at this stage is to decrypt the "encrypted" field as
@@ -160,7 +160,7 @@ Here are all the supported fields:
 
 <a id="rend-spec-v3.txt-2.5.1.4"></a>
 
-#### Hiding client authorization data {#hiding-client-auth}
+### Hiding client authorization data {#hiding-client-auth}
 
 ```text
     Hidden services should avoid leaking whether client authorization is
@@ -183,7 +183,7 @@ Here are all the supported fields:
 
 <a id="rend-spec-v3.txt-2.5.2"></a>
 
-### Second layer of encryption {#HS-DESC-SECOND-LAYER}
+## Second layer of encryption {#HS-DESC-SECOND-LAYER}
 
 The second layer of descriptor encryption is designed to protect descriptor
 confidentiality against unauthorized clients. If client authorization is
@@ -196,7 +196,7 @@ does not offer any additional security, but is still used.
 
 <a id="rend-spec-v3.txt-2.5.2.1"></a>
 
-#### Second layer encryption keys {#second-layer-keys}
+### Second layer encryption keys {#second-layer-keys}
 
 The encryption keys and format for the second layer of encryption are
 generated as specified in \[HS-DESC-ENCRYPTION-KEYS\] with customization
@@ -213,7 +213,7 @@ parameters as follows:
 
 <a id="rend-spec-v3.txt-2.5.2.2"></a>
 
-#### Second layer plaintext format {#second-layer-plaintext}
+### Second layer plaintext format {#second-layer-plaintext}
 
 After decrypting the second layer ciphertext, clients can finally learn the
 list of intro points etc. The plaintext has the following format:
@@ -396,7 +396,7 @@ newline.
 
 <a id="rend-spec-v3.txt-2.5.3"></a>
 
-### Deriving hidden service descriptor encryption keys {#HS-DESC-ENCRYPTION-KEYS}
+## Deriving hidden service descriptor encryption keys {#HS-DESC-ENCRYPTION-KEYS}
 
 In this section we present the generic encryption format for hidden service
 descriptors. We use the same encryption format in both encryption layers,
@@ -439,7 +439,7 @@ Here is the key generation logic:
 
 <a id="rend-spec-v3.txt-2.5.4"></a>
 
-### Number of introduction points {#NUM_INTRO_POINT}
+## Number of introduction points {#NUM_INTRO_POINT}
 
 This section defines how many introduction points an hidden service
 descriptor can have at minimum, by default and the maximum:
diff --git a/spec/rend-spec/hsdesc-outer.md b/spec/rend-spec/hsdesc-outer.md
index 5f4b5de..ea623b8 100644
--- a/spec/rend-spec/hsdesc-outer.md
+++ b/spec/rend-spec/hsdesc-outer.md
@@ -1,6 +1,6 @@
 <a id="rend-spec-v3.txt-2.4"></a>
 
-## Hidden service descriptors: outer wrapper \[DESC-OUTER\]
+# Hidden service descriptors: outer wrapper \[DESC-OUTER\]
 
 The format for a hidden service descriptor is as follows, using the
 meta-format from dir-spec.txt.
diff --git a/spec/rend-spec/shared-random.md b/spec/rend-spec/shared-random.md
index b06558f..e6b2452 100644
--- a/spec/rend-spec/shared-random.md
+++ b/spec/rend-spec/shared-random.md
@@ -1,6 +1,6 @@
 <a id="rend-spec-v3.txt-2.3"></a>
 
-## Publishing shared random values {#PUB-SHAREDRANDOM}
+# Publishing shared random values {#PUB-SHAREDRANDOM}
 
 Our design for limiting the predictability of HSDir upload locations
 relies on a shared random value (SRV) that isn't predictable in advance or
@@ -19,7 +19,7 @@ According to proposal 250, we add two new lines in consensuses:
 
 <a id="rend-spec-v3.txt-2.3.1"></a>
 
-### Client behavior in the absence of shared random values {#client-disaster}
+## Client behavior in the absence of shared random values {#client-disaster}
 
 If the previous or current shared random value cannot be found in a
 consensus, then Tor clients and services need to generate their own random
@@ -36,7 +36,7 @@ found originally.
 
 <a id="rend-spec-v3.txt-2.3.2"></a>
 
-### Hidden services and changing shared random values {#service-problems}
+## Hidden services and changing shared random values {#service-problems}
 
 It's theoretically possible that the consensus shared random values will
 change or disappear in the middle of a time period because of directory