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

[s7r]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


On 11/19/2015 3:57 PM, George Kadianakis wrote:
> s7r <s7r at 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.
-----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-----