7 files changed, 42 insertions, 8 deletions
diff --git a/spec/srv-spec/acknowledgements.md b/spec/srv-spec/acknowledgements.md
index 171cfde..edeb53e 100644
--- a/spec/srv-spec/acknowledgements.md
+++ b/spec/srv-spec/acknowledgements.md
@@ -1,4 +1,5 @@
 <a id="srv-spec.txt-7"></a>
+
 # Acknowledgements
 
 Thanks to everyone who has contributed to this design with feedback and
@@ -26,4 +27,3 @@ References:
 [VDFS]:
    https://eprint.iacr.org/2018/601.pdf
 ```
-
diff --git a/spec/srv-spec/discussion.md b/spec/srv-spec/discussion.md
index 9d469fc..ea38318 100644
--- a/spec/srv-spec/discussion.md
+++ b/spec/srv-spec/discussion.md
@@ -1,7 +1,9 @@
 <a id="srv-spec.txt-6"></a>
+
 # Discussion
 
 <a id="srv-spec.txt-6.1"></a>
+
 ## Why the added complexity from proposal 225?
 
 The complexity difference between this proposal and prop225 is in part
@@ -10,6 +12,7 @@ clients. This proposal spends lots of effort specifying how the two shared
 random values can always be readily accessible to clients.
 
 <a id="srv-spec.txt-6.2"></a>
+
 ## Why do you do a commit-and-reveal protocol in 24 rounds?
 
 The reader might be wondering why we span the protocol over the course of a
@@ -28,6 +31,7 @@ big problem. Also, this way we give more chances for a failing dirauth to
 recover and rejoin the protocol.
 
 <a id="srv-spec.txt-6.3"></a>
+
 ## Why can't we recover if the 00:00UTC consensus fails?
 
 If the 00:00UTC consensus fails, there will be no shared random value for
@@ -36,4 +40,3 @@ randomness of the day at 01:00UTC instead. However, the engineering issues
 with adding such recovery logic are too great. For example, it's not easy
 for an authority who just booted to learn whether a specific consensus
 failed to be created.
-
diff --git a/spec/srv-spec/introduction.md b/spec/srv-spec/introduction.md
index 5ed203b..37d6473 100644
--- a/spec/srv-spec/introduction.md
+++ b/spec/srv-spec/introduction.md
@@ -1,7 +1,9 @@
 <a id="srv-spec.txt-1"></a>
+
 # Introduction
 
 <a id="srv-spec.txt-1.1"></a>
+
 ## Motivation
 
 For the next generation hidden services project, we need the Tor network to
@@ -17,6 +19,7 @@ Tor-related protocols (e.g. OnioNS) or even non-Tor-related (e.g. warrant
 canaries).
 
 <a id="srv-spec.txt-1.2"></a>
+
 ## Previous work
 
 Proposal 225 specifies a commit-and-reveal protocol that can be run as an
@@ -25,4 +28,3 @@ However, directory authority operators feel unsafe running a third-party
 script that opens TCP ports and accepts connections from the Internet.
 Hence, this proposal aims to embed the commit-and-reveal idea in the Tor
 voting process which should make it smoother to deploy and maintain.
-
diff --git a/spec/srv-spec/overview.md b/spec/srv-spec/overview.md
index 728aad2..6da4599 100644
--- a/spec/srv-spec/overview.md
+++ b/spec/srv-spec/overview.md
@@ -1,4 +1,5 @@
 <a id="srv-spec.txt-2"></a>
+
 # Overview
 
 This proposal alters the Tor consensus protocol such that a random number is
@@ -10,6 +11,7 @@ The proposal also specifies how the final shared random value is embedded
 in consensus documents so that clients who need it can get it.
 
 <a id="srv-spec.txt-2.1"></a>
+
 ## Introduction to our commit-and-reveal protocol
 
 Every day, before voting for the consensus at 00:00UTC each authority
@@ -23,6 +25,7 @@ commitment value you should not be able to derive the underlying reveal
 value. The construction of these values is specified in section [COMMITREVEAL].
 
 <a id="srv-spec.txt-2.1"></a>
+
 ## Ten thousand feet view of the protocol
 
 Our commit-and-reveal protocol aims to produce a fresh shared random value
@@ -58,6 +61,7 @@ Commit phase:
 ```
 
 <a id="srv-spec.txt-2.3"></a>
+
 ## How we use the consensus [CONS]
 
 The produced shared random values need to be readily available to
@@ -81,6 +85,7 @@ For this, a new SR consensus method will be needed to indicate which
 authorities support this new protocol.
 
 <a id="srv-spec.txt-2.3.1"></a>
+
 ### Inserting Shared Random Values in the consensus
 
 After voting happens, we need to be careful on how we pick which shared
@@ -118,6 +123,7 @@ this because changing SRVs in the middle of the day has terrible
 reachability consequences for hidden service clients.
 
 <a id="srv-spec.txt-2.4"></a>
