That’s not our threat model. I’m solving for 90% of users, not people at risk of physical device seizure.
Then we risk Monero’s problem, folks thinking they are anon, when they are not.
I think its wild how much trust some give it.
You make a great point, I’d like to add a lot more on this topic, but returning to Tor. Guys, can someone please explain this to me:
What is fundamental difference in the P2P Zcash network for IPv4 and Tor v2 and v3?
I understand it like this: For working through Tor, Zcash needs to know Tor TransPort, obtain its address from Tor service, and tell Tor service which port Zcash is listening for incoming connections on.
After that, all connections to .onion addresses are simply route through TransPort, and share own address to Zcash nodes with .onion addresses.
At least as far as I know, this is how most programs interact with the Tor service. Or maybe the scheme through the SOCKS protocol which isn’t much more complicated.
When the addresses changed from v2 to v3, for programs interacting with Tor in this way, the only thing that changed was that the address just became longer, and that’s it. Nothing else really changed.
Therefore, 99.9% of programs that work through Tor just updated a few lines of code.
Does Zcash work differently? If so, what is the main idea behind Zcash’s interaction scheme with Tor?
With this approach, what’s the point of even being here, if you don’t mind me asking? It’s funny to imagine that Zcash developers might share the same mindset. 
1 Like
(I think) Zcash forked Bitcoin before it had support for Tor, so adding Tor for P2P on zcashd would be a ton of work. Due to a ton of hard work by many people here, str4d is correct that the new Zebra code will make it much easier to use Tor for P2P.
I believe that solving for Zcash node network privacy via Tor is cool, but would be giving Tor first to the users who are the least at risk in our ecosystem: node operators.
The well-documented surveillance occurring across cryptocurrencies is light wallet servers operated by private corporations logging IP addresses and productizing that information to institutions and governments that would likely not be able to legally log that information otherwise. Notably, by the company Chainalysis.
Network privacy for end users is more urgent than privacy for zcashd/zebra operators (100 people?)
If there were documented proof that node operators were being persecuted for running Zcash nodes that would be another story. But that is not the case: it’s light wallet users (all mobile apps) that are by FAR the most at risk today.
Because I believe effort makes a difference. These are dark times, but that doesn’t mean I wont fight for privacy. Id rather be honest to those who may not know than hide the details in the shadows however.
I am forever a student, much to learn I still have, but the sooner everyone realizes there is always a bigger fish, the better. 
It seems like the right approach is to be honest with users and tell them that if privacy is important to them, they absolutely shouldn’t use light wallets.
They need to use only full-node wallets. You could even sell them physically, like Raspberry Pi setups.
Be upfront about the security holes, point them out, and close them. These are pretty basic things, really.
And the main message here seems to be: Zcash is the most private coin because of the Orchard pool. And that’s it. But users aren’t idiots. At least, not the ones who have the money to buy Zcash. That’s why there are downloads of wallets, but no transactions
2 Likes
As far as I understand, they absolutely should. Would you mind elaborating?
Great information, but the issue of light wallets isn’t really addressed there.
A wallet scans incoming blocks with transactions and looks for its addresses to understand whether they were involved in any transactions, i.e., whether funds were received by the user or sent from them. If it’s a full node wallet, it requests data from its own node, and there are no issues with this. A light wallet, on the other hand, is designed to retrieve transaction information without downloading full blocks, and certainly without storing them. In the worst case, it just requests exactly what it is interested in, which, accordingly, becomes known to the node it queries. The best case scenario would be requesting the entire block without revealing any information about itself.
However, if the wallet downloads the entire block, the point of using a light wallet is lost. Therefore, the wallet tries to strike a balance: minimizing exposure while also minimizing the amount of data downloaded.
Nevertheless, the node can always make certain judgments or assumptions about what exactly the wallet is interested in. Even if the transaction is shielded, the node may infer, based on the fact that one wallet and another wallet are querying this transaction, that it’s a transaction between those two wallets.
In this document ( Addressing Network-Level Threats in Zcash Using the Nym Network), from this thread (Revised Nym for ZCash Network-level Privacy - #28 by mxx) Anna claims that in Zcash, node can make not just an inference about the ownership of an address, but know for certain. (see section: Compromised lightwalletd server - Threat to Light Clients ) As you can see, I’m asking wallet team how this works
Ok but if I use a VPN, or better yet, Tor, that does not tell the lightwalled server anything that can be used to deanonymize me and that’s the important bit here.
If I run my own node and I send transactions from it, it will however definitely enable chainanalysis to link my wallet, to an IP I control, to potentially, my identity. That’s what the op of the thread I have shared above is explaining.
If we are to succeed, it is critical that a granny using Zcash can benefit from the maximum privacy we can provide without having to double-think anything. Lightwallets behind VPN or Tor are providing that quite effectively as far as my understanding goes.
Zcash’s P2P protocol is based on Bitcoin Core 0.11.2. At the time, Bitcoin’s P2P protocol only had space for IPv4 and IPv6 addresses, but Tor v2 onion addresses were short enough to fit into an IPv6 slot, so that’s how Tor support was hacked into Bitcoin. Zcash had this support either at launch or close to it (it’s been a decade, I forget some details).
The Bitcoin P2P network protocol was later updated with support for much longer addresses, which enabled Tor v3 onion service addresses, I2P addresses, and others. Unfortunately this was implemented upstream after a long and significant refactoring of Bitcoin Core’s entire networking stack, meaning that it was not a simple backport for us.
Zcash still however had Tor support in its full nodes like zcashd and its P2P layer up until Tor v2 onion service support was disabled in the Tor network.
Thank you for the explanations! It’s definitely clearer now. I understand that answering users’ questions is not part of your job, but I can’t resist taking the opportunity. A document was shared above [Best Practices for Shielded Note Management and Networking Considerations], and it says:
In the future perhaps we’ll see Zcash nodes implement a gossiping protocol like Dandelion, which introduces delays between gossips in order to thwart these kinds of gossip timing attacks.
Is that true? Does Zcash not use anything like Dandelion or similar? Are transactions broadcast “in the open”?
1 Like
The problem is not network security, but the fact that your transactions are linked to each other and to other users of light wallets. This is a very serious vulnerability. It’s almost as bad as not using Tor or a VPN.
If granny uses her own node and it works through Tor (I haven’t considered any other option), then:
- She doesn’t have problems receiving transactions. Her node simply downloads blocks from other nodes, and they are indistinguishable from each other.
- There is a potential problem with sending transactions: if her node has been connected to a Chainalysis node for a long time and she’s sent several transactions, Chainalysis might figure out they all come from the same user. If one of those transactions involves her personal account on Binance, it’s not great for her. This problem can be solved by reconnecting the node. For example, she can send the transaction, then reload the node. Moreover, in blockchains where user security is a priority, various tools are developed to mitigate this risk.
If granny uses a light wallet:
- She has a problem with receiving transactions. The wallet inevitably shows the transactions to the node it interacts with. There’s nothing she can do about it. Yes, nobody will come right away if she uses Tor, but the attack vector I mentioned above exists: the connection between her transactions.
- She has the same problem with sending transactions as in the case with her own node, because the company providing the light wallet and the nodes it interacts with, just like Chainalysis, can see who is sending what to them.
This applies to desktop light wallets. On a phone, it’s even worse.
At the same time, there are no issues with using a full wallet and avoiding unnecessary risks.
Thanks @postfix1 for explaining your perspective on this, I appreciate.
Then you proceed to tell me two things a granny would most definitely never ever do. 
Either way, it’s still interesting and I’ll think about it some more for my personal use cases, thank you.
To me, assuming I understand you correctly, the highlight of what you are saying is that currently Zcash is not that private by default (using say Zashi). I thought using such wallets behind Tor was sufficient to obtain the maximum privacy offered by Zcash.
I’m curious to read more expert takes on this matter quite critical to our project. If what you say is correct, we should have a plan to address this over the long term, but also some high quality documentation to explain how to transact with maximum privacy.
This is false. The light wallet protocol (as we designed) uses a broadcast channel for detecting shielded transactions: the light client downloads a compact form of all blocks and looks for their shielded transactions locally, so the light wallet server cannot from this connect your shielded transactions together.
The receive-side part that reveals to the lightwallet server which transactions the wallet is interested in, is “enhancement” (specifically, the act of fetching memo data; excluded from the compact blocks for bandwidth reasons). You can avoid this linkability in several ways:
- Don’t fetch memo data; this part of the light client protocol is optional by design.
- Pay the higher bandwidth cost of downloading all memo data.
- Enhance the transaction over Tor or similar. You need to take care to avoid temporal linkability, but it’s much better than direct enhancement. This is what we’re deploying soon in Zashi.
- Use a Private Information Retrieval protocol. These are more viable than they were 6 years ago when the light client protocol was designed, but I haven’t had the time to look into them myself recently.
The solution here is the same as for protecting enhancement: send transactions over Tor (as we’ll be doing soon in Zashi) or via some other network privacy layer.
Great, excellent if that’s the case! However, i described the general problem of light wallets. The point of them is to be as user-friendly as possible while minimally loading the network. These goals are inevitably achieved at the expense of reducing security, because it’s always less inconvenient to be secure than to ignore it. I don’t think you would deny that this is the case, and that a full node wallet is safer than a light wallet.
Every team that develops a wallet and is concerned with user privacy issues tackles this balance between security and convenience with varying degrees of success. I haven’t heard of this problem being fully solved 100%. There’s always something that a node can analyze—sometimes the wallet keeps requesting certain blocks, sometimes the wallet starts querying the node when it expects a transaction, sometimes flaws are found in the filters, and so on.
And now the question: why think about all this if security is more important to you than usability? You can just use a full node wallet.
As for Zcash light wallets: I don’t know the exact flaws they have. I think there are many flaws, based on:
- The expert’s report, the link to which I provided in the previous post.
- The fact that a so-called “private” wallet is distributed without network security tools. This speaks volumes about the developers’ attitude toward the issue.
And one specific developer team is very distinctly characterized by the fact that their website: zingolabs.org is blocked for viewing through Tor. (Meanwhile, in our days, even toy stores make Tor-friendly services)
In other words, ZingoLabs is not at all welcoming to all those geeks who love privacy and to hide themselves in the network, damn them.
I’d like to ask ZingoLabs: Guys, what’s with the hostility? Who wronged whom first?
And, of course, there’s the question hanging in the air, but I won’t voice it.
@str4d I assume you’ve seen the thread I’ve posted before (and below); I would be curious to know how accurate you believe it is.
I’ve used Zcash since day 0 and since that post was shared, I have diligently followed its recommendations. However @postfix1 doesn’t seem to agree with it and this feels important enough to clarify for the benefit of the community at large.