What are all the current requirements for a relay to get a HSDir flag? 96 (97?) hours of uptime and what else? Can someone tell me what my relay, MYCROFTsOtherChild, is missing for a HSDir flag? Thanks in advance for any relevant information.
Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
On 2021-05-22 11:31:12, "Scott Bennett" bennett@sdf.org wrote:
What are all the current requirements for a relay to get aHSDir flag? 96 (97?) hours of uptime and what else? Can someone tell me what my relay, MYCROFTsOtherChild, is missing for a HSDir flag?
From the spec:
https://github.com/torproject/torspec/blob/master/dir-spec.txt
"HSDir" -- A router is a v2 hidden service directory if it stores and serves v2 hidden service descriptors, has the Stable and Fast flag, and the authority believes that it's been up for at least 96 hours (or the current value of MinUptimeHidServDirectoryV2).
"Fast" -- A router is 'Fast' if it is active, and its bandwidth is either in the top 7/8ths for known active routers or at least 100KB/s.
If you look at the concensus health (https://consensus-health.torproject.org/), go to the bottom and enter your relay nickname you will see what each of the authorities think about your relay. moria1 and bastet are very stingy about handing out HSDir. I don't think any of my relays ever has gotten it from them. Of the rest, the authorities that think your relay is "Fast" has also awarded it HSDir. Unfortunately 3 don't think the relay is "Fast" so no HSDir. And with only a 4/9 vote the relay don't get the HSDir flag.
What year is it?
On 24. May 2021, at 13:53, Logforme m7527@abc.se wrote:
"Fast" -- A router is 'Fast' if it is active, and its bandwidth is either in the top 7/8ths for known active routers or at least 100KB/s.
I second this. We are in 2021 and a relay is considered fast if it is above 100KB/s...? I don’t think a later dialup service should be considered a fast relay.
Thanks, John Csuti (216) 633-XXXX
On May 25, 2021, at 4:18 AM, abuse department abuse@relayon.org wrote:
What year is it?
On 24. May 2021, at 13:53, Logforme m7527@abc.se wrote:
"Fast" -- A router is 'Fast' if it is active, and its bandwidth is either in the top 7/8ths for known active routers or at least 100KB/s.
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 2021-05-25 12:08:34, "John Csuti" postmaster@coolcomputers.info wrote:
I second this. We are in 2021 and a relay is considered fast if it is above 100KB/s...? I don’t think a later dialup service should be considered a fast relay.
100KB/s is about 800Kb/s (https://en.wikipedia.org/wiki/Data-rate_units). I envy the dial up modems you had :)
I agree it is not fast, but is it "fast enough" for Tor's purpose? The Fast flag is (was?) also described as "the router is suitable for high-bandwidth circuits". If I used Tor for high bandwidth stuff I'd hate to get a relay like that in my circuit. Especially if it also acts as a HSDir provider.
Problem is that Tor is mostly used for web browsing and the amount of graphics and videos is increasing. You do not want to surf with >1 mbit at all and maybe there are two users on this relay so we have >0.5 mbit ….
If a first time user is surfing over Tor with 1 mbit he will uninstall it ...
On 25. May 2021, at 16:52, Logforme m7527@abc.se wrote:
On 2021-05-25 12:08:34, "John Csuti" <postmaster@coolcomputers.info mailto:postmaster@coolcomputers.info> wrote:
I second this. We are in 2021 and a relay is considered fast if it is above 100KB/s...? I don’t think a later dialup service should be considered a fast relay.
100KB/s is about 800Kb/s (https://en.wikipedia.org/wiki/Data-rate_units https://en.wikipedia.org/wiki/Data-rate_units). I envy the dial up modems you had :)
I agree it is not fast, but is it "fast enough" for Tor's purpose? The Fast flag is (was?) also described as "the router is suitable for high-bandwidth circuits". If I used Tor for high bandwidth stuff I'd hate to get a relay like that in my circuit. Especially if it also acts as a HSDir provider.
tor-relays mailing list tor-relays@lists.torproject.org mailto:tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Logforme m7527@abc.se wrote:
On 2021-05-22 11:31:12, "Scott Bennett" bennett@sdf.org wrote:
What are all the current requirements for a relay to get aHSDir flag? 96 (97?) hours of uptime and what else? Can someone tell me what my relay, MYCROFTsOtherChild, is missing for a HSDir flag?
First, thank you for your reply.
From the spec: https://github.com/torproject/torspec/blob/master/dir-spec.txt
"HSDir" -- A router is a v2 hidden service directory if it stores and serves v2 hidden service descriptors, has the Stable and Fast flag, and the authority believes that it's been up for at least 96 hours (or the current value of MinUptimeHidServDirectoryV2).
"Fast" -- A router is 'Fast' if it is active, and its bandwidth is either in the top 7/8ths for known active routers or at least 100KB/s.
Up until last night when I had to reboot my system twice a few hours apart, tor had been running for more than 12 days. It had both Fast and Stable flags, but no HSDir flag at any time since it started running.
If you look at the concensus health (https://consensus-health.torproject.org/), go to the bottom and enter your relay nickname you will see what each of the authorities think about your relay.
Thank you for the link. I've bookmarked it for future reference, although the page is a bit difficult to interpret when seen with lynx(1).
moria1 and bastet are very stingy about handing out HSDir. I don't think any of my relays ever has gotten it from them. Of the rest, the authorities that think your relay is "Fast" has also awarded it HSDir. Unfortunately 3 don't think the relay is "Fast" so no HSDir. And with only a 4/9 vote the relay don't get the HSDir flag.
I don't notice any change in the specification you cited above, but I think something *has* changed. Up until about seven months ago, IIRC, it had always gotten the HSDir flag by 97 hours of uptime. Then the flag began to be both assigned and revoked at random times. That continued for a bit over two months, I think, before the flag disappeared forever. I interpret that as meaning that one or more criteria being used by one or more authorities has changed, so I am trying to find out what actually changed in case there is something I can do to return my relay to HSDir service. A further question I would like to raise is why do the Authority relays use different criteria from one to another for the automatic assignment of flags? Should they not be consistent in using the same rules?
Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
On 2021-05-26 08:18:32, "Scott Bennett" bennett@sdf.org wrote:
I interpret that as meaning that one or more criteria being used by one or more authorities has changed,
What I have noticed on my relay is that the "Consensus Weight" is fluctuating. CW is too complicated for my tiny brain but I believe the measurements from the Bandwidth Authorities is involved. The BWAuths are spread around the world and depending on current internet conditions they get different speed values to your relay. But can it cause massive swings in CW? Maybe the BWAuths have changed their measurement technique during the last couple of months?
A further question I would like to raise is why do the Authority relays use different criteria from one to another for the automatic assignment of flags? Should they not be consistent in using the same rules?
I agree that it is confusing that 2 auths don't assign the HSDir flag according to the spec. I have no explanation apart from that AFAIK moria1 is run by Roger Dingledine and I guess he runs a lot of beta and test stuff. moria1 publishes 2 HSDir "Flag Threshold" values (hsdir-wfu and hsdir-tk) that no other auth publishes which leads me to believe moria1 runs another version of the auth software that handles the HSDir flag differently. That don't explain bastet though.
It's fun to speculate :)
Logforme m7527@abc.se wrote:
On 2021-05-26 08:18:32, "Scott Bennett" bennett@sdf.org wrote:
I interpret that as meaning that one or more criteria being used by one or more authorities has changed,
What I have noticed on my relay is that the "Consensus Weight" is fluctuating. CW is too complicated for my tiny brain but I believe the measurements from the Bandwidth Authorities is involved. The BWAuths are spread around the world and depending on current internet conditions they get different speed values to your relay. But can it cause massive swings in CW?
Yes. My relay is on a residential service connection and its "bandwidth" rating from the Authority relays typically oscillates between ~30 and ~120, so proportionally the swings are often fairly wild.
Maybe the BWAuths have changed their measurement technique during the last couple of months?
Well, I first noticed it late last year, IIRC. The measurement technique will, of course, often give deceptive results. For example, if the connection supports ~350 KB/s and the relay has little traffic at the time measurement begins, the result should be fairly close to the true value. OTOH, if the relay is handling 200 KB/s of traffic for other circuits at the time measurement begins, then the result should be at most only ~150 KB/s, which is far from the true value.
A further question I would like to raise is why do the Authority relays use different criteria from one to another for the automatic assignment of flags? Should they not be consistent in using the same rules?
I agree that it is confusing that 2 auths don't assign the HSDir flag according to the spec. I have no explanation apart from that AFAIK moria1 is run by Roger Dingledine and I guess he runs a lot of beta and test stuff. moria1 publishes 2 HSDir "Flag Threshold" values (hsdir-wfu and
Yeah, I saw that, but don't know quite what to make of it.
hsdir-tk) that no other auth publishes which leads me to believe moria1 runs another version of the auth software that handles the HSDir flag differently. That don't explain bastet though.
And it only accounts for two Authority relays, whereas you said five are refusing to assign HSDir to my relay, which, as you pointed out, may depend upon network conditions between those Authority relays and my relay at the time and have nothing at all to do with my relay or how much traffic my relay could handle or might actually be handling at the time.
It's fun to speculate :)
I would rather not be kept in the dark. It should not be like trying to get information on what the criminals who rule over us are up to. The problems outlined above would be mitigated somewhat if the measurements were filtered somehow, which could be as simple a filter as a boxcar moving average. Yes, I know that for many purposes a rectangular window gives lousy results, but for the purpose of understanding relays' capacities over time as having values that usually change slowly if at all a boxcar moving average should be plenty good enough. An exponential moving average would probably also be fine. The point of using a filter for the measurements would be to minimize the temporary interference of transient network conditions affecting the measurement process and corrupting some of the results at some times but not at others. Of course, measurements outside some number of standard deviations from the mean for a relay could be discarded, as well. At present, it is difficult to separate the deficiencies of the measurement method from the network realities in trying to interpret the measurements.
Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
I bennett@sdf.org wrote:
Logforme m7527@abc.se wrote:
On 2021-05-26 08:18:32, "Scott Bennett" bennett@sdf.org wrote:
I interpret that as meaning that one or more criteria being used by one or more authorities has changed,
What I have noticed on my relay is that the "Consensus Weight" is fluctuating. CW is too complicated for my tiny brain but I believe the measurements from the Bandwidth Authorities is involved. The BWAuths are spread around the world and depending on current internet conditions they get different speed values to your relay. But can it cause massive swings in CW?
Yes. My relay is on a residential service connection and its "bandwidth"rating from the Authority relays typically oscillates between ~30 and ~120, so proportionally the swings are often fairly wild.
A new, more extreme problem has emerged in the last two or three days. My relay's "Bandwidth" in the consensus documents dropped suddenly to 14, then 4 for about 18 hours, and finally to 3, where it has remained ever since. This is still the first time I can remember it showing up in the consensus with a value lower than "Bandwidth=20 Unmeasured=1". On Wednesday I took a quick look at the then current consensus file and found the following, regarding single-digit "Bandwidth" values.
Script started on Wed Jun 2 10:36:48 2021 hellas# grep '^w Bandwidth=' /var/db/tor/cached-consensus | wc -l 6777 hellas# grep '^w Bandwidth=.$' /var/db/tor/cached-consensus | wc -l 610 hellas# grep '^w Bandwidth=1$' /var/db/tor/cached-consensus | wc -l 359 hellas# ^1^2 grep '^w Bandwidth=2$' /var/db/tor/cached-consensus | wc -l 53 hellas# ^2^3 grep '^w Bandwidth=3$' /var/db/tor/cached-consensus | wc -l 32 hellas# ^3^4 grep '^w Bandwidth=4$' /var/db/tor/cached-consensus | wc -l 25 hellas# ^4^5 grep '^w Bandwidth=5$' /var/db/tor/cached-consensus | wc -l 31 hellas# ^5^6 grep '^w Bandwidth=6$' /var/db/tor/cached-consensus | wc -l 29 hellas# ^6^7 grep '^w Bandwidth=7$' /var/db/tor/cached-consensus | wc -l 27 hellas# ^7^8 grep '^w Bandwidth=8$' /var/db/tor/cached-consensus | wc -l 32 hellas# ^8^9 grep '^w Bandwidth=9$' /var/db/tor/cached-consensus | wc -l 22 hellas# exit exit
Script done on Wed Jun 2 10:39:46 2021
As you can see, 9% of relays in that consensus had single-digit "Bandwidth" values assigned to them by the Authority relays, and the sizable majority (almost 59%) of those were dumped into the lowest bin ("Bandwidth=1"). I frequently observe my relay chugging along at 330 KB/s to 355 KB/s and occasionally at more than 400 KB/s. It appears that the Authority relays no longer consider that worthwhile, so is there any reason that I should continue to run tor as a relay? Or should I reconfigure it to run as a client only and stop needing to pay atention to it? I started running it around sixteen years ago, but if it's no longer going to be used, maybe I should shut it down instead of letting it just add clutter to the consensus..
Maybe the BWAuths have changed their measurement technique during the last couple of months?
Well, I first noticed it late last year, IIRC. The measurement techniquewill, of course, often give deceptive results. For example, if the connection supports ~350 KB/s and the relay has little traffic at the time measurement begins, the result should be fairly close to the true value. OTOH, if the relay is handling 200 KB/s of traffic for other circuits at the time measurement begins, then the result should be at most only ~150 KB/s, which is far from the true value.
A further question I would like to raise is why do the Authority relays use different criteria from one to another for the automatic assignment of flags? Should they not be consistent in using the same rules?
I agree that it is confusing that 2 auths don't assign the HSDir flag according to the spec. I have no explanation apart from that AFAIK moria1 is run by Roger Dingledine and I guess he runs a lot of beta and test stuff. moria1 publishes 2 HSDir "Flag Threshold" values (hsdir-wfu and
Yeah, I saw that, but don't know quite what to make of it.hsdir-tk) that no other auth publishes which leads me to believe moria1 runs another version of the auth software that handles the HSDir flag differently. That don't explain bastet though.
And it only accounts for two Authority relays, whereas you said five arerefusing to assign HSDir to my relay, which, as you pointed out, may depend upon network conditions between those Authority relays and my relay at the time and have nothing at all to do with my relay or how much traffic my relay could handle or might actually be handling at the time.
It's fun to speculate :)
I would rather not be kept in the dark. It should not be like trying toget information on what the criminals who rule over us are up to. The problems outlined above would be mitigated somewhat if the measurements were filtered somehow, which could be as simple a filter as a boxcar moving average. Yes, I know that for many purposes a rectangular window gives lousy results, but for the purpose of understanding relays' capacities over time as having values that usually change slowly if at all a boxcar moving average should be plenty good enough. An exponential moving average would probably also be fine. The point of using a filter for the measurements would be to minimize the temporary interference of transient network conditions affecting the measurement process and corrupting some of the results at some times but not at others. Of course, measurements outside some number of standard deviations from the mean for a relay could be discarded, as well. At present, it is difficult to separate the deficiencies of the measurement method from the network realities in trying to interpret the measurements.
Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
tor-relays@lists.torproject.org
-
abuse department -
John Csuti -
Logforme -
Scott Bennett