[tor-relays] Exit Concentration vs Bulk filters?

[Tim Niemeyer]

Hi nusenu

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.

Theoretical

So what can we do to achieve the ideal distributed network? Throttle
all exits to the slowest exit, to get the best diversity? It would be
awesome if we only have exit families with max 0.05% overall capacity
(with each multiple gigabits). But currently we need only 5GBit/s
bandwidth and 2 office computers for ~7%. That's ridiculous, it's year
2020!

Diversity 

Shouldn't the tor software handle the diversity? So what if an
intelligence adds an exits with ~100 GBit/s? Will it gain all exit
traffic? And if so, is that a real problem for a tor user (which uses
end to end authentication etc)? And if so, why don't we change the
software?

Am Samstag, den 04.01.2020, 11:44 +0000 schrieb nusenu:
> > I never heard a real technical reason to avoid
> > high
concentration of Tor exit capacity. 
>
> In short, you don't want to make the tor network depend on 1-2 or 10
> but many.
> So if a few operators disappear the network remains functional and
> available
> and is generally harder to attack.

Maybe my point wasn't clear.. my mistake.

While the tor network currently depends on some high exit capacity
families, it's not the mistake of them. Instead it's the mistake of all
others which don't provide exit capacity.

The right way besides throttling

The only right solution can be to encourage others to add more exit
capacity. So instead to throttle the available resources and blame the
people behind them, we should say a big "thank you" to all people and
orgs that provide us with exit resources. Besides the resources, these
providers handle all the troubles with police and other annoying things
and that is the really hard work of an exit relay.

We need all exits, whether high or small capacity. Don't we?

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20200104/759685f0/attachment.sig>