- tor-relays - lists.torproject.org

OT: Tor Control Protokoll ADD_ONION
by boldsuck 25 Jul '24

25 Jul '24

Hi, In the control-spec https://spec.torproject.org/control-spec/commands.html#add_onion or https://github.com/torproject/torspec/blob/main/control-spec.txt#L1777 The ADD_ONION 'Flag' include Hidden Service options: MaxStreamsCloseCircuit and MaxStreams, among others. We also want to use the PoWDefenses and IntroDoSDefense parameters. Is the control-spec outdated or is it not possible to set these parameters via Flag? -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

1 0

OT: Tor-Metrics for Hidden Services
by boldsuck 25 Jul '24

25 Jul '24

Does anyone know where I can find information about the MetricsPort output? In particular, hs introduction point and rendezvous point circ build time bucket. What do the numbers represent le="1000.00" - le="6000.00" suggested-effort value Do I understand correctly that the value goes from 0-1000? https://spec.torproject.org/hspow-spec/common-protocol.html#client-limits # HELP tor_hs_intro_circ_build_time The introduction circuit build time in milliseconds # TYPE tor_hs_intro_circ_build_time histogram tor_hs_intro_circ_build_time_bucket{onion="somerandomonionaddress",le="1000.00"} 128 tor_hs_intro_circ_build_time_bucket{onion="somerandomonionaddress",le="5000.00"} 205 tor_hs_intro_circ_build_time_bucket{onion="somerandomonionaddress",le="10000.00"} 205 tor_hs_intro_circ_build_time_bucket{onion="somerandomonionaddress",le="30000.00"} 205 tor_hs_intro_circ_build_time_bucket{onion="somerandomonionaddress",le="60000.00"} 205 tor_hs_intro_circ_build_time_bucket{onion="somerandomonionaddress",le="+Inf"} 205 tor_hs_intro_circ_build_time_sum{onion="somerandomonionaddress"} 210297 tor_hs_intro_circ_build_time_count{onion="somerandomonionaddress"} 205 # HELP tor_hs_rend_circ_build_time The rendezvous circuit build time in milliseconds # TYPE tor_hs_rend_circ_build_time histogram tor_hs_rend_circ_build_time_bucket{onion="somerandomonionaddress",le="1000.00"} 14275 tor_hs_rend_circ_build_time_bucket{onion="somerandomonionaddress",le="5000.00"} 24060 tor_hs_rend_circ_build_time_bucket{onion="somerandomonionaddress",le="10000.00"} 24095 tor_hs_rend_circ_build_time_bucket{onion="somerandomonionaddress",le="30000.00"} 24096 tor_hs_rend_circ_build_time_bucket{onion="somerandomonionaddress",le="60000.00"} 24096 tor_hs_rend_circ_build_time_bucket{onion="somerandomonionaddress",le="+Inf"} 24096 tor_hs_rend_circ_build_time_sum{onion="somerandomonionaddress"} 25308501 tor_hs_rend_circ_build_time_count{onion="somerandomonionaddress"} 24096 # HELP tor_hs_pow_suggested_effort Suggested effort for requests with a proof of work client puzzle # TYPE tor_hs_pow_suggested_effort gauge tor_hs_pow_suggested_effort{onion="somerandomonionaddress"} 1 -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

1 0

bridges
by Earl M. Northern 23 Jul '24

23 Jul '24

obfs4 49.12.224.203:8001 8E6B9FB7914E9ECA1BD271AB33FF8D868EEA6DE5 cert=zZcPgBgVxKhmhlo2M0yLKTGkxDnSXl2372d5E0POqVMpmzu0tsIlegXR4OolUDudfD+7CA iat-mode=0 obfs4 94.131.97.25:50703 4DF9058B33F6D3E72A4397B09A40503AF51DAA04 cert=HXw+QS4SVjB9/oekpZSQcGDyoNxrp8a/mOQ14qSAuLPp5b9h6H1p4VB8008VHWPwj7vBJA iat-mode=0 obfs4 88.198.12.66:1812 7611DAC3C59A43322D774400F57FDA4D2AC0EEE2 cert=Qo94bPwOyZ9gRUJkyXFV5AhLXOPa+Ilgt8gQ+5a2Mw2NSzzvEY00FhWfeCnfSGs81CYLZA iat-mode=0

3 2

tor middle relay issue
by theyarewatching 22 Jul '24

22 Jul '24

I have had two ubuntu based tor middle relays fail.I am using a proxmox server and have tried both ubuntu server 20.04 and a fresh download of ubuntu 24.04. I follow the tor website install instructions. The results show the same no matter what version of ubuntu. "failed to start Tor(a)default.service. This is the same result with the original install and a brand new VM install on Proxmox. Any input would be greatly appreciated Thank you SDS

1 0

OOM at relay with small RAM if statistic configs are enabled
by Toralf Förster 14 Jul '24

14 Jul '24

Regarding to https://gitlab.torproject.org/tpo/core/tor/-/issues/40958 I do wonder if that issue happened for stable Tor versions too - I do run myself git HEAD only. FWIW at my bare metal relay the RAM consumption per Tor process decreased by about 0.7 GiB. -- Toralf

