> On 21 Nov 2015, at 04:14, Michael Rogers <mich...@briarproject.org> 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 tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev