- tor-relays - lists.torproject.org

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 12 Jun '24

12 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 07 Jun '24

07 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