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. Cheers, Michael
Attachment:
0x9FC527CC.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev