Hi boldsuck and Marco, Summary (shares = % of consensus weight per position, i.e. how often clients pick a relay there): - If the goal is diversity: keep the guards. AS60729 (Stiftung Erneuerbare Freiheit) already carries ~1 in 5 exit circuits, so one AS operator, upstream or court order can watch or cut that slice of Tor's exits [1][2]. Converting would grow the slice from 18.3% to ~19.7% (+1.4 percentage points) and 185.220.0.0/16 from 21.7% to ~23%; only AS215125 (Church of Cyberology) is larger (21.9%). As guards, the server sits in an AS with ~1% of guard weight, so guard traffic stays spread out. - If the goal is capacity: convert to exits. Exits are the bottleneck, and the 40-relay server would get ~1.7% of exit weight vs ~0.8% of guard and ~0.5% of middle weight today. - Recommendation: get both, diversity and capacity, by moving the server outside AS60729 and 185.220.0.0/16 and running exits there. If moving isn't possible, keep the guards: the capacity gain as exits is small (under a third of today's exit shortfall), while the diversity cost lands on the #2 exit AS. (Disclosure: 1AEO runs only guards/middles. Data: 9 Oct 22:00 UTC.) > We are now only generating ~16%. That ~16% is a 26 Mar snapshot [3]; AS60729 is now at 18.3% [4], shared by four operators. If ForPrivacyNET is boldsuck's, ForPrivacyNET's 40 exits there are ~2% [5]. Reaching 25% would take ~5.6M more exit CW: ~5x the guard server's ~1.1M CW, ~180-200 more relays like ForPrivacyNET's, or ~36 Gbit/s at ForPrivacyNET's current exit CW per Gbit/s. > I believe that adding more Tor exit instances to our AS won't increase our CW or traffic volume. True on a maxed-out server, but not because of the /16: sbws weights relays by measured speed, with no AS or subnet factor [6]. The /16 rule hits guards: Tor picks the exit first, then a guard outside the exit's /16 [7], so ForPrivacyNET's guards sit out the ~22% of exit circuits leaving via 185.220.0.0/16. Marco wrote: > exit bandwidth is much more limited than entry/middle node bandwidth. boldsuck replied: > There's plenty of bandwidth available Both are partly right: exit weight is ~8% short of guard or middle weight, yet exits use only 37.5% of advertised bandwidth vs 50.5% for guard-only relays [8]. 2026 trend [9]: Exits held 36-40% of total weight through May; after large exit operators left (Quetzalcoatl, r0cket) [10], exits hover around one-third. Below that line, Tor uses Guard+Exit relays only as exits, never as guards or middles (Wgd=Wmd=0): 15% of hours in June, 82% in October. Guard-flagged relays fell ~29% since May, but guard-only weight is still ~45% of the total. > stable guards are also needed. Agreed, and ForPrivacyNET's guard server is a stable one: while 57.2% of all Guards reported overload in the Jun-Jul flood [11], the server kept Guard on ~38 of 40 relays on average, and no ForPrivacyNET relay shows overload now [9]. HSDir is the weak spot: 40 of 40 relays Jan-Apr, 12-23 since July, 0 after the 9 Oct upgrade restart (96 h uptime rule). > It's actually a real shame that the abuse-resistant IPs don't handle exit traffic. The strongest argument for flipping, but the guard server's IPs (185.220.101.192-211) share a /24 with ForPrivacyNET's exits, so flipping adds to the concentration above. -- [1] No per-AS or per-family exit cap exists yet; proposal still open: https://gitlab.torproject.org/tpo/core/torspec/-/work_items/103 [2] Roger's rule of thumb for one operator, "5% exit share is fine, and 10% is probably a bit too high": https://lists.torproject.org/mailman3/hyperkitty/list/tor-dev@xxxxxxxxxxxxxxxxxxxx/message/VVJNYNXRCTJBFLJREZEURQOTRYBAIAN2/ [3] https://nusenu.github.io/OrNetStats/#autonomous-systems-by-cw-fraction [4] Onionoo exit_probability: https://onionoo.torproject.org/details?type=relay&running=true&fields=as,as_name,flags,exit_probability,guard_probability,middle_probability ; metrics.1aeo.com counts a few more relays, so shows ~17.4% (AS60729) and ~20.8% (AS215125): https://metrics.1aeo.com/misc/networks-by-exit-consensus-weight/ [5] https://metrics.1aeo.com/as/AS60729/ [6] https://gitlab.torproject.org/tpo/network-health/sbws/-/raw/main/sbws/lib/v3bwfile.py [7] https://spec.torproject.org/path-spec/path-selection-constraints.html ; https://spec.torproject.org/guard-spec/algorithm.html [8] https://metrics.torproject.org/bandwidth-flags.html (5 Oct 2026) [9] Computed from hourly consensuses, Jan 2025-Oct 2026: https://collector.torproject.org/archive/relay-descriptors/consensuses/ ; weight rules: https://spec.torproject.org/dir-spec/computing-consensus.html ; overload: https://onionoo.torproject.org/details?type=relay&running=true&fields=flags,overload_general_timestamp [10] https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@xxxxxxxxxxxxxxxxxxxx/thread/4L7EBLD56PPU4J6CNXR7BXT2M3AKXW3F/ ; https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@xxxxxxxxxxxxxxxxxxxx/thread/WOHPLKCSHYXFTBRZXDENDKJZMBMPLMG5/ [11] https://1aeo.com/blog/circuit-building-dos-blast-radius-june-2026.html Sent from Proton Mail for Android. -------- Original Message -------- On Wednesday, 09/16/26 at 12:16 boldsuck via tor-relays <tor-relays@xxxxxxxxxxxxxxxxxxxx> wrote: On Wednesday, 16 September 2026 17:58:52 CEST Marco Moock via tor-relays wrote: > Is there any problem with that? I don't fully grasp the voodoo behind consensus weight and circuit selection, but the fact that all the relays are in the same /16 subnet plays a role. I believe that adding more Tor exit instances to our AS won't increase our CW or traffic volume. And when I see the current attacks against (Hidden)Onion-Services that are forcing some guards to their knees, stable guards are also needed. With the planned 2-week C-tor release cycle, HSDir's are in for some really tough times. ;-) Background: Why niftybunny split up his AS and servers back then https://gitlab.torproject.org/tpo/core/tor/-/work_items/40007 > I know that it would be much better if exits were more distributed, but > exit bandwidth is much more limited than entry/middle node bandwidth. There's plenty of bandwidth available¹ Advertised and consumed bandwidth of relay: https://metrics.torproject.org/bandwidth-flags.html ¹Especially in our rack or AS. Multiple machines with 2x10G or 2x25G that do the 'R' in tor. net.ipv4.conf.default.forwarding=1 # be a router and fwd v4 packets net.ipv4.conf.all.forwarding=1 # be a router and fwd v4 packets net.ipv6.conf.default.forwarding=1 # be a router and fwd v6 packets net.ipv6.conf.all.forwarding=1 # be a router and fwd v6 packets -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!_______________________________________________ tor-relays mailing list -- tor-relays@xxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx
Attachment:
publickey - tor@1aeo.com - 0x9288289B.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-relays mailing list -- tor-relays@xxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx