On 21/11/15 12:05, George Kadianakis wrote: >> 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. Would it help if we defined the disaster SRV as being derived from the last SRV for which there was a consensus, rather than from the previous round's SRV? That would allow the network to converge on the same sequence of disaster SRVs, and then switch back from disaster mode to business-as-usual mode, just by sharing valid consensuses. >> 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. When the failed dirauths come back online they should accept the consensus that was generated in their absence. So in the following round, all dirauths will vote for an SRV based on the one that was agreed while the failed dirauths were offline. Cheers, Michael > 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. > _______________________________________________ > tor-dev mailing list > tor-dev@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
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