+
 ## Persistent State of the Protocol [STATE]
 
 A directory authority needs to keep a persistent state on disk of the on
@@ -133,11 +139,12 @@ previous time period must also be present in the state at all times if they
 are available.
 
 <a id="srv-spec.txt-2.5"></a>
+
 ## Protocol Illustration
 
 An illustration for better understanding the protocol can be found here:
 
-https://people.torproject.org/~asn/hs_notes/shared_rand.jpg
+<https://people.torproject.org/~asn/hs_notes/shared_rand.jpg>
 
 It reads left-to-right.
 
@@ -155,4 +162,3 @@ example, the SRV was computed with 3 authority contributions and its value
 is "a56fg39h".
 
 We advice you to revisit this after you have read the whole document.
-
diff --git a/spec/srv-spec/protocol.md b/spec/srv-spec/protocol.md
index 4567f89..7a17004 100644
--- a/spec/srv-spec/protocol.md
+++ b/spec/srv-spec/protocol.md
@@ -1,4 +1,5 @@
 <a id="srv-spec.txt-3"></a>
+
 # Protocol
 
 In this section we give a detailed specification of the protocol. We
@@ -8,6 +9,7 @@ encoding of the messages is specified in the next section ([SPEC]).
 Now we go through the phases of the protocol:
 
 <a id="srv-spec.txt-3.1"></a>
+
 ## Commitment Phase [COMMITMENTPHASE]
 
 The commit phase lasts from 00:00UTC to 12:00UTC.
@@ -20,6 +22,7 @@ in their permanent state. We call a commit by Alice "authoritative" if it was
 included in Alice's vote.
 
 <a id="srv-spec.txt-3.1.1"></a>
+
 ### Voting During Commitment Phase
 
 During the commit phase, each authority includes in its votes:
@@ -39,6 +42,7 @@ phase, only the first commitment should be taken in account by other
 authorities. Any subsequent commitments MUST be ignored.
 
 <a id="srv-spec.txt-3.1.2"></a>
+
 ### Persistent State During Commitment Phase [STATECOMMIT]
 
 During the commitment phase, authorities save in their persistent state the
@@ -46,6 +50,7 @@ authoritative commits they have received from each authority. Only one commit
 per authority must be considered trusted and active at a given time.
 
 <a id="srv-spec.txt-3.2"></a>
+
 ## Reveal Phase
 
 The reveal phase lasts from 12:00UTC to 00:00UTC.
@@ -54,6 +59,7 @@ Now that the commitments have been agreed on, it's time for authorities to
 reveal their random values.
 
 <a id="srv-spec.txt-3.2.1"></a>
+
 ### Voting During Reveal Phase
 
 During the reveal phase, each authority includes in its votes:
@@ -70,6 +76,7 @@ commitment during the reveal phase or introduce a new commitment,
 the new commitment MUST be ignored.
 
 <a id="srv-spec.txt-3.2.2"></a>
+
 ### Persistent State During Reveal Phase [STATEREVEAL]
 
 During the reveal phase, authorities keep the authoritative commits from the
@@ -82,6 +89,7 @@ MUST wait till the next voting round before including that reveal value in
 its votes.
 
 <a id="srv-spec.txt-3.3"></a>
+
 ## Shared Random Value Calculation At 00:00UTC
 
 Finally, at 00:00UTC every day, authorities compute a fresh shared random
@@ -98,6 +106,7 @@ Apart from that, authorities at 00:00UTC proceed voting normally as they
 would in the first round of the commitment phase (section [COMMITMENTPHASE]).
 
 <a id="srv-spec.txt-3.3.1"></a>
+
 ### Shared Randomness Calculation [SRCALC]
 
 An authority that wants to derive the shared random value SRV, should use
@@ -123,6 +132,7 @@ To maintain consistent ordering in HASHED_REVEALS, all the ID_a | R_a pairs
 are ordered based on the R_a value in ascending order.
 
 <a id="srv-spec.txt-3.4"></a>
+
 ## Bootstrapping Procedure
 
 As described in [CONS], two shared random values are required for the HSDir
@@ -133,6 +143,7 @@ consensus. This should happen after three 00:00UTC consensuses have been
 produced, which takes 48 hours.
 
 <a id="srv-spec.txt-3.5"></a>
+
 ## Rebooting Directory Authorities [REBOOT]
 
 The shared randomness protocol must be able to support directory
@@ -152,4 +163,3 @@ Finally, authorities MUST implement their persistent state in such a way that th
 will never commit two different values in the same protocol run, even if they
 have to reboot in the middle (assuming that their persistent state file is
 kept). A suggested way to structure the persistent state is found at [STATEFORMAT].