1 0

Hardware sizing for physical exit node
by Osservatorio Nessuno 11 Jul '24

11 Jul '24

Hi everyone, we are planning to get some hardware to run a physical Tor exit node, starting with a 1Gbps dedicated, unmetered uplink (10Gbps downlink). We will also route a /24 on it, so we will have large availability of addresses to run multiple instances. We have been running a few exit nodes so far, but never on our own hardware. Which is the bandwith limit per core/Tore instance? Or what can we expect to be the bottleneck? Due to some other requirements we need for some experiments (SFP ports, coreboot support, etc) we can mainly choose between these 2 CPUs: Intel i5-1235U Intel i7-1255U The cost between the two models is significant enough in our case to pick the i7 only if it's really useful. In both cases with 32GB of DDR5 RAM (we can max to 64 if needed, but is it?). Should this allow us to saturate the uplink? To summarize, with this bandwith, this hardware and a /24 how many Tor exit nodes should be ideal to run considering that each of them could have their own address? Thanks!

5 4

Seeking Advice on Running Multiple Tor Relays or A Bridge
by Alessandro Greco 07 Jul '24

07 Jul '24

Hello Tor Community, I have some experience running a Tor relay, and I am now interested in setting up another one. I plan to do this using my home internet connection, which is an FTTH line with bandwidth up to 2 Gbps. I have read that it is possible to run multiple relays on the same node, but I am unsure how to configure this. Additionally, I am curious about what would be most beneficial for the Tor network today: a highly resilient bridge or multiple relays managed from the same node? Is it feasible to operate both at the same time? This is probably not the best idea since the bridge's IP address would be public, right? I am looking for guidance on the best course of action to support the Tor community. Thank you in advance for your assistance,Aleff.

4 5

Re: [tor-relays] Seeking Advice on Running Multiple Tor Relays or A Bridge
by 0tpcqovw＠duck.com 07 Jul '24

07 Jul '24

For what it's worth, in addition to my Tor Bridge Relay, I also run two Snowflake Proxies on my home LAN. Malcolm On 6 July 2024 19:14:23 GMT-03:00, "Gary C. New via tor-relays" <tor-relays_at_lists.torproject.org_0tpcqovw(a)duck.com> wrote: >Alessandro, > >I would recommend running bridges (opposed to relays) on a home network to avoid browing issues with your bank, news, etc as these entities often block Tor relays and not bridges. >Respectfully, > >Gary > > On Saturday, July 6, 2024, 3:07:52 PM MDT, Roger Dingledine <arma(a)torproject.org> wrote: > > On Sat, Jul 06, 2024 at 06:34:37PM +0000, Alessandro Greco via tor-relays wrote: >> I have some experience running a Tor relay, and I am now interested in setting up another one. I plan to do this using my home internet connection, which is an FTTH line with bandwidth up to 2 Gbps. > >Thanks for running a relay! > >> I have read that it is possible to run multiple relays on the same node, but I am unsure how to configure this. > >If you're using the tor deb (e.g. on Debian or Ubuntu), it comes with >a tool to set up multiple tors. "man tor-instance-create" to get started. > >There is also the possibility of using the fancy automated >deployment tools that some of the bigger relay operators here >use, which probably only makes sense if you are already familiar >with these automation tools (a popular one based on ansible: >https://github.com/nusenu/ansible-relayor ). > >In either case, make sure you have enough memory in your system to >handle each Tor relay: relays can use 1 or 2 gigabytes of memory each >during normal operation, but when the network is under load it can go >much higher than that. > >> Additionally, I am curious about what would be most beneficial for the Tor network today: a highly resilient bridge or multiple relays managed from the same node? > >If you have the bandwidth (which it sounds like you do), the multiple >fast relays will be much more useful to the network. > >See also https://2019.www.torproject.org/docs/faq#RelayOrBridge > >> Is it feasible to operate both at the same time? This is probably not the best idea since the bridge's IP address would be public, right? > >It is technically possible yes, but as you say, having a public relay >on the IP address will undermine the effectiveness of your bridge on >that IP address. > >The same logic is also why we don't recommend running two different >kinds of bridges on a single IP address: if one of them gets discovered >and the censor blocks by IP address, then the other will stop working too. > >> I am looking for guidance on the best course of action to support the Tor community. >> Thank you in advance for your assistance,Aleff. > >Thanks for wanting to help! > >--Roger > >_______________________________________________ >tor-relays mailing list >tor-relays(a)lists.torproject.org >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

1 0

Quick Assist Technology and Tor?
by mail＠nothingtohide.nl 25 Jun '24

25 Jun '24

Hi o/, During the Tor Operator Meetup I asked about Quick Assist Technology (QAT) support and was asked to bring it to the tor-relays mailing list so the network team can take a look at the question. In 2025 we're going to build one or more new servers and we're looking in to optimizing the performance per watt ratio since some of our current servers are rather power hungry ;-). I'm wondering whether QAT works for Tor to offload compression, hashing and encryption. In theory, looking at the nature of Tor (a lot encryption), this could result in a huge performance boost of 100-300% (based on other hashing, cryptographic and compression offload benchmarks). Support for QAT also has improved considerably over the years so many programs/workloads already work nicely with it, but I'm not sure about Tor. It looks like Tor uses [1] RSA-1024, AES-CBC, AES-CTR, Curve25519, Ed25519, SHA1, AES256, AES3-256. Most (no Curve- and Ed25519) should in theory also work with QAT [2] (although I guess only a few would impact performance significantly when offloaded). But the question is: does it really work? If not, what would be needed to make it work? Are there Tor operators who already utilize QAT? Does the Network Team have some insight in to this? :) Some of the potential advantages when comparing a similar amount of traffic: - Lower power consumption (much cheaper to run in expensive European countries). - Less CPU cycles required (= cheaper CPUs). - Less heat/cooling required (easier to put in distribution boxes and other small places). - Smaller physical footprint (easier to put in distribution boxes and other small places). - Alleviates some of the issues and challenges caused by Tor's single threaded architecture by effectively increasing bandwidth per CPU core considerably. With regards, tornth [1] https://spec.torproject.org/tor-spec/preliminaries.html?highlight=cipher#ci… [2] https://www.intel.com/content/www/us/en/support/articles/000093843/technolo…

4 4

Why should we avoid adding bridges fingerprints in MyFamily?
by Edward Cage 24 Jun '24

24 Jun '24

Hi all, Quick question about the fingerprints of our bridges. It's clearly written in torrc that we should not include them in MyFamily. I don't well understand why, especially because: - Every bridge, and their fingerprints, are publicly listed on Tor Metrics; - The contact email is disclosed for each of them, and it allows our bridges and relays to be easily linked to a same operator. (or should we use a different email address for each bridge?) Best regards

2 1

Next Tor Relay Operator Meetup - June 22, 2024 at 19 UTC
by gus 23 Jun '24

23 Jun '24

Hello, Please save the date: the next Tor Relay Operator will happen Saturday, June 22 at 19 UTC! We're still working on the agenda for this meetup, however feel free to add your topics directly to this pad or just reply to the mailing list: https://pad.riseup.net/p/tor-relayop-june22-meetup-keep ## Agenda 1. Announcements - EOL work: bridges running 0.4.7.x were rejected from the network: https://lists.torproject.org/pipermail/tor-relays/2024-June/021678.html - Snowflake extension issue: https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/142 - Farahavar directory authority is back! https://gitlab.torproject.org/tpo/core/tor/-/commit/39ba9ce0d7913ceb53fc1f1… 2. Network Health - Reports of relays ddos & ongoing onion services overload 3. Policy and proposals discussion: - https://gitlab.torproject.org/tpo/community/policies/-/issues/22 4. Next events - Tor presence at DEFCON, Las Vegas - Summer break & next Tor Relay Operator online meetup 5. Questions & Answers <add your questions here> ## How to join us Meetup details - Room link: https://tor.meet.coop/gus-og0-x74-dzn - When: June 22, 19.00 UTC - Duration: 60 to 90 minutes - Tor Code of Conduct: https://community.torproject.org/policies/code_of_conduct/ - Registration: No need for a registration or anything else, just use the room-linkabove. We will open the room 10 minutes before. cheers, Gus -- The Tor Project Community Team Lead

2 2

Tor non-exit list
by Carsten Otto 22 Jun '24

22 Jun '24

Hi Dan, For reference: https://www.dan.me.uk/dnsbl https://www.dan.me.uk/tornodes https://www.dan.me.uk/torlist/?full First of all, thank you for your tools and other contributions. The mere fact that your DNS blocklists are used by countless vendors should be a compliment in itself, and I'd be happy to have that much impact with my own projects. As you already state on your own site ("Please think carefully before choosing to use this list for blocking purposes"), your non-exit Tor relay list is a bit unusual. I'm running ftp.halifax.rwth-aachen.de, a major file mirror serving around 30 TByte of data at around 4 GBit/sec (on average). Recently, we added Tor relays on the same IP address, and your list correctly picked this up (137.226.34.46). Now, I'm writing as this caused quite a lot of mayhem. Several "security" appliance vendors didn't "think carefully" before adding your non-exit list to their devices. Among those are Arbor Prevail, Check Point, Ubiquiti (UniFi) - feel free to search for "ET TOR Known Tor Relay/Router (Not Exit) Node" to see the effect of this. In addition to private users making use of such devices, several banks/corporations/institutions started blocking our IP address, causing some frustration with us and their admins, as their Linux/Jenkins/... updates suddenly stopped working. As you might have guessed, changing "security" configurations (even if they may be wrong or questionable) is quite a challenge, and in some cases the (motivated) admins weren't unable to fix this issue on their end. As you seem to be well aware of what Tor is, what an exit relay does and what a non-exit relay does, would you be willing to retire the non-exit blocklist (at least the part that can be used for automated blocks)? I'd argue that the current setup does more harm than good (assuming you agree that Tor is a good thing in general). I'd be happy to discuss pros and cons, but ultimately that's your decision to make. Thanks Carsten -- Dr. Carsten Otto http://verify.rwth-aachen.de/otto/

5 6

Relay usage dropped 9x when enabling UFW. What UFW rules do other relay operators enact?
by admin＠likogan.dev 20 Jun '24

