- tor-relays - lists.torproject.org

Abnormal Firewall-States since 0.4.9.10
by ProSecureRelays 08 Jul '26

08 Jul '26

Hi there, I want to report abnormal Firewall States since the update. Since a week or two, (I believe with 0.4.9.10) tor started to excessively use Firewall-States, far beyond what I observed beforehand. In normal operation, I observed about 20k - 45k Firewall States for the relay. Yesterday, before I installed the update, I had 190k Firewall States, related to Tor Relay Traffic. The days before it cycled from 120 - 145k States. Also far more than normal. Today, I see excessive Errors (> 20 Errors/Sek) in my Firewall, relating to use of invalid Firewall States (pf: BAD State..) - all are Tor Related Connections. It would be nice if anyone could have a look, if your connections increased also that much. I also wonder if this might be a type of attack? Regardless of the odd connections, the relay is running well, no CPU peaks and normal memory usage (602MB). Best regards and have a nice weekend! Joker

2 2

GeoIPFile option warning
by krishna e bera 27 Jun '26

27 Jun '26

I am seeing these warnings in Tor's notices.log: Mar 24 09:42:21.000 [notice] Configured to measure directory request statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option. Mar 24 09:42:21.000 [notice] Configured to measure entry node statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option. However the option is set in torrc and i verified the files are at those locations and readable by all: GeoIPFile /usr/local/share/tor/geoip GeoIPv6File /usr/local/share/tor/geoip6 Any hints how i could check whether the warnings are spurious or dump what the running config actually is? I know it is reading the torrc because introducing an error in the file stops it from loading.

2 3

Tor relay doing 400 Mbps up, 50 Mbps down until reboot
by forest-relay-contact＠cryptolab.net 26 Jun '26

26 Jun '26

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. One of my relays, 54C85B97B4A5253483AA269B341C4CCF9328C443, had 400 Mbps up and only 50 Mbps down for several hours. Performance got so bad that could barely SSH in. Unfortunately, I rebooted before doing diagnostics and the problem has not happened since, so I couldn't see if Tor logged asymmetric bandwidth use in its heartbeat. Nothing in the logs indicate anything abnormal. This started on Jun 25th, 12:30 AM UTC and continued until I rebooted at around 4:00 AM UTC. Tor's CPU use was 100% for the duration of this event and the uplink was not saturated. Is this something that has happened before? Could it be some DoS attack? As far as I know, the only way to get Tor to use asymmetric bandwidth is to use it as a directory mirror. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCaj2vuwAKCRAw+TRLM+X4 xhhPAQDqw7+xxZWmOUP00rTmyT1brTFdkTRwEUWWmSdx1njWLAEA8lttz57jLKO7 zZSJyBW02z8rMKds0SpRiP2heVBfFwQ= =ecuY -----END PGP SIGNATURE-----

1 0

Maximizing contribution with own ASN + IPv6 — exit vs guard, IPv6 exit, AS diversity
by lists.torproject.org.broker091＠passmail.net 26 Jun '26

26 Jun '26

Hi all, I run my own ASN and announce my own IPv6 prefix via BGP (with valid RPKI ROAs), plus IPv4. I’d like to contribute to the network in the way that adds the most value, and I’d appreciate guidance from experienced operators. My situation: - ASN: own, prefix announced via BGP (IPv6 /48, IPv4 /28) - Bandwidth available: ~100 Mbit/s, monthly traffic budget: unmetered - Willing to handle abuse complaints: yes - rDNS and abuse contact fully under my control My questions: - Given that AS diversity is scarce, is an exit relay the highest-value use here, or does a high-bandwidth guard already help significantly from an underrepresented AS? - IPv6 exit support seems uncommon — is enabling IPv6Exit on my exit a meaningful gap to fill, and any caveats? - Any recommendations on exit policy and per-IP layout within my prefix to balance reachability and abuse handling? - If I run multiple relays, is the new cryptographic family scheme (FamilyId / tor --keygen-family) the right approach over legacy MyFamily? Happy to share more details. Thanks for any pointers.

3 2

relayor v26.2.0 is released - Goodbye "MyFamily"
by nusenu 23 Jun '26

