Tim Wilson-Brown - teor teor2345@gmail.com writes:
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)
True. However, if the majority cannot agree on SR values, how can a majority be formed to agree on disaster recovery SRVs? The problem here is that the disaster SRVs are derived from the previous SRV.
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.
Indeed, that's something very important.
Yesterday, we were discussing with David how bad it would be if 2-3 SR-enabled dirauths drop offline during voting, and the rest dirauths generate a consensus without an SR value (because the consensus method requirement for SR failed or something).
In this case, some clients will have a consensus with an SR value, and some other clients will have a consensus with no SR value. Those two client sets will use a different formula to connect to hidden services, bringing out terrible reachability consequences.
I wonder what's the solution here. We don't want a single consensus to break reachability for all hidden services. I wonder what should we do? Should we just make it ultra unlikely that a consensus will be generated without SR values? For exmaple, we could require every dirauth to participate in the protocol so that we either have a consensus with SR or no consensus at all. This will slow down deployment, but it might make the system more bullet proof.