20 Jun '24

Hello all, I'm running relay 292FCACE773DC259B799914A23BE65A6A6178E8F and have noticed traffic drops when enabling UFW. Around 2024-01-15, I enabled UFW on this server. I noticed a 9x drop in traffic (10.88M -> 1.708M), and coughed it up to relay weirdness. This is about when my relays Guard status would randomly drop every few weeks. I finally got fed up with this huge drop in traffic on 2024-06-11 and was about to reinstall my server OS. This is when I decided to disable UFW and found that my traffic went back over a few days (2.215M -> 8.948M). Here are my tor-related UFW rules; To Action From -- ------ ---- [ 3] 9001 ALLOW IN Anywhere [11] 9001 (v6) ALLOW IN Anywhere (v6) I'm really confused how UFW firewalled most, but not all, of my relays traffic. What UFW rules do other relay operators enact? Thanks, Likogan

3 2

Re: [tor-relays] Relay usage dropped 9x when enabling UFW. What UFW rules > do other relay operators enact?
by zorc 19 Jun '24

19 Jun '24

Hi Likogan, > What UFW rules do other relay operators enact? I'm running 4CEAFCE5841C0DAE30164B4F59452F7F4D818A67 on Linux Mint 21.3 (should be close to Ubuntu Jammy) with UFW enabled, and don't have any issues. I have the same two rules for Tor as you do. I can imagine three things: 1. To me it looks like you have other rules before your Tor rules. Are any of them rate limiting? 2. I don't run an exit node, so I don't know how UFW would behave in that case. 3. Do you have logging rules? I once had issues with my router running out of CPU due to some logging rules being triggered by Tor-related traffic (potentially malicious). Maybe UFW could achieve something similar? Hope that helps. Cheers, zorc

1 0

Which choice is better
by theyarewatching 18 Jun '24

18 Jun '24

Hello all, I have been operating 8 middle relays for several months and due to my internet service limitations I have to make some changes. I have cox panorama service in the USA and for the most part it works well. My dilemma is with all of my VMs running and relays etc it tends to overload my connection. This causes my household streaming to drop off and my fam is not happy with me. The question I have for you is the following. Which is preferable; four middle relays running with no limits or eight middle relays with speed limits? I am asking which would be better for the network? I'll await your answers Thanks for the input SDS

2 1

Relay migration
by Eldalië 17 Jun '24

17 Jun '24

Hello everyone. I have to move somewhere else a a (middle) relay I have been running for a few years. It will be down for 2-4 weeks, then be back online in a different location, with different ISP, at better speed. But it will run on the same hardware and software. Should I keep the same keys, or start from scratch? -- Eldalië My private key is attached. Please, use it and provide me yours!

5 6

Disable instance
by mailinglistreader＠riseup.net 14 Jun '24

14 Jun '24

I ran into a problem with instances. On some of my servers I noticed that the performance decreased when running a node for each CPU (more than 2 virtual CPUs on those systems). So I disabled the newest node on those systems with "systemctl disable tor(a)instancename.default" without getting a output. But after an TOR update or reboot of the system, that instance is up again. Is it enough to (re)move the instance folders in /etc/tor/instances and /var/run/tor-instances, or do I have to look in another location as well?

2 1

[proposal] Guidelines for sustainability and incentivization proposals in the Tor Community
by gus 13 Jun '24

13 Jun '24

