So I discovered there are some decent one-liner descriptions written in the dir-spec.txt after all. I propose I yoink these verbatim:
"Authority" if the router is a directory authority.
"BadExit" if the router is believed to be useless as an exit node
(because its ISP censors it, because it is behind a restrictive
proxy, or for some similar reason).
Usually it implies that they are breaking stuff, either maliciously or through misconfiguration.
The most common misconfiguration I have seen is using OpenDNS as a host's nameserver with what I think is the OpenDNS default configuration. Services such as OpenDNS lie to you, under the name of protecting you. The result is for instance getting redirected to ...
It used to be manually assigned by the authority operators, but a couple of years ago I wrote a set of scripts to vote on Named automatically.
We have documented their behavior in dir-spec:
Newer Naming authorities run a script that registers routers
in their mapping files once the routers have been online at
least two weeks, no other router has that ...
Just install Tor on the new server and then copy over your torrc file and the files from the Tor data directory on the old server: https://www.torproject.org/docs/faq.html.en#UpgradeOrMove
The data directory is in different locations depending on your OS. On Linux it's located at: /var/lib/tor. You can skip the "cached-" files, copying them can cause some ...
There's a good break-down of most of these at https://github.com/torproject/torspec/blob/master/dir-spec.txt
It doesn't cover your full list, but the ones it does cover are very clearly explained:
A router is called an ‘Authority’ if the authority generating the
network-status document believes it is an authority
A router ...
This has been described in details in the phase three of The lifecycle of a new relay.
Your new relay has to be stable (up and running for at least 8 days), and have a minimum bandwidth of 250KB/s to receive a guard flag and become an entry node.
Here I quote from Tor spec:
A router is a possible 'Guard' if its Weighted Fractional Uptime is at
From the Tor directory specification (emphasis added):
Named – Directory authority administrators may decide to support name
binding. If they do, then they must maintain a file of
nickname-to-identity-key mappings, and try to keep this file consistent
with other directory authorities. If they don't, they act as clients, and
Currently not every fast exit is also assigned the Guard flag. There was a change reported at TWN of July, 30th 2014:
Once directory authorities have upgraded, they will “assign the Guard flag to the fastest 25% of the network”. Some experiments showed that “for the current network, this results in about 1100 guards, down from 2500.”
If I'm correct the ...
The guard flag is only given to servers that are sufficiently fast and stable [dir-spec]. Stable means being available most of the time.
So yes, if your relay goes down due to hibernation this can result in your relay not getting the guard flag next time it becomes available. Clients will deal with this and just pick new/more guards.
I am not aware of ...
You should get the V2Dir flag simply by publishing a DirPort.
Now, whether or not you publish a directory port depends on many factors, including your accounting/hibernation configuration --- see router.c.
HATEthePLOT, the problem with my relay appears to be corrected. All five active bwauth servers are measuring my relay. The three bwauth servers that were previously egress blocked by my firewall (pfSense) are measuring my relay at a low number, but I think this may be part of the lifecycle of a new relay:
I have run a Tor relay for fifteen years, and I am seeing a similar issue with my relay. For privacy reasons, I apologize in advance for not listing my relay's nickname. According to Tor Metrics, on 2020-02-26 both my relay and your relay began receiving a Consensus Weight of 20 (Additional Flag: Unmeasured). Both of our relays are non-exit, middle-nodes ...
As far as I know it is still possible to do those kind of attacks against the network. However Tor tries to detect bad relays and block them from participating in the network. So there is a high chance that your research doesn't lead to satisfactory results.
Tor has created a Research Safety Board. You can ask them for advice on how to best conduct your ...
A restart does not cause a relay to lose its Guard and HSDir flags. However, a restart that takes way too long, or frequent restarts (more than one per week, say) can cause a relay to lose its stable flag, which will then cause it to lose its Guard and HSDir flags.
Note: OS updates typically do not require restarting. Typically kernel updates are the only ...
The flag StaleDesc was developed throught a proposal. Anyone can send in a proposal to improve the Tor protocol. The specific proposal has the number 293 with the title "Other ways for relays to know when to publish". The implementation was tracked in ticket #26770.
Authorities recognize that a relay descriptor is too old and assign this flag. A relay ...
All relays are suitable for all positions in ciruits. How clients use them depends on their assigned flags, with the exception of exiting traffic which is defined by their chosen exit policies.
So you will potentially act to some users as a guard and others as an intermediary (not always just the "middle") and possibly an exit to others (if you have a ...
This is just a guess:
When you restart a relay, chances are you're going to restart it again soon. Once it's been up for a day or two, you'll probably leave it running.
I have no research to back this up but it seems likely that statistically, restarts come in bunches, rather than being distributed evenly over time.