Walletwasabi: Optional tor relay node integration

[MaxHillebrand]

Problem

Wasabi is a heavy tor user, so we rely on a healthy and decentralized infrastructure. If a client communicates over tor only when the user is doing Bitcoin stuff, there might be time correlation attacks.

Solution

Similar to #2495 bitcoind binary inclusion, add the software to run a tor relay node in the Wasabi client, and in the settings make it one click optional to start and stop tord together with Wasabi.

[ghost]

@MaxHillebrand

as we started a chat, let's continue here!

the problem with a user routing all traffic through tor is not really a security or privacy issue, but more so a layer8 issue that cannot be solved very easily. it's like saying "only use wasabi on tor" which may get people nervous about their traffic habits.

so my ideas could be:

• on wasabi spinup like bitcoind launch we could build a platform-dependent binary that would act as a simple tor router. design would be simple create tun interface or next in device series, then figure out dynamic routing to route wasabi by default through tord. rest of user's traffic can go through clearnet with optional full-route through tord

• i like the idea of modularization in that let's say you could spawn some unikernel container with tor running to it, then traffic routing for wasabi might be more isolated and blackboxed in a way. but i think it's more tooling and coupling this way, probably easier and better design with first option

i may have some more thoughts but this gets the conversation started

[MaxHillebrand]

Thanks for chipping in @assassin4377!

The nuances of this is all over my head, so let me ping @nopara73 and @lontivero who know much more about the details.

And just for the record, wasabi already today routes all traffic through tor by default. Here is the TorSocks5, Tor tests and Tor exceptions code.

So this open issue is to find out if there are any additional privacy benefits to be gained by running some additional tor functionality, like for example a relay node. And also how this would help the tor network in general.

[nopara73]

The described problem is vague, the and the suggested solution is even more so. We were planning to add an additional option of running Tor relay, but purely because it would support the Tor network.

Questions to explore are if it really supports the Tor network or just releases a bunch of unreliable node to it and if it exposes our users to privacy attacks or not. IMO the legal issues are just noise and the decision can be delegated to the user at hand.

[ghost]

@MaxHillebrand And just for the record, wasabi already today routes all traffic through tor by default. Here is the TorSocks5, Tor tests and Tor exceptions code.

yes, i'm aware. but was confused by your ask and terms earlier. i understand now the intention.

@nopara73 i have to agree. the concept is vague and my suggestion(s) as well. it's like shooting a shotgun hoping to hit a bird.

as long time user and operator of tor and other overlay technologies, i can confirm that simply dropping a middle/exit relay into the mix is counterproductive. ignore the legal issues, as you said they are noise.

• starting a middle or exit relay while the user is using wasabi is risk because when either one of those relay types are deployed the ipv4/6 ip address is listed in the tor directory, thus adding a vector of de-anonymization and jeopardizes the user privacy

• starting a middle or exit relay while user is running wasabi also pollutes the tor network with unreliable and slow nodes. it can take up to 68 days for a non-exit relay to achieve steady-state guard phase which is ideal for a node. so given that scenario, i launch wasabi which spawns a relay, i have to leave it open for at least 30 days just to make it useful and nearly 70 days to make it very reliable. one of complaints i receive from new users is why is it unreliable. node pollution is a massive reason for this

• even though legal issues are noise and there is no law in place to stop you from running middle/exit node, running exit node presents a lot of challenges mostly in maintenance and administration side. it could all be automated, but the last thing you would want for a user is for them to pawn a tor node process, leave it running, then they wake up later to find isp has cut their access for exiting questionable traffic. as a long time operator i would never run any relay from my operational location. it's just all around poor idea.

that all being said, i think if we were to introduce this idea, the use-case is best to launch bridge nodes. here's why.

• currently the buzz is on running middle and exit relay nodes because it's cool or whatever. very few people focus on bridges. bridges allow people on networks that filter tor traffic to punch the firewall and connect into tor. since tor does not publish the ipv4/6 address of the bridge like it does for relay, they are much more covert. they also pose almost 0 privacy or security issues, and some of us in the network would argue that they are one of the most important parts of tor.

