> On 21 Nov 2015, at 04:14, Michael Rogers <[email protected]> wrote: > > On 20/11/15 16:24, David Goulet wrote: >> # Consensus >> (This goes for both previous and current SRV) >> if SRV in consensus: >> dirauth MUST keep it even if the one they have doesn't match. >> Majority has decided what should be used. >> else: >> dirauth MUST discard the SRV it has. > > This seems like an excellent idea. Relying on the consensus ensures that > no matter what crazy shit happens to the individual dirauths, they can > eventually converge on the same previous and current SRV values (or > agree that no such SRV values exist) by sharing the valid consensus > documents they've seen. > >> Side effect of only keeping SRV that are in the consensus. If one voting >> round goes bad for X reason and consensus end up with no SRV, we end up >> in bootstrapping mode that is no previous nor current SRV in the >> consensus which is problematic because for 48 hours, we won't have a >> previous SRV which is the one used by everyone. >> >> I don't see a way to get out of this because consensus is decided from >> the votes deterministically thus if not enough vote for SR values, we'll >> end up with a consensus with none so this is why client/HS have to >> fallback to a disaster value by themselves I think which can NOT be >> based on the previous SRV. > > If there's no consensus on a fresh SRV for a while, clients and relays > can keep producing emergency SRVs by hashing the last fresh SRV they > know about, right? It doesn't have to be yesterday's SRV - if the last > fresh SRV was produced a week ago, they keep hashing based on that > (which is not ideal of course). As above, using the consensus seems like > a good idea because it allows the network to converge on the same values > just by sharing valid consensus documents.
If there's no consensus on a fresh SRV, why not just use the disaster recovery
procedure?
That is:
# Consensus
if majority agrees on SR value(s):
put in consensus
else:
put disaster recovery SR value (based on last round's agreed SR value,
if any) in consensus
Output: consensus is created
(Proceed like the 16:00 period)
That way, clients and relays don't need to do anything special: there will
always be a SRV in the consensus.
This means that the SR consensus method will always produce a SR value, which I
believe is a much better property than occasionally failing to produce a value.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
