[tor-relays] on diversity vs. centralization of Tor network capacity

nusenu nusenu-lists at riseup.net
Sun Jan 5 02:40:00 UTC 2020


> Thanks for your explanation. You are right in all points. But they are
> a bit of theoretical, because we don't have big choice here. Further I
> don't think a big exit is the opposite of our goals, it's just the
> beginning.

I believe they are less theoretical than one might think.

One practical example that comes to mind is when the Tor network was affected
by the Debian openssl bug in 2014 or the removal of outdated relays in October 2019.
 
> Shouldn't the tor software handle the diversity?

Yes I believe it should, but I'm not sure about the exact definition of 'handle'.



My understanding is that you are looking for an authoritative answer to the
question:

What is the acceptable upper limit of a relay operator in terms of fraction of the Tor network capacity (cw fraction)
or an authoritative answer that there is no such limit.

Actually I was always looking forward to see someone test this practically by adding capacity (in a transparent and responsible way)
since I doubt there will be a public authoritative answer that is more specific than what we have
already on the record and that gets actually enforced.

On a side note: 
Should anyone be worried about big publicly declared operators than I would
recommend to turn your eye towards less publicly declared Tor capacity that might be run with less noble intentions.

Having big fractions of the Tor network that is actually attributable to some extend
will actually be beneficial to another side project I'm interested in to reduce the risk of the increasing 
fraction of malicious or at least rather dodgy relay capacity.







-- 
https://mastodon.social/@nusenu
https://twitter.com/nusenu

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20200105/ef37c068/attachment.sig>


More information about the tor-relays mailing list