-
diff --git a/spec/srv-spec/security-analysis.md b/spec/srv-spec/security-analysis.md
index 698cac5..658c2f8 100644
--- a/spec/srv-spec/security-analysis.md
+++ b/spec/srv-spec/security-analysis.md
@@ -1,7 +1,9 @@
 <a id="srv-spec.txt-5"></a>
+
 # Security Analysis
 
 <a id="srv-spec.txt-5.1"></a>
+
 ## Security of commit-and-reveal and future directions
 
 The security of commit-and-reveal protocols is well understood, and has
@@ -16,6 +18,7 @@ crypto and more complex protocols so this seems like an acceptable solution
 for now.
 
 Here are some examples of possible future directions:
+
 - Schemes based on threshold signatures (e.g. see [HOPPER])
 - Unicorn scheme by Lenstra et al. [UNICORN]
 - Schemes based on Verifiable Delay Functions [VDFS]
@@ -24,6 +27,7 @@ For more alternative approaches on collaborative random number generation
 also see the discussion at [RNGMESSAGING].
 
 <a id="srv-spec.txt-5.2"></a>
+
 ## Predicting the shared random value during reveal phase
 
 The reveal phase lasts 12 hours, and most authorities will send their
@@ -39,6 +43,7 @@ Any other protocols using the shared random value from this system should
 be aware of this property.
 
 <a id="srv-spec.txt-5.3"></a>
+
 ## Partition attacks
 
 This design is not immune to certain partition attacks.  We believe they
@@ -50,6 +55,7 @@ attacks. Nevertheless, this section describes all possible partition attack
 and how to detect them.
 
 <a id="srv-spec.txt-5.3.1"></a>
+
 ### Partition attacks during commit phase
 
 A malicious directory authority could send only its commit to one single
@@ -67,6 +73,7 @@ coming from an authority should NEVER be different between authorities. If
 so, this means an attack is ongoing or very bad bug (highly unlikely).
 
 <a id="srv-spec.txt-5.3.2"></a>
+
 ### Partition attacks during reveal phase
 
 Let's consider Alice, a malicious directory authority. Alice could wait
@@ -95,4 +102,3 @@ will cause quite some noise. Furthermore, the authority needs to send
 different votes to different auths which is detectable. Like the commit
 phase attack, the detection here is to make sure that the commitment values
 in a vote coming from an authority are always the same for each authority.
-
diff --git a/spec/srv-spec/specification-spec.md b/spec/srv-spec/specification-spec.md
index 1ff7db3..8a35d22 100644
--- a/spec/srv-spec/specification-spec.md
+++ b/spec/srv-spec/specification-spec.md
@@ -1,7 +1,9 @@
 <a id="srv-spec.txt-4"></a>
+
 # Specification [SPEC]
 
 <a id="srv-spec.txt-4.1"></a>
+
 ## Voting
 
 This section describes how commitments, reveals and SR values are encoded in
@@ -17,6 +19,7 @@ Participating authorities need to include the line:
 in their votes to announce that they take part in the protocol.
 
 <a id="srv-spec.txt-4.1.1"></a>
+
 ### Computing commitments and reveals [COMMITREVEAL]
 
 A directory authority that wants to participate in this protocol needs to
@@ -44,6 +47,7 @@ REVEAL = base64-encode( TIMESTAMP || H(RN) )
 ```
 
 <a id="srv-spec.txt-4.1.2"></a>
+
 ### Validating commitments and reveals [VALIDATEVALUES]
 
 Given a COMMIT message and a REVEAL message it should be possible to verify
@@ -59,6 +63,7 @@ Authorities should ignore reveal values during the Reveal Phase that don't
 correspond to commit values published during the Commitment Phase.
 
 <a id="srv-spec.txt-4.1.4"></a>
+
 ### Encoding commit/reveal values in votes [COMMITVOTE]
 
 An authority puts in its vote the commitments and reveals it has produced and
@@ -76,6 +81,7 @@ ALGNAME is the hash algorithm that should be used to compute COMMIT and
 REVEAL which is "sha3-256" for version 1.
 
 <a id="srv-spec.txt-4.1.5"></a>
+
 ### Shared Random Value [SRVOTE]
 
 Authorities include a shared random value (SRV) in their votes using the
@@ -94,12 +100,14 @@ To maintain consistent ordering, the shared random values of the previous
 period should be listed before the values of the current period.
 
 <a id="srv-spec.txt-4.2"></a>
+
 ## Encoding Shared Random Values in the consensus [SRCONSENSUS]
 
 Authorities insert the two active shared random values in the consensus
 following the same encoding format as in [SRVOTE].
 
 <a id="srv-spec.txt-4.3"></a>
+
 ## Persistent state format [STATEFORMAT]
 
 As a way to keep ground truth state in this protocol, an authority MUST
@@ -156,4 +164,3 @@ Finally is the shared random value section.
         This is the latest shared random value. The fields are the same as in
         section [SRVOTE].
 ```
-