Would you like to help review some of the backport commits?
2 Likes
Friends, am I missing something here? In the middle of 2025, zcash nodes still don’t support the Tor protocol?? This is unbelievable!
2 Likes
i agree its something that shouldve been here already.
but we now have rust based version of Tor called Arti ready
and also Nym mixnet so
one of those should be integrated imo in ways to improve the privacy
i guess Zcashd deprecation is taking all the focus atm tho
1 Like
It’s actually quite cool that Zcash sponsored Tor’s to rust migration. I wasn’t aware of this. However, seeing that it happened back in 2021, it seems like something clearly went awry. Today, in 2025, the whole situation looks somewhat strange and rushed.
[forum. zcashcommunity. com/t/arti-a-pure-rust-tor-implementation-for-zcash-and-beyond/38776
Firstly, Tor is notoriously difficult to embed, but Arti solves this by being built as a set of Rust crates from the ground up.
What’s really puzzling is what’s so complicated that it’s justified waiting four years and still counting? Meanwhile, Arti is still not ready and not recommended for production use. Maybe they should rewrite it in Go and zcash users wait another five to ten years, then it’ll surely be a breeze to implement for Zcash .
Seriously though, I’ve never heard of anyone having issues with v3, whether it’s for cryptocurrencies or other services, and that it took a significant amount of time in any ecosystem.
It’s no surprise that Zcash isn’t used in practice as a private coin, despite trying to appear as one.
I’ve also heard about Nym. Everything sounds great on paper, but so far, it can’t be said that it’s “taken off” (with only 240 nodes today, and the project is five years old).
Moreover, in their VPN, there’s no option to pay with Zcash or swap it, even though they support over 1,000 different coins, including Monero (XMR) for sure, but not ZEC. (explorer. nym. spectredao. net/swap)
1 Like
Just re-read your post and thought you were trolling me with those Arti and Nym, and I didn’t catch the sarcasm and took it for real? 
umm no.
i cant talk for other projects.
i dont know why the normal Tor couldnt be implemented and it would be great if it had been long time ago.
ok maybe Arti is not super ready for everything, its usable for some things. and Zashi wallet has integrated it to show ZEC price in privacy preserving way.
Nym might be kinda old project but it only launched to wide public last month for real. before it was in beta testing for long time. i do consider it in its early phase still from VPN world perspective.
about ZEC payment for Nym, its in plans when BTCpayserver Zcash plugin gets fixed up finally.
1 Like
Arti was completed just a few months ago. From:
https://gitlab.torproject.org/tpo/core/arti
Now that Arti has reached version 1.0.0, we believe it is suitable for
actual use to anonymise connections.
I’d love to see it integrated with Zebra and wallets. Yes it’s a huge shame that it hasn’t happened yet. But we simply hadn’t the time to work on it.
2 Likes
Well, the final days for zcashd are steadily approaching. I thought I’d take a look at Zebra over the weekend, especially since it includes Tor, Nym, and blackjack with hookers.
Looking at zebra/zebra-network/Cargo.toml:
tor dependencies:
Wait until arti-client's dependency x25519-dalek v1.2.0 is updated to a higher version. (#5492)
Well, waited five years, now we’re waiting for something else… okay. Let’s see what stage this dependency is at.
It turns out it’s already resolved. We’re not waiting for anything anymore. Other circumstances arose a year ago, and that’s it.
github .com/ZcashFoundation/zebra/issues/8328#issuecomment-1969989648
Assignees: No one assigned
On the other hand: Why the heck bother with all these complications, this so-called “network security”? Investors don’t understand it anyway. And users… What users?
Give us a chance please. Investors are like users in this community, they’ve been de-prioritized so developers can finance their science experiments in peace. We need to get them back in here, it may take a little while but it’s doable.
I think investors, like users, very much care for all this; I certainly do. Stick around, we may need each others to make stuff like this happen!
2 Likes
SOCKS support is table stakes. It really is embarrassing that none of our wallets even have SOCKS. (SOCKS is a pluggable way to support Tor, Nym, anything that also supports SOCKS)
Rather than doing the ~2 week task of adding SOCKS to a Zcash wallet app (like BTC, Monero, countless other wallets have) so that users can hide their IPs via a Tor daemon, Zcash decided to fund a multi-million dollar rewrite of Tor into Rust. That still, none of our wallets use to connect to the Zcash network.
This rewrite, Arti, is actually incredible! Millions of people will benefit from it: Tor users. In the short term, that’s arguably more humans benefited by Zcash-funded technology than anything else we have built. More “normies” for sure.
Right now the only Zcash wallet using Tor is Zashi, and only for checking exchange rates.
When devs talk about Tor support today, they’re talking about exiting the Tor network. Supporting hidden services, which make it sufficiently-impossible for a user IP address to leak (.onions), is not yet within scope.
Zcash does not work in TAILS, the ephemeral operating system that the most vulnerable people often use. Feather (XMR) and Electrum (BTC) work great.
Please, someone add SOCKS support to a Zcash wallet.
And generally we need to stop our bad habit of overengineering and overfunding things, when a quick “version 1” of a feature is possible to launch within weeks.
It is not a sin to run code that is not written in Rust. I believe that our culture of Rust maximalism, and of micromanaging our users based on wild imaginations of their diverse threat models, holds us back.
2 Likes
We integrated Arti into the mobile SDKs (used by Zashi et al) in August last year, initially just for fetching currency conversion information over Tor. That’s had a while to stabilise (and Arti itself has had various bugfixes and improvements in the interim); we’re now working on moving transaction submission over Tor in the mobile SDKs, followed by transaction fetching.
3 Likes
I have literally tried this before, years ago. It is not a two week task, and the result was difficult to deploy, hard to use, unreliable, and completely unmaintainable.
The problem was nothing to do with C Tor not being written in Rust. The problem was everything to do with C Tor not being designed to be used as a library or an internal app dependency. And as I recall it, the work necessary to rework C Tor to be properly usable in this way would have been similar in effort to what instead went into Arti.
This is misleading. Onion service support is entirely within scope where usable and applicable; it just isn’t a magic bullet to be thrown at everything (and at least until recently was not recommended for use in Arti if you actually needed it to provide privacy guarantees; I still need to re-evaluate it).
On the topic of the actual thread: the thing blocking Tor support for the full node layer (rather than light clients) is making the necessary changes to the P2P network layer. This was blocked by zcashd due to needing an unreviewably and unmaintainably large backport of upstream networking changes. Once zcashd is deprecated and no longer in use, it should be relatively straightforward to make the appropriate change in Zebra to the P2P network protocol to support v3 onion addresses.
2 Likes
I’m referring to desktop wallets, not adding Tor support to zcashd.
Adding SOCKS in Zingo, YWallet, the deprecated Zecwallet would have been a two week task per wallet. I just don’t believe any of those projects would merge my PR because of our absurd politics and misguided opinions around here.
Everyone else uses SOCKS communicating to a separate process: Tor. This is the overengineering mindset I am referring to. Table stakes is SOCKS support, nobody else embeds Tor inside their crypto wallets. And again this is about desktop wallets, SOCKS makes way less sense in mobile (I can’t think of a mobile wallet that does it but perhaps that’s how Orbot works with wallets on Android)
Please be more specific. You are working on Tor support, yes: but Tor support that exits the Tor network.
This is what’s being worked on:
User wallet <> Tor network <> clearnet domain + SSL (light wallet server)
This is what other light wallets like Electrum (BTC) have supported for years:
User wallet <> SOCKS <> Tor <> Tor hidden service .onion (light wallet server)
SOCKS delegates DNS resolution to the SOCKS server so you don’t have to worry about making a ton of code changes to support non-standard-library-friendly domains like .onions.
Allowing light wallet servers to be Tor hidden services has these benefits:
- Anyone can host one without a domain name, SSL certificate, opening ports on their router.
- Light wallet servers don’t reveal their IP addresses, making it much safer to use your home network to host a server.
- Communications are end to end encrypted by Tor, removing the need for SSL certificates.
- Domain registries cannot censor or doxx you (the .rocks TLD, or legal process, could shut down zec.rocks)
- SSL certificate issuers cannot censor you by revoking your SSL certificate.
- If implemented using SOCKS, switching over to I2P, Nym, or any other SOCKS-compatible privscy network does not require code changes.
- Light wallet server operators are no longer at (much) risk of receiving subpoenas, national security letters, etc.
Then a) you should have said so, and b) you’re in the wrong thread.
For desktop wallets, yes. And indeed this could have been done long ago. You’d have to ask the developers of those desktop wallets though, instead of blaming the lack of it on other devs making unrelated decisions about desired support in mobile wallets.
The technical difference between these two on the client side is literally just me enabling a config option in Arti. It is disingenuous to claim that I’m somehow not working to enable Tor-internal communication.
The SOCKS proxy does nothing special here, and in my own past experience as an I2P developer it is much more susceptible to misconfiguration and subsequent leakage than in-app support.
Please upgrade Arti and enable that config option.
And to be clear, I’m glad that you’re working on it. It’s just extremely frustrating to try to communicate healthy networking OPSEC to a group of core engineers who seemingly have never used their own technology for something that their life/death/freedom depends on. Which, look, is probably a good thing.
I think that’s the core disconnect between full time Zcash developers and passionate anons that appear on the forums from time to time: if you’re using Zcash or any privacy coin in an attempt to get actual privacy in a high risk situation, you will of course approach these conversations with a different passion and urgency than people who are excellent at theory but likely have no experience fearing for their lives if a privacy technology fails them.
How likely is it that these technologies even help those truly in danger? Especially if configured wrong?
Today all users leak their IPs to Zcash light wallet servers while syncing, unless they use a somehow-perfect VPN setup. Zec.rocks does not log IP addresses. But somehow we are hosting practically 100% of the Zcash light wallet network right now. That’s a huge crosshair on our foreheads.
Tor is a giant leap in the right direction. And hidden service support fast tracks user ability to self host to not rely on us.
No privacy technology is perfect but Tor is absolutely keeping millions of people safer than they would be otherwise.
What if every phone, regardless of network gynmastics, is captured?