Dear relay operators, We invite all Tor relay operators to join the discussion about the "Guidelines for sustainability and incentivization proposals in the Tor Community". For your convenience, the proposal text is included below. If you prefer reading the markdown version, you can find the latest draft in the Community policy repository on Gitlab[1]. Similar to the contact info proposal discussion[2], the guideline proposal will follow the established process described in our meta proposal policy[3]. [1] https://gitlab.torproject.org/tpo/community/policies/-/issues/22 [2] https://gitlab.torproject.org/tpo/community/policies/-/issues/17 [3] https://community.torproject.org/policies/relays/001-community-relay-operat… """ ``` * Filename: xxx-guidelines-for-sustainability-and-incentivization-proposals.md * Title: Guidelines for sustainability and incentivization proposals in the Tor Community * Author: gus - gus(a)torproject.org * Created: 2024-06-11 * Status: Open ``` ## Overview This document outlines guidelines for sustainability and incentivization proposals for the Tor community. The guidelines are designed to prevent exploitative and abusive practices and preserve the volunteer-driven nature of the Tor community. We want to ensure that Tor remains an open and inclusive network and community for all users and contributors, and, at the same time, we want to encourage proposals to support and sustain the Tor network. ## Motivation The Tor community is shaped and driven by the principles outlined in the Tor Project's [Social Contract](https://community.torproject.org/policies/social_contract/), [Code of Conduct](https://community.torproject.org/policies/code_of_conduct/), and other policies such as the [Expectations for Relay Operators](https://community.torproject.org/policies/relays/expectations-fo…. The Tor network is powered by a diverse community of operators, also known as relay or network operators. The Tor network is the backbone of Tor and relies on the collaboration and support of thousands of volunteers, who donate their resources and bandwidth to ensure that users all around the world can access the free and open internet in a secure and anonymous way. Managing relays can create extra costs and expenses, for example, the cost of bandwidth, new hardware, dedicated IPv4 addresses, and, when operating exit nodes, in a few cases, legal costs. While some volunteers are able to cover the operational costs by themselves or by associating with others friends, growing the Tor network in a diverse and sustainable way is one of the open challenges for non-profit networks. There are multiple and different approaches to achieve this goal. As a non-profit organization, we seek proposals for sustainability and incentivization that may include financial resources, yet our primary goal is not to transform our community into a for-profit business. Shifting from a collaborative framework to a for-profit business model can impact the dynamics of the Tor Community and introduce new legal challenges. While many countries permit the operation of a Tor relay, shifting to a paid or for-profit service model could reclassify the network as a "commercial service provider", subjecting it to a different set of legal requirements and obligations. You can read more about the problem of for-profit models on the Tor blog post: [Safeguarding the Tor network: our commitment to network health and supporting relay operators](https://blog.torproject.org/tor-network-community-health-update/). ### Sustainability models over for-profit models It's clear for the Tor Project that sustainability proposals, including both financial and non-financial rewards, must enhance collaboration and help the community to grow, rather than marginalize contributors and undermine the volunteer-driven nature of the network and the Tor community. The proposals must respect and maintain the Tor relay operator community diversity while aligning with the goals and mission of the Tor Project. Incentivization proposal refers to a plan, scheme or strategy designed to encourage specific behaviors or actions through various incentives such as swag, gamification, or virtual points (e.g. Reddit's karma). Acceptable incentives primarily encompass non-financial rewards that recognize and motivate the community's contributions. Examples of such incentives include public acknowledgment, rewarding operators with [Tor swag](https://community.torproject.org/relay/community-resources/swag/), highlighting their contribution on Tor social media channels, inviting operators to the Tor Project in-person events, and so on. These incentives are designed to value the community's commitment without introducing monetary motivation, which could potentially erode the collaborative nature of volunteer participation. They aim to reinforce the intrinsic motivation of contributors, with a sense of belonging and achievement, while avoiding the complexities and potential conflicts associated with financial compensation. The guidelines described in this document ensure that sustainability and incentivization proposals are developed and managed transparently, fairly, and in the best interest of the Tor community, free from undue influence or bias. ## Guidelines for sustainability and incentivization proposals As outlined above, contributors willing to work on such proposals, must follow these guidelines: [Table of Content] 1. Policy compliance 2. Preservation of the Tor Community collaboration and its spirit 3. Innovation must preserve and respect the Tor Community diversity 4. Regulation of fundraising campaigns, donations and reward systems 5. No fee or "donation" for participation or to "unlock" rewards 6. Fraud, cheating, and abuse prevention in Tor incentives 7. Conflict of Interest Policy 8. Reporting scammers and avoiding risks 9. Frequently Asked Questions ### 1. Policy compliance - Any sustainability or incentivization proposal for the Tor network and the relay operator community, must comply and adhere to the Tor Project's [Community Policies](https://community.torproject.org/policies), including but not limited to the Tor Project Code of Conduct, Social Contract, Statement of Values and must follow the process described on: [Process for new policies and proposals for the Tor relay operator community](https://community.torproject.org/policies/relays/001-community-r…. - Proposals and projects must follow and comply with the Tor Project [Trademark](https://www.torproject.org/about/trademark/) policy. Don't use Tor in your product name or domain name. Creating a new brand that incorporates the Tor brand is likely to lead to confusion, and commercial confusion is a sign of trademark infringement. - Incentivization proposals or schemes of any nature that jeopardize this policy will lead to the removal of the authors and collaborators from the Tor network and the Tor Community. ### 2. Preservation of the Tor Community collaboration and its spirit Proposals must incentivize collaboration and sustainability of the Tor Community: - The Tor network operates as a non-profit and a collaborative community. - Rewards and incentivization proposals whether they involve monetary elements or not (like gamification strategies), must not disrupt the collaborative foundation of the Tor operator community. - The goal is to build a trusted Tor relay operator community, dedicated to defend and promote the Tor mission, rather than motivated and driven by individual financial profit. - For example, simplifying the process to facilitate the creation of local Tor relay associations is a proposal that respects and preserves the Tor Community. ### 3. Innovation must preserve and respect the Tor Community diversity - We encourage innovative collaboration methods that promote inclusivity, diversity, and the growth of the Tor network and our Community of operators. - These methods should not put our users and contributors at risk or be in detriment of our core values. - We do not believe that there is only one model or a single path to incentivize or sustain relay operations. We believe that Tor relay operators and contributors have different motivations and sustainability proposals must ensure that they are preserving and respecting the Tor Community diversity. ### 4. Regulation of fundraising campaigns, donations and reward systems It is crucial to draw a clear distinction between genuine donations made in support of the Tor Project's mission and exploitative financial schemes (aka pyramid or Ponzi schemes) aimed solely at profiting from the network's resources without contributing to the health of the Tor network and advancing Tor's mission. For instance, relay associations conducting their fundraising activities, such as selling t-shirts, are definitely aligned with the mission of the Tor Project and this policy. In this context, proposals involving any kind of reward or financial systems, such as tokens or cryptocurrencies, must seek and obtain formal and written approval from the Tor Project Executive Director before its implementation or any stage of execution (for example, promotion and outreach). Failure to proactively seek approval will lead to the exclusion of the project and its affiliates and associated from the network and Tor Community. Furthermore, legal measures may be pursued to rectify any financial or reputational harm incurred as a result of such actions. Vetting central entities: Proposals involving central entities such as collective wallets, Decentralized Autonomous Organizations (DAOs), or other intermediaries should be approached with caution and require approval by the Tor Project. These entities must be clearly identified and evaluated for their reliability, and the potential risks they pose should be thoroughly assessed. This includes considerations of their possibility to misbehave, for example, they could refuse service, could extort relay operators by demanding extra fees in order to release their reward, or could 'inflate' the digital currency (coins, tickets, guesses, etc.) by printing its own tokens for a profit, as highlighted in Rob Jansen's [research and blog post](https://blog.torproject.org/tor-incentives-research-roundup-goldstar-…. Consent for fund handling: It is mandatory for operators and intermediaries to obtain clear and explicit consent (written approval) before claiming or managing funds on behalf of others. This rule is crucial to maintain the transparency and trust within the community. Prohibition of unofficial financial activities: Unauthorized fundraising or financial activities conducted by intermediaries, especially those claiming to act on behalf of other operators without explicit consent and approval from The Tor Project, are strictly forbidden. Such activities, if promoted, posted, or shared on Tor communication channels (such as forums, mailing lists, chat channels), will lead to the immediate removal of the content and the exclusion of the individuals and entities responsible. Whether formally registered or operating on an informal basis, all Tor relay operators are authorized to launch fundraising and donation initiatives to support their ongoing non-profit relay operations within the Tor network. It is advised and recommended to handle the donations in a transparent way. This can be achieved by maintaining a specific web page that discloses the total amounts received by donations alongside with the operational costs. ### 5. No fee or "donation" for participation or to "unlock" rewards The sustainability proposals must be designed to avoid creating a divide within the Tor network, particularly between free and paid tiers. To ensure Tor remains accessible to all: - Participation in sustainability or incentivization proposals and the acquisition of rewards must be completely free of any charges. - True incentives for network contribution should not require relay operators to incur any direct (such as product purchases) or indirect expenses (like fees). - Any system not approved officially as described in this policy by the Tor Project that forces contributors and relay operators to purchase tokens, coins, hardware, or any form of digital or physical assets as a prerequisite is strictly prohibited. ### 6. Fraud, cheating, and abuse prevention in Tor incentives - Any proposed incentivization must incorporate a design that is resilient to fraudulent activities and exploitative behavior. - This includes verification processes for operators, and transparent and auditable reward distribution methods. The proposal's author must put in place measures to prevent fraud and gaming the system. - As part of their threat model and security concerns, proposals need to include a section analyzing potential scenarios of fraud, cheating, or abuse. A mitigation plan must ensure that the incentivization system remains fair, equitable, and true to the spirit of voluntary contribution that is crucial for the Tor community. ### 7. Conflict of Interest (COI) Policy Proposals and their implementation must follow this policy of Conflict of Interest: - All individuals and entities involved in the development, promotion, or management of sustainability and incentivization proposals for the Tor relay operator community must disclose any potential conflicts of interest and disclose the lack of a conflict to the Tor Community Policy editors, Tor Project Network Health and Community Team Leads. - These conflicts could include, but are not limited to, financial gain, personal relationships, or affiliations with organizations that could benefit directly or indirectly from the proposal. The definition of financial gain, affiliation and relationship will be added to the Tor Community Policies repository as a new informative proposal. - The Tor Project Inc (TPI) employees must follow the TPI Conflict of Interest policy. - Any party found to have a conflict of interest must immediately report to the Tor Project to either resolve the conflict in a way that aligns with the standards set by the Tor Project or voluntarily withdraw from the decision making process related to that conflict. The report must be sent to the Tor Project Network Health and Community Team Leads. ### 8. Reporting scammers and avoiding risks Unfortunately, scammers and bad actors are not new to the Tor Community and probably they won't go away anytime soon. If you want to report a project using the [Tor Project trademark](https://www.torproject.org/about/trademark/), the best way to do this is to email: frontdesk(a)torproject.org. If your report is about malicious relays on the Tor network, please submit your report to bad-relays(a)lists.torproject.org. The Tor Project is committed to maintain the anonymity and privacy of those who report. Be warned that sharing suspicious content on public channels will get your post excluded and your account banned by moderators. Relay operators should exercise caution regarding the source of their funds. In cases where there is suspicion that received donations may come from an illicit or controversial source, potentially jeopardizing one's reputation, operators are strongly advised to seek counsel from a legal advisor or contact their local relay association for guidance. ### 9. Frequently Asked Questions #### Q1: I'm a relay operator, and someone wants to buy me a beer for contributing to Tor, do I really need to submit a proposal? No, donations in any form do not require a proposal. #### Q2: I'm part of a relay association and we want to raise money to run more relays, how do we know if we need to apply? If you're operating as a non-profit, you do not need to apply. Relay associations are considered part of the Tor Community. #### Q3: I'm a cryptocurrency enthusiast, with an epic DAO tokenomics that is going to moon 10x in three weeks, you want a POAP? Join my discord! Before going to moon, please submit a full proposal to us, earthlings. #### Q4: I built a hardware device that people can buy to plug in and contribute to the Tor network as a relay, do I need to apply? As long you do not use 'Tor' as part of your product name and you're following the Tor Project policies, you are not required to apply. However, meeting with the Tor Project is strongly recommended. Please note that there are other hardware projects being developed by the Tor community, for example, by Science & Design, Inc. [Pi Relay](https://pirelay.computer/). #### Q5: I'm a VPN company and I built into our app a way to contribute a snowflake proxy, should I rip that out until I figure out how to do this process? No, although Snowflake is part of the Tor network, it's different from relays as we cannot remove "bad" snowflake proxies. However, we recommend getting in touch with the Tor Project Anti-censorship Team to ensure you're following their best practices and policies. #### Q6: We are a company who makes a cryptocurrency wallet application. We've built Tor support into our app to transmit transactions over the tor network for network-level privacy protections. We get a cut of those transactions. We want to give back by running relays, but do we need to apply to do that? Depends, if your wallet users are paying a fee to run a relay, then, yes, you need to write a full proposal. If you're talking about donating profits from your business and you've declared your 'MyFamily' relays, then following the [Expectations for Relays Operators](https://community.torproject.org/policies/relays/expectations-fo… is enough. ## References * Safeguarding the Tor network: our commitment to network health and supporting relay operators (2023) https://blog.torproject.org/tor-network-community-health-update/ * Tor incentives research roundup: GoldStar, PAR, BRAIDS, LIRA, TEARS, and TorCoin (2014) https://blog.torproject.org/tor-incentives-research-roundup-goldstar-par-br… * Two incentive designs for Tor (2009) https://blog.torproject.org/two-incentive-designs-tor/ """ Thanks, Gus -- The Tor Project Community Team Lead

