s7r <[email protected]> writes: > Hello, > > Saw the content of this section in master was corrected, yet the > subtitle is little confusing: > > 4.1.6. Including the ed25519 shared randomness key in votes [SRKEY] > > From the content of this section I understand that we are going to > include the ed25519 medium term signing key, certificate and master > identity key. The content is clear, but maybe we should change the > subtitle too, since there's no SR key: > > 4.1.6. Including the ed25519 medium term signing key and master > identity key in votes [ED25519ID] >
You are right. We need to fix this. Noted. > Edge cases are the main reason I suggested in my previous emails to > require at least 2 or 3 reveal rounds in order to allow a dirauth to > participate in the shared randomness calculation for that day. However > this won't help in case a dirauth needs to vote at 01:00 UTC and > doesn't know anything. > > 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. > I'm not sure exactly what you are suggesting here. That the participation flag should not simply be 0 or 1, and that it should have more purposes? > 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. > Yes, that *could* be a way to do it. Have dirauths who don't know the current/previous SRV get it from votes. I think we all agree that dirauths who don't know the current/previous SRV should get it from the previous consensus (even though this logic has not been implemented yet). Getting it directly from the votes would be a different scheme that maybe we should think about. _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
