On Sun, 26 Jul 2015 01:35:10 +0000 Yawning Angel yawning@schwanenlied.me wrote:
The relay identity key is sensitive cryptographic material. Sharing it means the private key is compromised and is an attempt to subvert:
- The bandwidth scanning process. The consensus weight is the relay's capacity relative to other nodes in the network which will change and should be reset if the location of the relay changes.
Yeah perhaps I should have mentioned that people should request one if they are absolutely certain that their server is capable of handling at least 50+50 Mbit of bandwidth.
- The flag assignment process. A random person should not get the Guard or Stable flag quickly.
...and that they expect it to have a certain degree of stability. :)
Sure this is a shortcut of sorts, and it's one that you should take if you believe you can "vouch" for things like stability and b/w capacity you can provide, and want to "skip the formalities" a bit so to say, and start contributing to the maximum extent possible immediately; surely nobody likes paying for idle servers.
Either way you won't do much damage even if any of this ends up being false, as the consensus weight and the stable status will drop more rapidly than they are gathered if your node can't maintain them.
Yes, in an ideal world the bwauths will scan new relays faster.
Meanwhile in reality the outcome is often [1].
A fun task for someone who likes messing with consensus documents and descriptors would be to write a script to measure IP address churn for relays while the relay identity remains constant (either legitimately eg: being on a dynamic IP, person had to move the rack the relay was on, or through key compromise/derp).
I do this extensively on my relays, as one VPS or dedicated server expires, gets terminated or canceled for various reasons, a different one takes its place, inheriting the same identity. If I had to always wait for new relays to spin up from scratch in each case, a lot of the time I probably wouldn't even bother.
Running 20 relays in a declared family at the moment, together comprising about 1.8% of aggregate Tor bandwidth, however due to financial reasons I will have to shut down most of these over the coming weeks and months; so I see little difference if the next machine inheriting a particular identity this time will be managed and paid for by someone else and not by me. Just throwing these away seemed like a waste.
[1] https://lists.torproject.org/pipermail/tor-relays/2015-June/007203.html