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?

Yes, but not directly related to this thread. I will file it via trac.tpo.

> One gotcha is
> that checks that require state (such as comparing with the last hour's
> consensus) is a bit more work.

Yes, that is what I was wondering if DocTor keeps any state at all already.

>> 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

I assume this has not been deployed - 50% or maybe 40% are fine I guess. 
To come up with good threshold values
one would need to look at historic data for the past few months.

twitter: @nusenu_

Attachment: signature.asc
Description: OpenPGP digital signature

tor-dev mailing list

Reply via email to