Add a Tor Relay Operator role

[sqrrm]

Motivation

Bisq is dependent on tor for stable operations. This showed clearly during an attack on the tor network in December. Bisq was affected quite negatively with failed message deliveries causing quite a bit of trouble and extra work for arbitrators. This was exacerbated by the high and volatile Bitcoin fees at the time, but that's a different issue.

Proposal

I propose to add the role of tor relay operator to support the tor network, to be compensated through the DAO. This might not stop troubles during attacks but it will add to the resilience of the tor network making it harder to attack in general.

Requirements

Requirements on this role to be decided, but some considerations would be to require at least a certain uptime and bandwidth and to keep the software updated. In general keeping with the guidelines from the tor community should be expected. As an example I've been running a node for a few weeks, stats can be seen at https://metrics.torproject.org/rs.html#details/D4FBE51BC35C3921F31B6E561FD8C07BC56F9D71

Other Considerations

It has been mentioned that this could encourage current tor operators to become Bisq tor operators to gain the BSQ reward. This could be seen as a problem in that it would add no benefit to the tor network but BSQ would be paid out. It would on the other hand bring in such operators to Bisq which could help with knowhow and more people within the project. I don't think it's likely to happen for now though, but should be kept in mind.

[ManfredKarrer]

Could you post the requirements for a hosting service (RAM, bandwidth) so it is easier to estimate the costs/ month?

[dsbeasley]

@sqrrm I'd like to setup a Tor node as well.

[cbeams]

I'm generally in favor of this proposal, but am holding off on my 👍 to explore the following thoughts and questions:

• How many relays would we want to support? We probably want to start thinking in budget terms here. We're currently issuing around 50K BSQ per month for compensation requests, so we should consider new expenses like this in relation / proportion to that figure. Tor is very important to Bisq, so 50 BSQ / month might be too little, and 5,000 BSQ would be too much. At our current stage, it seems to me that something around 500 BSQ per month would be appropriate.
• One way we could solve the "opportunistic relay operator" problem that @sqrrm mentions—in which existing relay operators just come and claim a BSQ reward—is to make this a bonded role. The bonding in this case wouldn't be so much about insuring against an operator going rogue as it would be about proving that a relay operator is actually committed to Bisq as a project.
• Having this be a bonded role would also help solve how to compensate the effort, as we can use normal "interest" payments on the bonding amount as an incentive, instead of an arbitrary amount above and beyond the costs of operating a relay.

[sqrrm]

@ManfredKarrer The guidelines can be found at https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#RelayRequirements

I've been running a node with 1GB RAM for a 100Mb/s unlimited node on a VPS for USD5 per month. With that I get about 1.3TB uploaded (and the same download) per month. They have lower suggested minimum but I don't know if it makes sense to support anything less considering the effort to request compensation or setup a bond.

@cbeams The amount spent on this should be kept reasonable in relation to other efforts, but I prefer to look at the technical details rather than the amount spent to consider our requirements. I agree though that 5000 BSQ (10% of total) is definitely too much, and even 500 BSQ (1%) sounds high for what is essentially just bandwidth.

• I suggest to support at least the amount bandwidth that Bisq uses. Bisq would then be a total good for the tor network since it wouldn't affect the bandwidth negatively but would add resilience. There is no conclusive measure of how many Bisq clients are in use at any given moment though, but using the number of downloads, number of offers and perhaps as Manfred mentioned elsewhere, running a client with no connection limit could give an indication.

• I like the idea of bonding as a sign of commitment to the Bisq project.

• Automating the compensation sounds good to me. It would then be good to set up a strict requirement of what service should be provided, such as a certain bandwidth with a certain uptime.

[ManfredKarrer]

In December there have been about 125 nodes online at the same time.
We support about 10 BTC nodes which cost about 500 BSQ/month. I would consider the Tor part equally important (or even more important), so I would not have a problem to spend 500 BSQ / month on Tor relay nodes.
With 5 USD/months we could support quite a bit of nodes. I assume the setup is the only one time effort then once the nodes runs there is very little maintenance needed.
@sqrrm What would you estimate monthly compensation additional to the hosting costs?

[sqrrm]

@ManfredKarrer I've done nothing with my node since I set it up which took an hour or something like that. There is however a need to keep up to date with latest tor updates and make sure the service is running. The uptime isn't really a problem since the services are not critical in the same way seed nodes and price nodes are so just updating tor every once in a while is all that's needed from what I can see.

There is a way to setup multiple hosts with ansible but I have some troubles with that. If I get that to work it would be a single command to setup any number of relays. How much that's worth in compensation I don't really know, but probably not much per relay.

[cbeams]

@sqrrm, thanks for your responses. All makes sense to me so far. I'm for this, so long as you'll be on point as the primary Tor Relay Operator from the get-go, and thus the one who makes sure that everything is documented, that you publish a monthly report on the Tor Relay Operator role issue, etc. Is that what you had in mind / does that work for you?

[sqrrm]

@cbeams Yes, I planned on taking on the Tor Relay Operator documentation and reporting to begin with, unless there are other takers, but probably good if I take it first and hand over to others if there are other takers.

[cbeams]

Closing as approved with 2 👍 (3 if you count @sqrrm, who didn't actually give his own 👍—proposal submitters should always do that):

@sqrrm, please go ahead with the following:

• Create a new issue in bisq-network/roles titled "Tor Relay Operator", reference this proposal in the description, and indicate that you are the primary role owner.
• I'll then assign you to the issue and set up a @bisq-network/tor-relay-operators team.
• At the same time, please submit a PR to the bisq-network/bisq-docs repository adding tor-relay.adoc. This can be as basic as you like, but should carry over the motivations and requirements laid out in this proposal at a minimum, should link to the role issue, and generally contain any and all information you think will be of value to (a) current and future Tor relay operators, but also (b) general Bisq users and contributors who are looking to understand the various components of the larger Bisq Network. You can think of this doc as part wiki page, part manual, part role specification. Everything is very much in flux with the docs repo and docs.bisq.network site, and I plan to write up documentation about that effort soon, but since I haven't done so yet, I thought I'd provide a the primer above. Just have a look through the recent documents I've created, like proposals.adoc and see about following convention / tone you see there.

In any case, enacting this proposal is all yours to carry out now. Thanks for raising it in the first place. I think this'll be a valuable addition on multiple fronts. When the above items are all in place, we can announce / promote the effort via Twitter to let everyone know what we're up to and get the most mileage out of it.

[sqrrm]

I've meant to write up an operator requirement but been sick for a couple of weeks. Once brain is back I'll get on it.