23 Jun '26

Hi, relayor v26.2.0 is released. https://github.com/nusenu/ansible-relayor/releases/tag/v26.2.0 This release marks the end of "MyFamily" support in relayor. Since all supported tor versions support the Happy Family design there is no reason to continue supporting the old "MyFamily" method to declare relay families. relayor is an ansible role that helps you with automating tor relay operations https://github.com/nusenu/ansible-relayor#main-benefits-for-a-tor-relay-ope… Changes since v26.1.0: - remove MyFamily support: The last tor version that required MyFamily (0.4.8.x) in addition to Happy Family support reached end-of-life on 2026-06-01 - use absolute filter name to fix error "No filter named 'ipaddr'" kind regards, nusenu -- https://nusenu.github.io

6 8

deb.torproject.org-keyring package missing in Ubuntu 26.04 (resolute) repo
by nusenu 23 Jun '26

23 Jun '26

Hi, according to https://support.torproject.org/little-t-tor/getting-started/installing/ users should perform: apt install tor deb.torproject.org-keyring but https://deb.torproject.org/torproject.org/dists/resolute/main/binary-amd64/… unlike https://deb.torproject.org/torproject.org/dists/noble/main/binary-amd64/Pac… the resolute repo does not contain the deb.torproject.org-keyring package. kind regards, nusenu -- https://nusenu.github.io

4 4

Post-Quantum Cryptography in Tor's TLS Layer: Help needed!
by Alexander Hansen Færøy 20 Jun '26

20 Jun '26

Hello Tor Relay Operators, With the arrival of OpenSSL 3.5.0 in 2025, we finally had an important missing piece of infrastructure to start enabling the Tor network to support Post-Quantum Cryptography in the outermost cryptographic layer of the Tor protocol. Since Tor version 0.4.8.17, we have supported the x25519/ML-KEM-768 hybrid handshake in our TLS layer, and we have gradually seen more relays supporting it in the production network. Tor Browser has been built against OpenSSL >= 3.5.0 since (at least) version 13.5.22, released in September 2025, and therefore supports Post-Quantum TLS handshakes today, but it requires that its guard node supports it. We need to give a big shout-out to the OpenSSL Team here to get this out and available to the masses! <3 Since Q3 2025, I've been running some semi-regular scans of the Tor production network to check for TLS cipher suite availability. This work started as part of the first Tor Community Gathering back in October, 2025[1]. The results are as follows: In January, around 28% of the Tor relays supported the Post-Quantum TLS handshake. The scan I did yesterday showed an increase of around 4 percentage points to 32.32%. Out of 9476 scanned relays, 9185 were reachable, 291 were unreachable. Of the 9185 reachable relays, I saw the following distribution of cipher suites: `TLS13_AES_256_GCM_SHA384`: 9023 relays. `TLS13_CHACHA20_POLY1305_SHA256`: 158 relays. `TLS13_AES_128_GCM_SHA256`: 4 relays. For the key exchange groups, I saw the following distribution: `secp256r1`: 6212 relays. `X25519MLKEM768`: 2969 relays. `X25519`: 4 relays. Of the Directory Authorities, 5 of them supported the `X25519MLKEM768` key exchange group during the TLS handshakes. 2969 / 9185 * 100 = 32.32% of relays support the `X25519MLKEM768` cipher suite. This number is a good start, but we should ideally bump it up! You can see the individual results for your relay(s) in the big table available at https://ahf.me/tor-tls-pqc/2026-02-26/ -- entries without a cipher suite or key exchange group were unreachable at the time I ran the scan. These missing entries can be due to a network problem anywhere on the path between my host and yours, so don't get worried if your relay is missing :-) The scanner I used is free software and is available as part of the Network Health Team's Margot tool[2], used for various analysis purposes. Please note that the goal here isn't to enumerate all available cipher suites for each relay, but instead I'm interested in the "strongest" possible cipher suite my custom client can negotiate with each relay. My ask for you as the relay operator community here is as follows: Next time you folks are doing maintenance on your relay(s), please have a look at whether you can upgrade either your packages or underlying software distribution to a version such that you either get a new enough version of OpenSSL (>= 3.5.0), or if you are a LibreSSL user, check whether the LibreSSL project supports the ML-KEM hybrid handshake, and upgrade to that version. It looks like the LibreSSL project is currently working towards supporting the ML-KEM handshake in the next upcoming release[3]. For Debian users, to get a new enough OpenSSL version that supports the PQC TLS handshake, you need to upgrade to (at least) Debian Trixie. For everybody else, it's best to check your respective software distribution's package management system to find the version you need to upgrade to. For Arti users, a licensing issue with the currently available crypto providers in Arti prevented enabling the ML-KEM handshake. Nick, however, has recently been making progress on this matter and has a patch up that is now pending upstream review[4]! :-) If you are excited about exploring different aspects of the Tor ecosystem, talking with other Tor enthusiasts, and you have nothing planned for your weekend in two weeks, I highly encourage you to look into the next Tor Community Gathering in Denmark. The event takes place from 2026-03-13 to 2026-03-15. For more information, check out our website at https://onionize.space/2026/ Thank you all for all the work you do to make Tor better! <3 Cheers, Alex [1]: https://onionize.space/2025/ [2]: https://gitlab.torproject.org/tpo/network-health/margot/ [3]: https://github.com/libressl/portable/blob/a989b7acb9a475fde656e48dbcb38289d… [4]: https://github.com/RustCrypto/rustls-rustcrypto/pull/143 -- Alexander Hansen Færøy