1 0

PSA: Rejecting bridges running 0.4.7 (EOL)
by gus 11 Jun '24

11 Jun '24

Hi, The bridge authority Serge has upgraded to tor-0.4.8.12 and it's now rejecting bridges running tor-0.4.7.x (end-of-life). Please upgrade your bridge to tor 0.4.8.x to return to the network. Bridges affected: https://metrics.torproject.org/rs.html#search/type:bridge%20version:0.4.7%20 Gus -- The Tor Project Community Team Lead

1 0

Re: [tor-relays] Directory authorities not giving weight to a relay
by smoothop＠tutanota.de 08 Jun '24

08 Jun '24

Hello! Thank you very much for your detailed response. I have been checking everything you and the others have said, and seems like my naivety was the problem all along. TLDR: Hosting (Hostiko) does shady practices and limits server bandwidth Before getting to the solution, let me enumerate a list of things my friend who I work with and I have done over the past week: Checked tor logs, hoping to find some error that told me that something was wrong with my tor setup (nothing was found!) Checked zabbix metrics, but nothing out of the ordinary (also worth to mention that this was setup after the drop in consensus weight) Tried to install vnstat from source and failed miserably, about 15 minutes into the "make install" it threw an error. I cleaned everything that was made (or so I thought) and installed it with pkg because I was too lazy to make the compilation work. Spoiler alert: I was getting tons of permission errors and similar with everything related to vnstat. I just let it be and assummed that zabbix would get me the same values that vnstat would. Updated FreeBSD to the latest version (downloading everything was rather slow, hmm...) Updated my tor relay to 0.4.8.11 Nothing worked, so as a last resort I checked the server bandwidth once more (this was already checked when I first got the server, and it was fine). Speedtest reported around 3 Megabits per second. My friend also ran iperf and we got a similar result. Anyway, I log into the customer area of the hoster and open a live chat. My message was the following: > Hello! I am having issues with my server bandwidth. I should have something close to 200 mbit but I seem to be getting 3 mbit max After a few minutes they get back to me with this response: > Your server's speed has been limited because it is being used for traffic proxying. According to our policy, we restrict VPS that are used to hide the real address or to utilize our DDoS protection. This message seemed a bit weird, mostly because I didn't really understand how did the know what I am using this server for. I am aware that there are several methods (checking the relay search, duh), but on their side I just supposed that they would see traffic from the port 443 and assume that I am hosting a website or something. Then I remembered something strange that happened around the time that the consensus weight dropped. My friend had setup an alert on every login on the system, and we got one at Thursday 0:33 (We both work, so at that time we are usually asleep already) This login stood up a lot, but not because it was a root login (we only login with our users), but because of that specific IP, 178.250.189.20. A simple lookup tells us that it's related with the hosting. The ISP is MDCloud and the organization is Hostiko. At the time we assumed that this happened because the server restarted and some service triggered the login alert. Anyway, fast forward again to today, and I checked the root user command history and this is what we found: The command history was disabled, then history was run again (I guess after whoever got into the server ran some commands) and exited. This is extremely shady. I checked every log in the system, even the system mail where apparently I get daily and weekly security digests (which is just a log of failed logins and some updates recommendations) and could not find anything in that specific timeframe, it's like it never happened and it's all in my head. Anyway, I'm not much of a confrontational person, so I just asked more about that limitation and how can it be. Unless I am missing something, their ToS has nothing against them. Their response: > We do not prohibit VPNs or Tor middle nodes, but we limit network speed once the traffic exceeds the acceptable amount for your plan. In your case, we noticed that the server was used solely for proxying and exhibited an unnaturally consistent level of traffic (almost the same 24/7), so we have limited it. Since we use more expensive DDoS protection in Germany and Poland, we are forced to take stricter measures. You can use our services in Ukraine, where we can apply more lenient policies. If this is unacceptable to you, we can also offer you a refund. We apologize for the inconvenience. They offered a refund, and even for the whole three months. I already gave them my details, hopefully they keep their word on this at least. I have backed up my relay keys, even though I'm not sure if I can trust them anymore. My next step currently would be to decide on a new hosting provider. I will also try to update the Good Bad ISP table. Thank you very much again! Regards.

