- tor-relays - lists.torproject.org

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

08 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

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

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

07 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

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 01 Jun '26

01 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 01 Jun '26

01 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 25 May '26

25 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 14 May '26

14 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