3 6

Re: relay not working 100%
by C. Pe. 17 Jun '26

17 Jun '26

Hi, a very generic advice would be to rather not to throttle the bandwidth to such a low value, but to set a daily(!) quota. A relay running fast, but only a few hours a day is better than a slow relay running all the time. Regards, C Am 2. Juni 2026 um 11:34 schrieb torgnole-relayed via tor-relays <tor-relays(a)lists.torproject.org>: Hi, I'm convinced that tor allows the needed strong anonymity on internet, and I want to contribute. I set up, as a newbie, a middle relay, in february 2026. I rode that a new relay needs to wait something like 80 days before running 100%, the time for the network to check it's liable. It is now running for months, and it is still not running 100%. I have rate-limited the traffic to 500KB/s as for the moment I'm using a low cost VPS. But it appears that it doesn't even reach 70KB/s (it is the best pike in the last days), and even more regrettable, it fell down to 10KB/s or worse since 2-3 days. It used to have 4 flags (Running, Stable, Valid, Fast) but I'm afraid it lose the Rapid flag in the last days. I really don't understand what's going on. Tor logs seem not to show anything helping. Nyx used to show thousand of "inbound" and thousands of "outbound", but rarely "circuits" or anything else (I have to say I understand nearly nothing in Nyx, as I can't find any tutorial explaining it deeply). Nowadays, Nyx shows thousands of inbound, but only a very few outbound, something like 20-30. Server dosen't seem to have failings. Tor version is 0.4.9.8. on linux relay is minotor (B438F0D3E2281C307B459DB2ABDDB48871D06C18) at https://metrics.torproject.org/rs.html#details/B438F0D3E2281C307B459DB2ABDD… VPS is on interserver.net (2TB/month). I can send logs or torrc if needed. So my questions are : what's going on with my relay ? How is it possible it is still not running 100% ? is the bandwidth enough for a middle relay, or should I opt for a bridge ? All the best, _______________________________________________ tor-relays mailing list -- tor-relays(a)lists.torproject.org To unsubscribe send an email to tor-relays-leave(a)lists.torproject.org -- Sent with https://mailfence.com Secure and private email

2 1

Banned by Spamhaus and AWS
by Ole Rydahl 16 Jun '26

16 Jun '26

I have been running a non-exit Tor relay since Snowdon and a The Guardian journalist used Tor. I am doing it using my public ip on my home network. 1Tbyte/day roughly. Starting a year ago I was excluded from the Danish "internal revenue services" - skat.dk. However, using the Tor-browser I could still perform my duties there... Now! From May this year, my ip over and over again got listed at Spamhaus. My gateway only allows my MTA to use the ports 25, 465 and 587. Mysterious! Spamhaus' services are used a lot, so it seriously limits who we can send mails to! Spamhaus claims the following: Why was this IP listed? a.b.c.d has been classified as part of a proxy network. There is a type of malware using this IP that installs a proxy that can be used for nearly anything, including sending spam or stealing customer data. This should be of more concern than a Spamhaus listing, which is a symptom and not the problem. The proxy is installed on a device - usually an Android mobile, firestick, smart doorbell, etc, but also iPads, and Windows computers - that is using your IP to send spam DIRECTLY to the internet via port 25: This is very often the result of third party "free" apps like VPNs, channel unlockers, streaming, etc being installed on someone's personal device, usually a phone. After a throughout search for "infections" - including finding out that some Tor-relays are using port 465 and 587 as or-port - I caved in and stopped my tor-relay. After a few days the miracle happened my ban at Spamhaus was lifted _and_ I was allowed access to skat.dk directly. My conclusions based on my experiments so far are: Spamhaus falsely considers my Tor relay as malware and so does AWS. (Skat.dk are performing their services at AWS - judging from the ip's used.) Hilfe!!! /Ole PS: no PTR-record relates my domain and ip and Google's DNS-services are used. PPS: I have opened a number of tickets at Spamhaus. However, I have not been successful in having a meaningful conversation with them - so far.

6 7

Strange SMTP attempts from my tor relay
by Ole Rydahl 13 Jun '26

13 Jun '26

Hi, I have noticed that my firewall registers connection attempts from my tor-server on port 465 and 587. My relay performs normally, so it appears that they have no significance for the operation. Could somebody please explain the logic behind those SMTP connections? I am a bit puzzled! /Ole Rydahl OS: Fedora Linux 43 (Server Edition), Platform: Tor 0.4.9.8 on Linux

5 6

tor weather account deletion
by Marco 08 Jun '26

08 Jun '26

Hello! Where is the place to request account deletion for TOR weather? I do not need this monitoring service anymore. -- kind regards Marco Muell und Spam bitte an abfalleimer2002(a)stinkedores.dorfdsl.de

1 0

PSA: 0.4.8.x is EOL now, please upgrade!
by Georg Koppen 03 Jun '26

03 Jun '26

Hello! As a reminder for those of you still running any 0.4.8.x Tor version (be it as a relay or a bridge): please upgrade! The 0.4.8.x series is end-of-life since 2 days ago and you should see a respective warning in your Tor log since yesterday. There's currently still 1598 relays on 0.4.8.x, which means roughly 19% of the advertised bandwidth of the network (and 990 bridges). Supported releases in general can be found on the network team wiki.[1] As for the timeline, we plan to reach out to operators still not having upgraded by start of August, and 0.4.8.x is on track to get blocked from the network early September.[2] To follow along the EOL process for 0.4.8.x you can track our work in Gitlab as well.[3] Thanks, Georg [1] https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorRele… [2] We have a ticket for blocking clients by then: https://gitlab.torproject.org/tpo/network-health/team/-/work_items/460 [3] https://gitlab.torproject.org/tpo/network-health/team/-/work_items/453

1 0

[Proposal] OnionCoin: Economic Incentives for Tor Relay Operators
by Gabx 02 Jun '26

02 Jun '26

Hello Tor relay operators, I'm Gab Virebent, a privacy infrastructure developer, and I've been working on an experimental cryptocurrency called OnionCoin that rewards Tor relay operators through a unique consensus mechanism. ## The Problem Running Tor relays costs money (bandwidth, electricity, VPS) but provides no economic return. This leads to: - High node churn (operators drop out) - Centralization risk (40%+ relays on Amazon/OVH/Hetzner) - Difficulty scaling the network sustainably ## OnionCoin's Approach: Proof-of-Relay OnionCoin uses "Proof-of-Contribution" consensus where block rewards are distributed based on: - 40% Stake (anti-Sybil, but logarithmic to reduce whale advantage) - 30% Tor Relay Work (bandwidth relayed for OnionCoin traffic) - 15% Bandwidth contribution - 10% Uptime - 5% Storage Key innovation: **30% of block rewards go directly to relay operators** who route OnionCoin P2P traffic through Tor. ## Node Identity via .onion Addresses Every OnionCoin node runs as a Tor hidden service: - Persistent cryptographic identity (Ed25519) - No IP exposure - Reputation tied to .onion address, not location - Economic stake provides Sybil resistance (min 10 ONC ≈ $100 at launch) ## Verifiable Relay Operator Identity (Critical Security Feature) Current Tor problem: relay operators are pseudonymous with no accountability mechanism. Bad actors can: - Run malicious exit nodes - Disappear and reappear under new identity - Sybil attack the network with multiple relays OnionCoin solution: **Blockchain-based operator identity** - Each relay operator stakes tokens (economic skin in the game) - .onion address = permanent on-chain identity - Reputation history is immutable and public - Bad behavior → stake slashing (Ethereum-style) - Good operators build long-term reputation → earn more rewards This creates: - **Accountability**: Exit node operators can be identified by their blockchain identity - **Sybil resistance**: Running 100 relays requires 100x stake (expensive) - **Quality incentive**: Good operators earn compound rewards over time - **Traceable history**: Community can see how long an operator has been active The .onion address becomes both your Tor identity AND your blockchain wallet. This solves the "who runs this relay?" problem without breaking anonymity (no real names, no IP addresses). ## Current Status - Prototype complete (Rust, MIT license) - Consensus logic implemented with passing tests - Tor integration (arti) planned Q3 2026 - Testnet launch planned Q4 2026 **Repository**: https://git.virebent.art/virebent/onioncoin **Release v0.1.0**: https://git.virebent.art/virebent/onioncoin/releases/tag/v0.1.0 (Signed with YubiKey Ed25519) ## What I'm Looking For 1. **Technical feedback**: Does this approach make sense? What are the risks? 2. **Pilot participants**: 10-50 relay operators interested in testing economic incentives 3. **Research collaboration**: Measure impact on relay uptime/bandwidth/churn ## Key Questions - Would economic incentives improve your relay operation sustainability? - What concerns do you have about mixing crypto with Tor? - What metrics would convince you this improves the Tor network? ## Contact **Email**: gabriel1(a)virebent.art **Website**: https://contact.virebent.art I'm happy to answer technical questions, discuss the consensus design, or hear why this is a terrible idea. All feedback is valuable. Thanks for running relays and keeping Tor alive. Best, Gab Virebent --- P.S. This is NOT an official Tor Project initiative. OnionCoin is an independent experiment to test whether cryptocurrency incentives can improve volunteer network sustainability. -- https://contact.virebent.art https://www.virebent.art https://archives.virebent.art

1 0

Tor Metrics Country Error
by Diyar Ciftci 02 Jun '26

02 Jun '26

Good evening, One of my relays (azadisrvbasic) is being listed on tor metrics as being in the United States of America but it is in the United Kingdom of Gread Britain and Northern Ireland. Could this be corrected please. Kind regards, Diyar Ciftci https://diyarciftci.xyz

3 2

relay not working 100%
by torgnole-relayed 01 Jun '26

01 Jun '26

Hi, I'm convinced that tor allows the needed strong anonymity on internet, and I want to contribute. I set up, as a newbie, a middle relay, in february 2026. I rode that a new relay needs to wait something like 80 days before running 100%, the time for the network to check it's liable. It is now running for months, and it is still not running 100%. I have rate-limited the traffic to 500KB/s as for the moment I'm using a low cost VPS. But it appears that it doesn't even reach 70KB/s (it is the best pike in the last days), and even more regrettable, it fell down to 10KB/s or worse since 2-3 days. It used to have 4 flags (Running, Stable, Valid, Fast) but I'm afraid it lose the Rapid flag in the last days. I really don't understand what's going on. Tor logs seem not to show anything helping. Nyx used to show thousand of "inbound" and thousands of "outbound", but rarely "circuits" or anything else (I have to say I understand nearly nothing in Nyx, as I can't find any tutorial explaining it deeply). Nowadays, Nyx shows thousands of inbound, but only a very few outbound, something like 20-30. Server dosen't seem to have failings. Tor version is 0.4.9.8. on linux relay is minotor (B438F0D3E2281C307B459DB2ABDDB48871D06C18) at https://metrics.torproject.org/rs.html#details/B438F0D3E2281C307B459DB2ABDD… VPS is on interserver.net (2TB/month). I can send logs or torrc if needed. So my questions are : - what's going on with my relay ? How is it possible it is still not running 100% ? - is the bandwidth enough for a middle relay, or should I opt for a bridge ? All the best,

