[tor-dev] Shared random value calculation edge cases (proposal 250)
s7r at sky-ip.org
Thu Nov 19 16:46:26 UTC 2015
-----BEGIN PGP SIGNED MESSAGE-----
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.
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
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)
-----END PGP SIGNATURE-----
More information about the tor-dev