Hi list,

First of all, why is email verification not used as an additional method for making family settings?
(Additional meaning that operators could choose to either verify their mail address or write all their
relays fingerprints in the config.)
Wouldn't it be more convenient to verify the address once and then automatically adding every
relay with the same contact to that family. And maybe notify the operators so that they can claim
the new relays to be "not theirs" in case somebody else pretended to be that operator.


Secondly, how about adding something to the configuration of relays with the purpose of showing
inheritance from other configurations in order to make bad relay detection easier?

Imagine the guide for running secure relays changed regularly in a way that makes the 'version' of
torrc distinguishable by looking at the settings. This could be easily achieved by adding a varying
additional field in the settings.
The value of the field is not important, but the name of the field should change in an unpredictable
way. Somebody would keep the chronology of old suggested configurations.
This way it can be used like non coding DNA for m/paternity testing.

The desired effect:
If a good operator sets up a new relay for the very first time, the person reads the guide and
copies this extra line which adds very little extra effort. If the good operator sets up many relays
he can automate that and always use the same settings because the good operator doesn't need to
hide she is running multiple relays. (This does not replace family settings.)
If a bad operator sets up many relays over a long period of time, the bad operator cannot automate
this process as the relays would stand out by using outdated recommendations that a new operator
would not have found online and that can be related to the other relays of the same operator.

The extra information should not de-anonymize relay operators because the time when they setup
their relay is usually available through the first seen field and family settings are public available too.

The obvious difficulty is, for it to work, the tor relay guide containing the altering information should
be so well-written that the majority of new relay operators always choose to follow this rather than
other guides that don't change. And it maybe requires different error handling.

Anyway this example should only illustrate the basic concept. 
I don't know if that option has been discussed so far.