1 0

tor 0.4.8.x reaches end-of-life on 2026-06-01
by nusenu 26 May '26

26 May '26

Hi, this is a reminder that tor version 0.4.8.x reaches end-of-life on 2026-06-01, in one week from now. https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorRele… kind regards, nusenu -- https://nusenu.github.io

1 0

AROI Validation vanished due to ciissversion:3 on 1AEO Metrics
by ProSecureRelays 15 May '26

15 May '26

Hey there, is there any information out regarding the AROI-Status and the trasisition from ciisversion:2 to ciisversion:3? I was proud having it all setup, but then I followed the advice on creating an ed25519 key and added the proof in my github page. The setup was done correctly as far as I can see, however, this led to loosing my AROI Status :'( . I'm happy if someone sees my fault or has a clue what to do now to get the AROI back. Of course it would be easy to just revert the change to the contact info, but the must be a "Go-Live" when the ciisv3 is the desired value? Best regards, Joker P.S. What I also noticed - I have only one relay, but since I configured the ed-key, there was a notice in the tor log that MyFamily Descriptor is still needed aswell. [warn] FamilyId was configured, but MyFamily was not. FamilyId is good, but the Tor network still requires MyFamily while clients are migrating to use family keys instead. As with one relay, I didn't see the benefit, but added the fingerprint as desired with the MyFamily Option. The warning is gone since then. Additionally I also lost my "First-Seen" Date when doing the change to v3. But I heard this is already under investigation. Picture 1: Happy Family Cert is installed and valid. Picture 2: 1AEO stats claims missing ciisversion:2. Picture 3: On the Page from Nusenu (OrNetStats), I still see myself as verified, but the update rate is quite low. This reflects the data before the change.

