You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Basically, arti refuses to use relays without the Stable flag for some purposes; notably as hidden service rendezvous or intro points.
I'm not sure whether the c-tor client is affected. It's possible that it doesn't have this requirement or ignores it when TestingTorNetwork is set.
I have verified that in a small tornettools test run, some relays don't get the Stable flag.
It might be a good idea to set AuthDirVoteStableGuaranteeMinUptime in the authority's config files, which should ensure all relays get the Stable flag. Particularly if/when we want to include arti clients, but it might also be a good idea to check whether c-tor clients are affected by this.
The problem doesn't seem to crop up as much when all relays are started at once (as I think tornettools does?), though I'm not sure why.
IIUC, in the absence of long-term reliability data, the authorities will give the Stable flag to relays that have a self-reported uptime of greater than the median or greater than AuthDirVoteStableGuaranteeMinUptime (default 30 days). I would think this would always result in half of the relays not getting the Stable flag when we don't override AuthDirVoteStableGuaranteeMinUptime, but it experimentally isn't quite that bad in practice if all relays are started at once. (I think the self-reported uptimes are rounded to the second; maybe they all or mostly end up tied with the median?)
We might as well set AuthDirVoteStableGuaranteeMinUptime in all cases so we're not left wondering about the more complex TestingTorNetwork, unless there are cases where setting it would cause a problem (do all recent versions of Tor support it)?
There's a little bit of analysis and discussion in #124. Letting @robgjansen handle a more thorough investigation and tuning, possibly rolling together with some other changes that may require some tuning.
Activity
sporksmith commentedon Jun 16, 2026
The problem doesn't seem to crop up as much when all relays are started at once (as I think tornettools does?), though I'm not sure why.
IIUC, in the absence of long-term reliability data, the authorities will give the Stable flag to relays that have a self-reported uptime of greater than the median or greater than
AuthDirVoteStableGuaranteeMinUptime(default 30 days). I would think this would always result in half of the relays not getting the Stable flag when we don't overrideAuthDirVoteStableGuaranteeMinUptime, but it experimentally isn't quite that bad in practice if all relays are started at once. (I think the self-reported uptimes are rounded to the second; maybe they all or mostly end up tied with the median?)robgjansen commentedon Jun 17, 2026
We might as well set
AuthDirVoteStableGuaranteeMinUptimein all cases so we're not left wondering about the more complex TestingTorNetwork, unless there are cases where setting it would cause a problem (do all recent versions of Tor support it)?Set "AuthDirVoteStableGuaranteeMinUptime 0".
Set "AuthDirVoteStableGuaranteeMinUptime 0".
sporksmith commentedon Jun 29, 2026
There's a little bit of analysis and discussion in #124. Letting @robgjansen handle a more thorough investigation and tuning, possibly rolling together with some other changes that may require some tuning.