diff options
author | Nick Mathewson <nickm@torproject.org> | 2023-10-12 12:27:58 -0400 |
---|---|---|
committer | Nick Mathewson <nickm@torproject.org> | 2023-10-12 12:27:58 -0400 |
commit | f7e5a95ee96d8ef52c1732d066c1249a6f84391e (patch) | |
tree | 2e1ddd85f471143518d0df7c7645d066d43bc149 /spec/srv-spec/discussion.md | |
parent | e4e0d93d56ee8c1aec4c2efaa7046b651f0fe55c (diff) | |
download | torspec-f7e5a95ee96d8ef52c1732d066c1249a6f84391e.tar.gz torspec-f7e5a95ee96d8ef52c1732d066c1249a6f84391e.zip |
Convert text specifications to mdbook.
Diffstat (limited to 'spec/srv-spec/discussion.md')
-rw-r--r-- | spec/srv-spec/discussion.md | 39 |
1 files changed, 39 insertions, 0 deletions
diff --git a/spec/srv-spec/discussion.md b/spec/srv-spec/discussion.md new file mode 100644 index 0000000..9d469fc --- /dev/null +++ b/spec/srv-spec/discussion.md @@ -0,0 +1,39 @@ +<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 +because prop225 doesn't specify how the shared random value gets to the +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 +whole day (24 hours), when only 3 rounds would be sufficient to generate a +shared random value. + +We decided to do it this way, because we piggyback on the Tor voting +protocol which also happens every hour. + +We could instead only do the shared randomness protocol from 21:00 to 00:00 +every day. Or to do it multiple times a day. + +However, we decided that since the shared random value needs to be in every +consensus anyway, carrying the commitments/reveals as well will not be a +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 +the whole day. In theory, we could recover by calculating the shared +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. + |