3 4

Reducing ContactInfo to the family ID level
by nusenu 15 May '26

15 May '26

Hi, since we have a significantly less cumbersome and much less error prone way for tor relay operators to self-declare their relay groups using the Happy Family design I was thinking about whether we actually need ContactInfo at the relay fingerprint level or if we only need it at family ID level? The idea: - only a single relay in a family publishes a ContactInfo that is valid for the entire family benefits: - easiers ContactInfo management for relay operatos not using configuration management, since they only need to update a single config - less redundant information in relay metadata that gets received and distributed by tor directory authority - significantly smaller onionoo details files downsides: - no "backup channel" in case software has Happy Family related issues - like we saw in collector/onionoo - less flexibility you want to have different contacts for different servers I do not expect that rust-based tor relays - that hopefully significantly reduce the number of tor daemons an operator has to run to make use of multi-core CPUs will take over the tor network soon. So this will remain a relevant question for the time being. This topic is limited to relays and not bridges until bridges fully support Happy Family. If there are no strong reasons for relay level ContactInfos I might implement the idea in a minor variation in ansible-relayor: only a single tor instance per server will get a ContactInfo torrc entry. The CIISS spec would also be updated to reflect that. kind regards, nusenu -- https://nusenu.github.io

3 2

What's wrong with geolocation here?
by Dennis Bronk 14 May '26

14 May '26

2 2

Quetzalcoatl relays - Loss of may exits with immediate effect
by Dr Remmiz 13 May '26

13 May '26

Hi, I thought I would write to let you know that I have just lost all my servers - all exit relays, that were part supported and sponsored by rdp.sh. They had very kindly supported and sponsored many of my exit relays over the past several years. Rdp.sh made the decision to drop all my tor exit traffic after repeated and numerous Spamhaus listings. These had recently been forwarded to their upstreams who are now starting to cut their lines. This is with immediate effect as of several hours ago - and instead of 760 exit relays, I shall now be serving only 160 exit relays. I apologize for this disruption in service, but unfortunately it is out of my control. I shall endevour to rebuild some of my server pool, but this may take some time, and finding someone to help sponsor some of the servers I run will likely be difficult, and finding such a good provider as rdp.sh was, will also I believe be difficult. If anyone has any suggestions which may help, I'd be happy to hear them. Thanks for utilizing my server pool over the years. Regards, Zimmer

