diff options
Diffstat (limited to 'spec/srv-spec/protocol.md')
| -rw-r--r-- | spec/srv-spec/protocol.md | 24 |
1 files changed, 12 insertions, 12 deletions
diff --git a/spec/srv-spec/protocol.md b/spec/srv-spec/protocol.md index 7a17004..683b65e 100644 --- a/spec/srv-spec/protocol.md +++ b/spec/srv-spec/protocol.md @@ -4,13 +4,13 @@ In this section we give a detailed specification of the protocol. We describe the protocol participants' logic and the messages they send. The -encoding of the messages is specified in the next section ([SPEC]). +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] +## Commitment Phase \[COMMITMENTPHASE\] The commit phase lasts from 00:00UTC to 12:00UTC. @@ -43,7 +43,7 @@ authorities. Any subsequent commitments MUST be ignored. <a id="srv-spec.txt-3.1.2"></a> -### Persistent State During Commitment Phase [STATECOMMIT] +### Persistent State During Commitment Phase \[STATECOMMIT\] During the commitment phase, authorities save in their persistent state the authoritative commits they have received from each authority. Only one commit @@ -77,12 +77,12 @@ the new commitment MUST be ignored. <a id="srv-spec.txt-3.2.2"></a> -### Persistent State During Reveal Phase [STATEREVEAL] +### Persistent State During Reveal Phase \[STATEREVEAL\] During the reveal phase, authorities keep the authoritative commits from the commit phase in their persistent state. They also save any received reveals that correspond to authoritative commits and are valid (as specified in -[VALIDATEVALUES]). +\[VALIDATEVALUES\]). An authority that just received a reveal value from another authority's vote, MUST wait till the next voting round before including that reveal value in @@ -96,18 +96,18 @@ Finally, at 00:00UTC every day, authorities compute a fresh shared random value and this value must be added to the consensus so clients can use it. Authorities calculate the shared random value using the reveal values in -their state as specified in subsection [SRCALC]. +their state as specified in subsection \[SRCALC\]. Authorities at 00:00UTC start including this new shared random value in their votes, replacing the one from two protocol runs ago. Authorities also start including this new shared random value in the consensus as well. Apart from that, authorities at 00:00UTC proceed voting normally as they -would in the first round of the commitment phase (section [COMMITMENTPHASE]). +would in the first round of the commitment phase (section \[COMMITMENTPHASE\]). <a id="srv-spec.txt-3.3.1"></a> -### Shared Randomness Calculation [SRCALC] +### Shared Randomness Calculation \[SRCALC\] An authority that wants to derive the shared random value SRV, should use the appropriate reveal values for that time period and calculate SRV as @@ -126,7 +126,7 @@ is the corresponding reveal value of that authority for the current period. Also, REVEAL_NUM is the number of revealed values in this construction, VERSION is the protocol version number and PREVIOUS_SRV is the previous shared random value. If no previous shared random value is known, then -PREVIOUS_SRV is set to 32 NUL (\x00) bytes. +PREVIOUS_SRV is set to 32 NUL (\\x00) bytes. 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. @@ -135,7 +135,7 @@ are ordered based on the R_a value in ascending order. ## Bootstrapping Procedure -As described in [CONS], two shared random values are required for the HSDir +As described in \[CONS\], two shared random values are required for the HSDir overlay periods to work properly as specified in proposal 224. Hence clients MUST NOT use the randomness of this system till it has bootstrapped completely; that is, until two shared random values are included in a @@ -144,7 +144,7 @@ produced, which takes 48 hours. <a id="srv-spec.txt-3.5"></a> -## Rebooting Directory Authorities [REBOOT] +## Rebooting Directory Authorities \[REBOOT\] The shared randomness protocol must be able to support directory authorities who leave or join in the middle of the protocol execution. @@ -162,4 +162,4 @@ the protocol SHOULD still carry commits and reveals of others in their vote. Finally, authorities MUST implement their persistent state in such a way that they 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]. +kept). A suggested way to structure the persistent state is found at \[STATEFORMAT\]. |