1 0

Relay bandwidth issue
by kricklen＠tutanota.com 07 Jun '24

07 Jun '24

Hello everyone, i got a local relay running with v0.4.8.11 and the following configuration: ... RelayBandwidthRate 4 MBytes RelayBandwidthBurst 7 MBytes ExitPolicy reject *:* ExitRelay 0 SocksPort 0 About a month ago, the relay started to behave differently than it used to: A few hours after each restart, it didn't respect the bandwidth limits anymore, meaning it took what it could get. After a while my isp interrupts my connection, i guess because of exhaustive traffic or connections being established, not sure. This leads to the following loop: 1. The relay notices it's ip changed and starts over 2. It consumes max bandwidth after a while 3. The isp disconnects 4. Start at 1, until after enough loops the relay is broken and doesn't connect anymore I'm not sure what caused the different behaviour, i don't have a close look on when my relay gets an update. The issue is severe for me though, so any help in fixing the bandwidth limit again would be really appreciated. -- Sent with Tuta; enjoy secure & ad-free emails: https://tuta.com

2 1

Onion Services operators please enable tor PoW defense
by gus 06 Jun '24

06 Jun '24

Hi, As some of you might have noticed, we have a high load situation on the network for a couple of weeks now affecting in particular onion services (but not only them).[1] We recommend Onion Services operators to enable our Proof of Work (PoW) defense[2][3] and finetune their torrc[4]. If you're running onion services with onionbalance, though, PoW is currently not supported[5], but we're interested in hearing from you if this is a feature that we should prioritize. Thanks, Gus ps: this advice does not apply to relay operators, only to onion services operators. [1] https://status.torproject.org/issues/2024-05-14-network-performance-issues/ [2] https://blog.torproject.org/introducing-proof-of-work-defense-for-onion-ser… [3] https://community.torproject.org/onion-services/ecosystem/technology/pow/ [4] https://community.torproject.org/onion-services/advanced/dos/ [5] https://community.torproject.org/onion-services/ecosystem/technology/pow/#i… -- The Tor Project Community Team Lead