2 1

Tor-ddos project is now dead
by Chris Enkidu-6 12 May '26

12 May '26

On my last post to the group I mentioned a serious illness. unfortunately I should have said a terminal illness. I probably have a couple of weeks.Since my original post I really had no legitimate offer from anyone to take it over. Just a few time waster conversations that went nowhere. So as of now both tor-ddos and tor-relay-lists are down. Sorry to do this but I have other things to worry about and since only a limited number of people on this list know about it. Others can judge me however they like. Thank you for reading this.

7 7

Re: Reducing ContactInfo to the family ID level
by DTMF dont.track.my.stuff 11 May '26

11 May '26

Hello together, thank you for raising the idea. As far as i understood - defining some kind of data attributes centrally which are unique on family level is causing more struggle in usability even if there could be a slight benefit in reducing the general payload. ////////////////////////////////////////// Single Point of Truth /////// I see a potential down side in the definition of the central point of truth. It could be one relay of the family. But when a single relay is holding that information and that relay disappears or is compromise, the information could be lost/altered. Are there any other location (non-torrc) where that information could be included. Maybe some functionality that could be added by the TOR-Project themselves instead of having workaround with third party specs like CIISS. ////////////////////////////////////////// Levels of relevancy /////// Furthermore i see different levels of relevancy. - FamilyID / HappyFamilyID Level - vServer Level (Multiple Relays) - Relay Fingerprint Level The ContactInfo (according to spec ciissversion:3) can contain also data attributes (hoster, ram, etc..) which are only relevant on Relay Fingerprint Level, or even vServer Level (multiple relays). That means when we will end up in a hydrid-state anyways. All relays would contain their specific (Relay Fingerprint Level ) data attributes in the ContactInfo field - only one relay would have have the additional information. I also like to understand which data attributes of ciissversion:3 you are specifically talking about. @NUSENU Is it only about these - that you want to markup centrally? (1) email: (2) url: (3) proof: Kind regards DTMS - dont track my stuff

1 0

Mangled metrics and more
by Ralph Seichter 08 May '26

08 May '26

I am currently looking at a relay's data on metrics.torproject.org. It is still listed as "first seen 31 days ago" although it has been active since the second half of 2025. Was this not supposed to get fixed for all relays? More importantly, over the last four weeks the amount of traffic routed through this node has dropped sharply, to less than half of what was in March 2026. Consensus weight has dropped significantly as well, which I assume is connected. The relay is online most of the time, with brief interruptions in the form of reboots about once a week. It uses the latest available version of Tor. I do not know what could cause this massive decline in node usage. Perhaps someone here can enlighten me? -Ralph

1 0

OneProvider using now Scaleway AS
by DeuZa 06 May '26

06 May '26

Hi everyone, Until now, I’ve been managing three exit nodes with OneProvider (WIIT), which is generally considered Tor-friendly. But apparently, they’re now working with ScaleWay, and my fourth server in the Netherlands—which I’d just set up—was suspended in less than 24 hours, and I have to pay $100 to the UCPROTECT mafia... I just wanted to let you know that they’re now using AS12876 (Scaleway SAS), which is already well known... As for me, I’m switching to maxko-hosting -- Alain alias DeuZa alias 0x2A

3 5

The tor-realay-list and the tor-ddos project will soon go down
by Chris Enkidu-6 03 May '26

03 May '26

Due to a serious Illness Soon I will not be able to maintain that list anymore. Without that list the Enkidu-6 Tor-DDOS iptable lists will become useless because they all point to the tor-relay-lists. I'm looking at someone established with enough resources to maintain that list and I'd be glad to offer them the source code for how I get that list. You'll just need to associate your PGP key with your Github account and hopefully have at least two separate servers to run the Cron job on. Any dedicated takers please let me know. The whole thing will go down in probably a couple of weeks. Thank you all for taking the time to read my post.

3 2