[tor-relays] Qualities of a good relay (Sean Saito)
nusenu at openmailbox.org
Wed Jun 24 13:23:08 UTC 2015
-----BEGIN PGP SIGNED MESSAGE-----
> I’m currently working with Dr. Virgil Griffith on Roster, a tor
> project that aims to reward relay operators with good relays.
> Besides the obvious requirements of a good relay (e.g. speed,
> geo-diversity, constant uptime), what qualities make a relay
> valuable to the Tor network and its users?
What are you generally aiming for:
1) a current rating (snapshot)
2) a rating that accumulates over time (like in distributed
1 + 2?
For the rest of this email I'm assuming you go for (2).
Start with what matters most:
- - Reward people for their total pushed traffic.
You could use it as the base value that gets multiplied by other
- - Reward people running relays for a longer time.
(use a relay's age)
- - bandwidth
According to Roger one fast relay is more useful than many small relays.
Use bandwidth history (not advertised bandwidth).
- - Does the exit policy allow rare destination ports? more=better
- - Does the relay's declared family match the effective family?
bigger diff = less good
Once  is implemented this will be really easy to check for.
- - IPv6 connectivity
IPv6 enabled = better
- - Does the torproject want to reward non-announced 'exit_addresses'?
(as defined by onionoo)
- - Has the relay a contactinfo set?
non-empty is better
Certain people will scream "don't force people to disclose their email
addresses or link them to their relays".
I agree, but I'd say it is easy enough to create a new email address
for this purpose and people can also specify arbitrary strings there
(still more valuable than empty contacts if used consistently or
created by following a certain scheme).
- - Reward people running more than one relay.
You could simply use len(effective family) for that.
more relays = better
(until they reach some upper bound sum(CW) value?)
We don't want families to become to big in terms of CW fraction.
In practices you might ignore "the upper bound limit" since it is
unlikely that many ops will hit it anyway. And if more than one
strives for it the competition solves the problem itself.
Patch Level / Tor version / Supported Tor Handshake Types
- - Is the relay running a tor version
- 'recommended' as per consensus
- free from known vulnerabilities (that is unfortunately not a
perfect overlap with 'recommended' as per dir auths)
- the latest version of one of the stable/supported version
- using the latest
Does the torproject want to reward ops for running current alphas? You
probably want some but not all of the relays running alphas so this is
probably not suitable for automatic metrics.
Judging by the latest paper on that topic it is good to start many
guards near your users (in terms of how many ASes need to be
traversed) and many exits near popular destinations, but I'm still
judging by another very simple approach that actually runs counter to
that: starting relays where there are none or few (by CW) is rated as
better than starting a new guard in the country where most users are.
So things to weight in for a quality measurement could be:
- - /16 netblock (by CW fraction, relay count)
- - country/region/city (by CW fraction, relay count (less important
than CW) and flags)
- - AS (by CW fraction, relay count (less important than CW) and flags)
Lower CW fr./ relay count in CC/AS is better.
goal: spread relays across the world
- X added/runs a relay in a country and/or AS that had none or very
- X added/runs an exit relay in a country and/or AS that had none or
very few before (no matter how many non-exits there are)
Then you could "give out" rewards like "X started the first relay in
- - OS (by CW and relay count)
rare OS = better
(until people start to spoof their reported OS ;)
The calculation could look like this:
a new exit started, after 24 hours it did 700MB in a very common
AS/country/netblock, on Linux, with no contactinfo, with a great open
exit policy, running an unsupported tor version, declared+effective
factors (purely invented):
exit relay factor: 2.7
common AS factor: 0.7
common cc factor: 0.8
common netblock factor: 0.6
common OS: 0.9
unsupported tor version: 0.1
family len 0: 1
700 * 2.7 * 0.7 * 0.8 * 0.6 * 0.9 * 0.1 * 1 * ... = X points
after 24 hours the relay is relocated to a rare AS/country/netblock,
changed its OS to OpenBSD and runs the latest tor version, effective
family changed to 2 and did 900MB more.
exit relay factor: 2.7
AS factor: 1.4
cc factor: 1.5
netblock factor: 1.7
OS factor: 2.5
recommended tor version: 1
family len 2: 1.05
points from day 1 +
900 * 2.7 * 1.4 * 1.5 * 1.7 * 2.5 * 1 * 1.05 ...
multipliers will have to be dynamically calculated as the tor network
I would love to see something like this implemented.
I'm really looking forward to your results.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
More information about the tor-relays