diff options
Diffstat (limited to 'spec/srv-spec/discussion.md')
| -rw-r--r-- | spec/srv-spec/discussion.md | 5 |
1 files changed, 4 insertions, 1 deletions
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. - |