-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 11/19/2015 3:57 PM, George Kadianakis wrote: > s7r <[email protected]> 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJWTfziAAoJEIN/pSyBJlsRd2gH/1TgJawIc1dOEabN2kzfn7Q+ RNQQxawge+XM3vLjf4mkkUp+uvUd98Qe49vmT8gHRyeTO/lfjYrZdbNoCiv3iGSE y7FJ2Zg0r6tw32ggRm812tyufcYrFwN1eV8OVxvKz0QUiAhchFFwHZCWGsICU63y NqsWc5mB98Y5ptTnP85Fwdn0rv3nH6lzt95pxjL6/SO0gE4s/QuzeaYAwwxtxkG+ Nx5U5emz8paIsMRa/668LlNG+lwkEuHR3VondZHUTe+OfLc4UqlKNsHNjNEdMoJ6 h4Is4a1mjH/SqSKwTOkrVvtzq5avnP3rgWG3Ukmt/bEdtMQUHZGVKX0SnFqE/ac= =VgM1 -----END PGP SIGNATURE----- _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
