[tor-dev] monitoring significant drops of flags in dirauth votes

[Damian Johnson]

> thanks for implementing the new check so fast.

No problem! Thanks for suggesting it.

> This is also very useful but slightly different from what I had in mind,
> because it would not trigger if dirauths upgrade from A to B in the
> same hour and most exits, guards or hsdirs are gone due to a bug in version B.

This should catch a bug with B unless every authority upgrades to B in
the same hour. Otherwise we'd get an alert - either because the
majority is B and the remaining A votes are out of band, or the
consensus is made with A and authorities that upgraded to B are
different.

Is there another check in particular that you'd like? One gotcha is
that checks that require state (such as comparing with the last hour's
consensus) is a bit more work.

> I tried to find something related to this in the 0.3.3.x changelogs
> because moria1 (the affected dirauth) is the only one running tor alpha
> but I didn't find anything related to a change in what is required
> to earn the HSDir flag. Has there been any change related to how
> HSDir is assigned that would explain that significant difference?

For what it's worth I started with alarming when authorities differed
more than 20% from the consensus but it was a bit noisier...

[consensus-health] NOTICE: longclaw had 3100 HSDir flags in its vote
but the consensus had 2583
[consensus-health] NOTICE: moria1 had 756 HSDir flags in its vote but
the consensus had 2583
[consensus-health] NOTICE: moria1 had 1397 Guard flags in its vote but
the consensus had 1761