On 21 Nov 2015, at 04:14, Michael Rogers michael@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