tor project has tried to do something like what is suggested with snowflake which is pluggable webrtr transport in-browser. allows tor users a proxy/bridge where maybe before a reliable onramp was not available. this is the model i would suggest for wasabi project.

experience flow could theoretically go:

• user launches wasabi wallet
• by default wasabi will spawn lightweight bridge
• subtle ui/alert will tell user when bridge is hot and up
• upon terminating wasabi user can opt to leave bridge running
• also during any lifecycle of wasabi execution or termination user is easily able to opt-out of running bridge

again this is loosely realised design but it's interesting to think about.

[ChristopherA]

There are a number of different issues here. There is support of Tor for the benefit on the end-user, then there is support of Tor, for the network. For instance, Blockchain Commons (through our Patrons) is funding an Tor Exit Node https://metrics.torproject.org/rs.html#details/644074F47257F9A906F9AA5C6B8926C1540A1DA8 that has been up for over 100 days. Wasabi should consider funding the same (or contribute to Blockchain Commons to open another — we'd like to open a 2nd in Indonesia).

I don't think Wasabi itself should do Tor relay, but any bitcoin full-node user may want to, so setting up a Tor relay as part of setting up a full node isn't a bad idea.

Then there is the use of Tor to secure the user. You might want to take a look at #Bitcoin-Standup, a @BlockchainCommons project that sets up a full node for self-sovereign bitcoin users, and in particular, the QuickConnect QR/URL and how we set up V3 tor client auth secure connection between the full node and remote clients https://github.com/BlockchainCommons/Bitcoin-Standup#quick-connect-url-using-btcstandup

An aside:

I would really like to see a self-sovereign architecture where full node installers (Bitcoin-Standup), dedicated full-node devices (Nodl), remote devices (Fully Noded (ios)), remote wallets (Zion Wallet for HTC Exodus (Android)), multisig coordinators (Caravan), offline cold-storage (Hermit)), merchant services (BTCPay), and mixer services (Wasabi can all securely mix-and-max our capabilities and collaborate together for the benefit of the self-sovereign user.

Currently Blockchain Commons is coordinating a number of these discussions in issues on Github and via a private Signal group, but we have no one from Wasabi, and we have not chosen any other async chat forum (too many choices and channel fatigue).

Maybe we should schedule a Zoom call next week after US Thanksgiving to discuss different ways that this projects could function together? Some of use are US Central and Pacific time, others are in the same time zone as Taiwan.

cc: @Fonta1n3 @dhruvbansal @howech @NicolasDorier @htczion @wolfmcnally @rxgrant

[MaxHillebrand]

I'm sorry for the vague initial issue, I just don't understand the nuances of tor that well to formulate a coherent suggestion.

Thank you very much for the nuanced argument @assassin4377!!

The idea with a bridge node seems very promising - especially because it does not publish the ipv4/6 address. But a question: is it still a problem to have unreliable bridge nodes, just as it is to have unreliable relay nodes?

experience flow could theoretically go

What you describe here is exactly how I envision it too, and it is how bitcoind is operated already, with one minor caveat that it is initially an opt-in, and no default. But I think because the resource requirements of a bridge node are far below that of initial block download in bitcoind, so I think we could actually make it a default, but this warrants further discussion.

@ChristopherA it's a good idea that zkSnacks runs a tor node, but that is not what I intended with this open issue.

Your second comment is a bit off topic, but checkout @kixunil cryptoanarchy deb package which contains a very good selection of Bitcoin software in a well configured package.
I will reach out to you in DM to talk more about the integration of Wasabi in your projects.

[ghost]

@ChristopherA thanks for the polite and insightful response. my core work is focused on privacy, anonymity, and overlay/algo-routing such a tor/etc.

i think we have eliminated the idea of running any sort of middle or exit node for @MaxHillebrand issue that was spiked as it's not a sustainable or reasonable implementation given the lifecycle of a node.

i do fancy the idea of patron sponsored exit nodes, and while i'm waiting on the last 2 /24 assignments i do have a few pieces of metal floating around that i'd be happy to donate to whomever needs it.

while i'm not directly involved in blockchain commons or wasabi i am happy to serve as a resource or a fly on the wall should you require it.

@MaxHillebrand from packaging stance i like the repo surfaced by @Kixunil

but in my humble opinion i feel this is an organisational decision that would need to be decided within wasabi core team.

personally as a user of wasabi i already have some pain around resource allocation especially utilizing isolation such as vm, container, qubes, etc. so adding more tooling seems like it would be taxing on an end-user's system and would potentially harm the ux.

if you all have a call and wouldn't mind me joining, let me know

[nopara73]

I'm not really up for a call just yet. To be fair, right now we're working on 5-7 huge projects at the same time so we're not really in the position to think about this. Sure if there'd be a quick and clean, non-controversial way to do this, that'd be great, but reading this conversation, I realized, the topic is more nuanced than I initially thought. (Or just the participants want to act that way, haha.)

[ChristopherA]

@nopara73 I know a lot of things on your plate. But do take a look at the Quick Connect QR / URL code I mentioned above https://github.com/BlockchainCommons/Bitcoin-Standup#quick-connect-url-using-btcstandup

It would allow for Wasabi to securely connect to the users full node wherever it is, either locally, at home, or hosted on a VPS somewhere.

[ChristopherA]

As far as tor relay/bridge functions, I don’t see that any app should implement it directly. Instead it should be installed optionally and independently at the same time as bitcoin, lightning, BTCPay, etc. as a user option as another service that can added on a persistent device or server. But it should never be embedded in a app that is open/closed or a device that might sleep. These tor infrastructure services need persistence.

[MaxHillebrand]

Good conversation so far - thank to all!

@assassin4377 what do you think about the complexity of integrating the bridge node? Is it a big hassle, or can it be done rather smoothly? The prioritization of the project depends on this.

I will try to remember to send you the link to our next dev call, weekly on wednesdays 15:00 UTC I believe, it would be great if you can join and give some insights.

[Kixunil]

@assassin4377 you have some good ideas and I'd like them implemented - in a different project, not Wasabi. I think Wasabi is just one component of a bigger ecosystem and it should do one job and do it well. (I think that bitcoind is still a good exception for the meantime, while other tooling isn't there yet.)

