-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 11/19/2015 3:57 PM, George Kadianakis wrote:
s7r s7r@sky-ip.org writes:
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?
Sorry for the confusion. The participation flag should be 0 or 1 yes, but it should only refer to current consensus SR value. If our participation flag is 0, we don't vote a SR value for the next consensus. This doesn't prevent us from participating in the protocol run related to the SR value for the next day (after 00:00 UTC).
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.
Yes, agreed.
I have another crazy idea which maybe will help, or if not, hopefully at least will inspire us with another, better idea. Here goes:
Divide the consensus into 2 sections with separate signatures:
1) main section - general consensus with all the data as we have it today 2) SR section - which will include previous consensus SR value, current consensus SR value and separate signatures.
In the consensus main section we include in addition: Each dirauth participation flag (0 or 1) for current SR value and commits/reveals for the next SR value.
Dirauths who don't know previous SR value / current SR value or if the consensus at 00:00 UTC was created or not (disaster or not), simply publish a participation flag 0. They don't vote anything in the SR section.
In the consensus SR section we include: - - participating dirauths and their identities (ed25519, RSA) - - previous consensus SR value, current consensus SR value - - separate signatures for this section
The number of signatures required for the SR section to be valid will be the exact number of dirauths that published a participation flag 1, but not less than 3 signatures will be accepted.
Please don't shoot me if this is terrible - I am only trying hard to ensure a dirauth cannot break consensus accidentally if it is just out of sync and misses some information (edge cases) while also using a logic that won't over complicate stuff.