[tor-dev] Shared random value calculation edge cases (proposal 250)

[George Kadianakis]

s7r <s7r at sky-ip.org> writes:

> Hello,
>
> <snip>
>
> The idea of adding flags in the votes so each dirauth can advertise if
> it is participating (has an opinion for the <current> SR or not) is
> great and helps us build more defenses, probably make it easier in the
> future too if we decide to change anything.
>
> What if the consensus for SR calculation would define majority based
> on dirauths actually participating (and advertising so with a flag in
> the vote). Also, the participating or not participating flag should be
> used per vote/consensus and split into:
>
> a) we know current SR value for today so we vote it
> or
> we know previous SR value and we know for sure if we should follow the
> disaster protocol or not (in case we are about to vote at 01:00 UTC).
> so
> We participate in the vote for <current SR>.
>
> b) we are able to participate in this protocol run which will
> calculate the SR value for next day (after 00:00 UTC) so we send our
> commits/reveals.
>
> This is useful in case we are a dirauth that joined at 00:30 UTC and
> we couldn't get the _latest_ consensus (to find out if the 00:00 UTC
> consensus was created, and if not, previous SR value so we can follow
> the disaster procedure) we will not have an opinion for the <current>
> SR value at 01:00 UTC, but we can start participating in the protocol
> run for the next day - send our commit values. Once we decided on a
> <current> SR value for that day we save it and vote normally next time.
>
> So, if we have 5 dirauths running/signing consensus in total, out of
> which only 4 participate in the shared randomness protocol, the 4
> participating ones should be able to create a valid consensus
> themselves with the insurance that the 5th one won't break consensus.
>
> One way to do this is: the dirauth which is not participating will
> take the SR value voted by the majority of the participating dirauths
> and include that in its consensus and sign. We need at least 3
> dirauths agreeing on a SR value in order to accept it.
>
> Is this crazy? It shouldn't open the door new attacks, since this
> doesn't allow a single actor to game it, only the majority could game it.
>

Thanks for the suggestions.

Let me try to suggest a procedure here based on your ideas and some other ideas.

[Notation: SRV = shared random value]

The goal here is to minimize the edge cases during SRV calculation and disaster
SRV calculation. The edge cases here appear because there is no clear view on
whether other dirauths know the current or previous SRVs, or whether the SRV for
this period was ever created. The disaster recovery scenario is especially
annoying here. 

Here are some edge cases for example:

* Dirauth boots up at 02:00UTC and the 01:00UTC consensus does not contain any
  SR information (maybe because not enough SR-enabled dirauths participated at
  that time).

  Should the dirauth do the disaster recovery procedure, or just play it cool
  and put no SR information on the consensus? If it has to do disaster recovery,
  then what previous SRV does it use (the 01:00UTC consensus did not contain
  such info)?

  This type of edge case is my main concern, since with dirauths upgrading and
  going offline at random times, it's likely that we will eventually create a
  consensus without SR info in the middle of the protocol run.

* Dirauth boots up at 23:55UTC without having a previous consensus. It is
  supposed to vote and form a 00:00UTC consensus without knowing any previous
  SRVs. How does it figure out whether all the other dirauths are also
  bootstrapping, or whether the other dirauths actually know the previous SRVs?

Here are some prerequisites for the logic I'm going to suggest. The two first
suggestions are useful in any case, I think:

- First of all, we treat consensuses as trusted, so dirauths MUST learn
  previous/current SRVs they didn't know about from any consensus they fetch.

- We are also going to assume that we have some sort of "SR flag" on votes to
  denote whether the dirauth participates in the protocol.

- We are introducing another 'status' for shared random values (see [SRVOTE]).  

  Specifically, if a dirauth witnessed a 00:00UTC consensus failing to be
  created, or it did not contain any SRV information, then it sets the status of
  "shared-rand-current-value" in its votes to "none".

Now we are going to use the SRV lines in the votes as an indicator on how the
consensus creation should play out.

================================================================================

Here is some logic for the consensus at 00:00UTC:

     if majority of votes have disabled the SR flag:
               then don't write anything SR-related to consensus 
               exit

     If the majority of votes contain the previous SRV value:
               then calculate SRV as detailed in section [SRCALC]  
     else:
               then calculate SRV as in [SRCALC] but with previous_SRV set to 0

And here is some logic for all the other consensuses (to figure out when
dirauths should perform the disaster procedure):

     if majority of votes have disabled the SR flag:
               then don't write anything SR-related to consensus 
               exit

     if we know the current SRV:
               then write it on the consensus
               exit

     if the majority of votes have the current SRV status as "none" _AND_
        those votes also contain the previous SRV value:
               then do the disaster SRV procedure
     else:
               then don't write anything SR-related to consensus             

================================================================================

This _might_ work for fixing a good bunch of edge cases. But is it far too complex?

Should we just assume that these things will never happen on the real network
and avoid baking additional complexity? What do you think? :/