So since this is something I would definitely want, I opened https://github.com/Kixunil/cryptoanarchy-deb-repo-builder/issues/21 This whole thing looks like out-of-scope for Wasabi, so I suggest moving discussion there.

@MaxHillebrand unless there's an easy switch to turn it on, I guess it might be out of scope too. But again, something I'm interested in doing. I was actually thinking about it before, much more useful if you deploy the deb repo on a dedicated, always-online HW.

[ghost]

@nopara73 thanks for the response. yes, very nuanced.
@ChristopherA agreed tor is nothing without persistence even with bridge infra
@MaxHillebrand it's not terribly difficult, but as you can see it's very much out of band issue. always up for a call. i never sleep
@Kixunil thanks, i appreciate the loop-in. will look at that issue and discuss!

[Fonta1n3]

@assassin4377 am I correct in thinking that running a relay does significantly more to help increase the bandwidth and speed of the tor network then running a bridge? Sorry for the newb question.

[ghost]

@Fonta1n3 no worries, never apologize for learning.

bridge doesn't help much in the way of increasing bandwidth so much as it does increasing covert onramps to tor where tor may be censored (ie like dprk, syria, corporate network, etc). when a user requests a bridge tor will serve a proxy that looks like a clearnet endpoint and that allows you to enter tor and punch firewalls/bypass network analysis

the middle and exit relays are focal point for bandwidth and throughput. unfortunately there are many less exits vs middle relays since middle relays just algo-route traffic between nodes and never egress to clearnet. exits are the ones you hear the nightmare stories about. people getting busted for having illegal content flow through their node. but a lot of that is lack of education.

i operate quite a few of the exit nodes in us and eu and have only had dmca requests and one subpoena which cannot be answered because nature of tor is no log.

tor is an important part of privacy and anonymity which i think aligns well with wasabi. but none the less @Kixunil and i are discussing deeper integration into his project. :-)