s7r s7r@sky-ip.org 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.