3 3

Directory authorities not giving weight to a relay
by smoothop＠tutanota.de 03 Jun '24

03 Jun '24

Greetings everyone! Almost three months ago I have set up my first node. Everything seemed to be going great at first and as documented in the tor lifecycle blog post. A few days after being set up the weight drastically dropped to around twenty. This seemed a bit odd since that same blog post doesn't mention anything about weight dropping so much, but it does about bandwidth, ao I just shrugged it off and assumed it was normal. Anyway, fast forward to today, and the weight hasn't really gotten above two hundred, it has been a month and a half I think since the weight drop, and it has been stale at a weight of between one hundred eighty and two hundred. I can't put my finger on what is exactly the problem, the relay currently has six flags: Fast, HSDir, Running, Stable, V2Dir and Valid. Shortly after the drop I have even seen the Guard flag for like a day. The server has capacity and is dedicated solely to being a relay, and the ISP is in the good providers list. The fingerprint of the node is ACC72E6D0FA76168AE1BA7F26996D191FEA7C9D8. Maybe someone in this list can give me a hand and point me in the right direction. Thank you in advance!

4 3

Tor relays Bazinga and JPsi2 to be shut down
by Random Tor Node Operator 03 Jun '24

03 Jun '24

Hi all, I have been operating the relays - Bazinga B198C0B4B8C551F174FBB841A172616E3DB3124D - JPsi2 F6EC46933CE8D4FAD5CCDAA8B1C5A377685FC521 for about 10 years. The hosting provider stops providing their current service and their successor services are not Tor-friendly anymore. Hence, these relays will be shut down by June 2 2024. My third relay - SafeAndEffective A508096AA0C899F4E6ECD1D9C35037B89008BCBA is unaffected.

2 1

Warn_TorBTCMoon
by tor 27 May '24

27 May '24

Nickname TorBTCMoon ContactInfo torsafe777(a)gmail.com Your computer is too slow to handle this many circuit creation requests! Please coconsider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit CPU 100% How to fix?

2 1