Is Zcash actually quantum private?

I have thought of this.

What’s left is the discoverability, by one or more other Zcash nodes, that the IP address your node uses (‘node’ meaning node-specific identifier(s) broadcast on the network I assume - nothing to do with zaddr) created a certain shielded transaction (which, if they don’t know a zaddr pertaining to that TX, they can’t glean anything extra than anyone else trying to analyse the blockchain - but they do have a new extra facet of IP address signature).

The source of this in official docs:

If they continually collect this p2p off-chain data directly gleaned by their node(s), advanced Network Graph Analysis, correlating other non-Zcash data (IP address data) could over time perhaps link transactions. (E.g. via pattern of IP address - the fact that 23 of today’s 123 shielded ZEC TXs used a Tor IP is something that links those TXs together. But they would have to directly connect to enough nodes to scientifically make an accurate pattern analysis judgement. But it can be used as a mechanism to potentially link any two TX together in isolation if they are doing continual malicious Network Graph Analysis, and who knows how many others are using zcashd on Tor right now? Maybe it’s rather small number within the shielded ZEC pool at this point.)

Since doc uses plural (sends the transaction to other **nodes**), and it would make sense for efficiency to get TX confirmations as reasonably quickly possible, I assume zcashd by default tries to connect to multiple nodes (keeps directly connecting to more if you leave it running).

Two things I’ve concluded one can do to minimise this particular risk of malicious data collecting nodes:

  • Like docs say, connect zcashd via Tor, it’s the best (publicly accessible) IP address anonymity set I’m aware of. (Arguably by this point, Zcash’s quantum anonymity is greater than Tor’s quantum anonymity, to a global passive adversary, who probably has their fingers all through Tor - that’s very impressive BTW, to say that something inherently gives (or can give) more anonymity than Tor itself possibly can. Tor is as quantum-weak as Monero. Zcash is a freak! May it gain more recognition.)

  • Minimise this attack surface by turning off your zcashd node as soon as one confirmation is seen in your software. Untested by me yet, but I assume that one adjacent node usually will manage to propagate the transaction themselves without you needing to still be online. Just reconnect zcashd if after time no further confirmations were propagated.

Further things I will privately investigate for minimising zcash node surveillance:

  • If there’s any cli argument to limit network connections to X nodes, e.g. only 1 at a time. (If not, one could code up a custom zcashd fork if they have the resources - this would be bit like third-party BitTorrent clients that work with the BitTorrent protocol but don’t follow the usual protocol-intended ‘rules’ (or guidelines) like seeding back and demanding / rewarding certain seeding / swarming behaviour - ‘leech clients’.) This idea is a little like a certain Tor feature BTC: most Tor client software is configured to have client stick to only ONE entry (guard) node (the most immediate node touching your naked IP address) and rarely cycling it, to decrease your probabilistic chances of having a malicious (spying) guard node for any given session.

  • This should be obvious to any serious thinker: don’t use the exact same Tor exit node IP address for adjacent transactions. (Reduce linkability of multiple TXs you do to a mere pattern of ‘Tor IP address’, not the potentially unique linkability of ‘THIS specific Tor IP address’. Restart Tor daemon before the next TX, and more hardcore step, only use any zcashd node (broadcasting unique identifiers on the p2p network?) one time, for one transaction only (or two times, one in and one out - i.e. minimally). Appear as multiple people, not one person. Make your zcashd instances disposable. This only matters if you care about malicious Zcashd nodes surveilling by collecting this off-chain data.

  • Also I wonder if cli allows an option to ONLY connect to one specific node on the network (specify it by hash etc)? Then you could run a second node yourself, which does the (first) confirmation then spreads it out to others, and which doesn’t collect your original transaction/IP linkage since it’s you performing that confirmation. (You can also run this second node on Tor. I assume Zcash protocol traffic is encrypted and not sniffable by malicious Tor exit nodes.) However, can other nodes probabistically guess that the second node is actually you (even if it’s not the node that created the TX), if you operate such ‘second nodes’ with a repeatable pattern over time (or via some other mechanism - e.g. does protocol announce which node identifiers created which numbered confirmation [which would be terrible for node privacy])? If attacker runs several/many nodes in the network, perhaps they can determine the likelihood a particular node is somehow closely / directly connected to the original transaction sender, because no other node is delivering it to their multiple nodes in real-time? I’ve not studied particulars of Zcash network protocol - is it similar to BitTorrent which makes it possible, via at least one real-time observational technique, for peers to know which specific peer was the original seeder, if they were there at the right time and logged it? (Mitigation perhaps, and not perfect: close off your second node as soon as THAT garners at least one confirmation from someone else. Make a ‘random’ third party node be ‘the source’ after that, which is neither you/your IP address signature pattern, nor the node noted as having created the TX, and will ‘randomly’ be a different node on the network to scramble the IP address signature as randomly as any other transaction already would be - it retains a ‘ghost’ source of the TX on the network, if no one ever saw who the original node was apart from you. But that assumes confirmations on the network don’t broadcast the ‘order’ of confirmers or something similar. (And not perfect mitigation because the ‘randomly’ used third node might still be a malicious collector, who is also operating other nodes watching to analyse Zcash network activity in real-time.) Are these exact details about off-chain real-time metadata documented anywhere, so we can learn how easily an attacker can track the source and flow of confirmations of a TX on the network in real-time? I think I read all of readthedocs; I have not thoroughly read the mighty protocol.pdf, but no instance of the word confirmation in there.) I feel like this advanced Network Graph Analysis security hasn’t been explored properly by public researchers. (I didn’t see a paper so far, unless I forgot.) This is why I mention peer fundraising for such stuff.

Hope someone benefits from me having thought through this OPSEC. I know these are hardcore measures, but some people may depend on them, such as a persecuted dissident in a brutal regime being paid online by an overseas employer with high privacy so they and their family can survive. Their children may want to stay disconnected from such Zcash transactions for the next 60 years, otherwise they are tortured and killed.

1 Like

I’d be very interested in seeing adoption of Dandelion++ within Zcash as well. For now, a churn with a separate seed and Tor circuits…

2 Likes

Thank you for writing it up. There is lot of great information here, would you mind sharing them as tweet threads (quantum resistant & about churn)?

1 Like

Sadly I have no time to blog (even if someone paid me), at least I’m sharing here. :slight_smile:

1 Like

I run a zcashd node with tor.

The current assumption is even if an entity was able to track broadcast transactions to the tor exit IP, it would be very difficult to find the true original source. Of course if tor was ever broken or the entity could see the whole tor network chain, then maybe it would be possible to link to the source.

I believe you are correct - a higher level anonymity would require new tor connections and routes to be created after each broadcast to randomize the connection more. I guess we could look for zcashd to receive instruction to broadcast a high-security z-z transaction and be told to execute a script instructing a system to use a new tor circuit and reconnect to a new random node, broadcast the transaction, and then do it again…

Zcashd does support limiting how many connections and which peers to connect to. This is in the zcashd.conf documentation.

I am not sure if Zcash has encrypted the broadcast transactions; I know that if they are or aren’t, the data is still protected by digital signatures. I have previously come to the conclusion that like many private messengers, the application helps with privacy, but not necessarily anonymity. There is a paper that talks about this here.

3 Likes

Thanks, noted! So if there is a difference between a node seeing a transaction from the original source (looking for a ‘first confirmation’) vs. another just passing it along - if that’s how the protocol works - then using connect=X.X.X.X to use a specified, sort of second ‘guard node’ to protect a third party malicious node from sniffing your ownership ‘transaction originator node’ is how to plug that.

What then remains to be known by me, first is whether Zcash protocol has nodes tell other nodes whether they’re the ‘1st’, ‘2nd’, ‘3rd’ etc. node to have confirmed the transaction or not. Perhaps what you say below indicates that’s not the case - it’s just a hash once created by first ‘confirmer’ (for lack of better term), passed around to other ones in a way that doesn’t reveal who’s ‘first’, ‘second’, ‘third’ confirmer etc:

But secondly, even in that case, an attacker with enough malicious nodes recording the network in real-time could probably probabistically determine that your self-controlled second node is you, and thus your TX is still fingerprinted to ‘Tor IP zcashd node’ as a traceability vector.

Probably we have to accept this weakness and just do Tor circuit changing and existing OPSEC (like what I’ve shared such as scrambling and spacing out your timing, and the above idea I’ve notes to turn off all self controlled nodes ASAP once confirmed once) to be enough. We can’t do any better.

Final frontier to address leakage of IP address to well-resourced adversaries, as you say, seems to be mix networks:

Sadly, implementations of mix networks have been around since at least the 90’s, but even Tor hasn’t implemented anything as anonymous as that. (Wonder if Loopix can change that?) Clearly not enough people have been unmasked by adversaries (yet) to demand such a mix network-operated coin exist. (Or a regular web browsing Tor replacement.) Maybe hardly anyone has been unmasked by Tor-level anonymity, so for now, other OPSEC mistakes or exploits are what undermine someone before their need for a mix network emerges.

Thanks for sharing!

2 Likes

A very quick check of the source code indicates the node that gets the transaction checks validity and if valid, just forwards the transaction and not how many hops or other nodes have received the transaction into the mempool.

The steps you’ve outlined and as outlined by ECC for security considerations are correct - larger value stored in pool and send smaller amounts, spaced out timing for transactions, not sharing transaction details, and protecting IP addresses. Privacy Recommendations and Best Practices - Zcash

There is a project working on enhancing an onion routed network at the IP level called “Lokinet” that tries to avoid letting “global passive adversaries” take control of nodes because there can be high costs to run such nodes with risk of losing those funds if found to be misbehaving. It is far from ready for prime time and runs on privacy based blockchain technology (Oxen - originally forked from Monero).

3 Likes

Thanks for reporting that! And to corroborate: I found a 2019 paper that explores some of this network graph analysis category of attack:

It states e.g.: validation time seems to be a good indicator for the number of hops - but it’s close-range timing analysis only.

They don’t show a serious attack IMO - it’s only that a low-resourced attacker from anywhere in the network can map out chains between nodes for a given block/tx, to some extent, back through the chain from their own node(s), but with only “precision of 50%” - and not necessarily unmask which exact node originally created a block/tx (see below for my analysis).

But it made me realise the following:

Zcash’s privacy is not as strong as the quantum privacy of the blockchain graph data: it’s actually as weak as the monitorability of its real-time p2p network data. Obfuscation of a TX sender node’s IP address (as a significant fingerprinting or TX linkability vector) is more important than I thought. Under the current protocol design, if you want to take measures to achieve this, it’s currently doable (continue reading), but means longer confirmation times for your transactions.

In any case, I say it’s safest to always use stream isolated Tor IPs on your nodes - no other type of IP address can possibly be a more anonymous pattern of IP (as we don’t know what other people are using, whether it’s VPNs, university IPs, proxies, residential IPs, hacked IoT botnet IPs, or almost never any of the above), but we do know Tor is officially encouraged, built into the client as an easy setting, so that’s a known IP pattern to blend in with. (Perhaps non-Tor IPs for isolated churns/TXs/purchases have their place sometimes, if you only use such an IP fingerprint one time. But that opens can of other worms in OPSEC depending on your other Internet usage and your threat model, so in general I’d recommend only ever use Zcash on Tor.)

But I think my idea of using a second self controlled, exclusively connected ‘guard node’, which isn’t detectable as the original creator of your transaction, has benefit.

The paper’s core idea:

Seems to me that no single node can necessarily connect to all other network nodes simultaneously.

So I’d suggest a serious user does this:

  • First zcashd node (which creates the outgoing tx), use connect=x.x.x.x to only connect to your second node’s IP (guarantees absolute privacy of sender node’s IP address)
  • Limit your second node to only connect to ONE other random third-party node on the network (I think do -maxconnections=1? not tested by me yet). This way, limits the chances of connecting to a malicious node to only 1 out of all peers, instead of much more.

Then - unless your second node is very unluckily connected to a malicious node - you can be a true ‘ninja’ on the network as a mystery sender. Who knows what precise node originally created that TX? Only your own second node can possibly know. After that, perhaps there’s enough deniability statistical improbability of source point to hide in the crowd. This especially helps to mitigate the fact there’s currently only ~100 fully shielded TXs to hide among per day right now. (Not many IPs to hide in - let alone other nodes using the same IP fingerprinting of Tor - so let’s not make it possible to be observed what IP we’re even using, when we send a TX. Feel’s kinda Zcash style anyway, right? :slight_smile: )

Even if your guard node connects to an evil one, perhaps they aren’t connected in real-time to enough nodes in general to confidently conclude that your guard node is the ‘source’ of your transaction. They’d have to be operating many sinister nodes to map out everything in the brief moments while your TX is confirmed.

But: is it wasted effort to do this ‘second node’ thing? I’d need to study BTC’s technology more (upon which ZEC is based)…I see Zcash has inherited BitCoin’s ‘trickling’ feature to mitigate peer discovery of which node created a transaction, even if the transaction is brand new with 0 confirmations. But unless I know that by default Zcash is bullet-proof in making a sender node being 100% indistinguishable from a subsequent confirmer node, to a directly connected malicious peer, I’d stick with my idea, even though it’s extra work. At least it shields discoverability of sender node IP from the entire network.

Zooming out, alarmingly there were only estimated 300-something zcash nodes in 2019 by those researchers. Cant imagine it’d be above 500 now. Many large entities (corporate or government) could easily add at least that many evil nodes, to make it 50% likely you would connect to a malicious node. We’d need to watch out for this happening at all times, though it must be difficult to know for sure so true IP mixing and latency fuzzing would address that.

Solution for now: just keep using Zcash, thank you Edward Snowden for the continued shout-outs, please ECC continue to make Zcash more Monero-like (e.g. actually do a non-trusted setup for NU5), then more Monero Torheads will jump on board and make that anonymity set bigger. I’m just one of them.

2 Likes

I believe Zcash aims for privacy and not anonymity.

To quote a Google web search answer to “anonymity vs privacy”…

Privacy is the ability to keep some things to yourself, regardless of their impact to society. … So privacy is a concept describing activities that you keep entirely to yourself, or to a limited group of people.

In contrast, anonymity is when you want people to see what you do, just not that it’s you doing it.

Zcash would say it is like HTTPS - That is once you establish a secure connection, seeing or modifying the contents is private. However, this doesn’t stop the ISP and server from seeing that there is a connection. But just because there is a connection, no one can tell if you are sending nothing or a large sum of coins. Hiding that connection would be more so about anonymity which is something sort of tacked on by using external methods like Tor.

Sure you can attempt to obfuscate your connection/broadcasts, but without Web 3.0 methods of decentralized network connections with privacy, it will be possible to eventually link a connection to the source with enough time and resources.

I think this complexity is beyond the scope of the Zcash project. Instead it can rely on other projects (Loki, Nym, etc) or methods to create more anonymity on the network layer. As for quantum security, this is still pending an adoption of quantum Key Exchange and Signatures, possibly in a future pool as Zooko previously mentioned.

I think as of Jan 2022, there were about 263 nodes and over 75K miners that I could be publicly counted. I would like to see a more accurate number if possible. Transactions are relatively low, but I expect that as Zcash is still not in the top mainstream and is used more of a store of value and investing than for multiple/quick transactions.

3 Likes

Yes the two are fundamentally different, and sometimes the symbiosis / clash between the two can be complex / frustrating (respectively).

What I think, based on what I’ve learned so far:

  • The word ‘anonymity’ has a bad wrap. It’s associated with criminals, darknet markets, cybercrime, ‘hackers’, etc. (Thanks, media, for perpetuating those negative tropes, definitions, associations). The word ‘privacy’ is much less taboo, thus used more often, including when really they actually mean anonymity, or anonymity in equal measure. It’s proudly used with moral dignity by commercial VPNs and many businesses / orgs, who say it’s ‘a human right’. Not so much the ‘a-word’. This inequality of attitudes towards the two concepts might slowly change, e.g. increasing legal human rights in Europe of ‘anonymity’ just like ‘privacy’. ‘Anonymity rights’ NGOs might emerge in future, defending it and promoting why it’s important. (Tor certainly has found a voice for that message, and EFF - e.g. anonymity helps domestic violence victims, whistle-blowers, etc.)

  • The way I see Zcash: it uses privacy as the mechanism by which to achieve anonymity (in addition to privacy). ‘Financial privacy’ on a blockchain means ‘anonymity’ of public transactions to an outside looker (or, even to who you’re transacting with, at the blockchain-level). Speaking to above point, there is unfortunate legal stigmatisation of ‘anonymity’ in the context of money. Anti-money laundering laws (AML) in certain jurisdictions literally outlaw obscuring the source of any money, even if the origin is legal.

Zcash has already implemented ways that allow a user to comply with AML (view keys, memos etc.), which I hope suffices on-ramp/off-ramp exchanges obsessed with risk. But to grow the user base, IMO, the feature of ‘anonymity’ should be openly promised by Zcash as a positive, and not necessarily illegal thing (for a user to do or the project to promote). Just market the ability to comply with AML as strongly as the selling point of anonymity.

Additionally, z.cash (and every official associated domain like this one) should offer .onion Tor hidden services to put its money where its mouth is. You’ve donated to Tor so far, I hope you can consider that too! Like getmonero.org

I’m still a crypto newbie but looking at Zcash historical price graph vs. ones like BTC, it seems relatively stable over the years apart from a 2018 spike. Doesn’t that show it’s being used more as a regular transacting coin by a certain-sized base, not so much as a volatile investment coin (like BTC)? (Hopefully many of them doing it specifically for the financial privacy, whether perceived or real…) To me, the stable-ish price looks healthy, so I’m motivated to both use regularly for financial privacy and to hold funds in long-term.

(Note the subtle difference between investing in and storing money in Zcash? Maybe that’s a winning strategy for this coin. It’s a true digital cash - who wouldn’t feel safest storing most funds in this less volatile coin as if it’s their bank account, as separate from risk-bearing investment like BTC?)


I guess not many, if any, have explored advanced mitigation of surveillance nodes on the Zcash p2p network. I will implement what I thought of above in my OPSEC.

2 Likes

This is basically my personal opinion -
Supposing a quantum computer capable of factoring large public/private keypairs is built sometime in the future, would Zcash transactions be at risk of deanonymization through an adversary decrypting all the shielded transaction information?

I looked for information regarding how the data is encrypted on the zcash blockchain but found no exact details on the algorithm used. I assume it is some commonly used public/private key algorithm, which would make it quantum vulnerable. Is this the case?

The reason I’m concerned is that the blockchain is forever. It is easy to wave away concerns over quantum computers, as actually, useful quantum computers may be decades away. It is easy to just say “we’ll change the algorithm to a quantum secure one by then” and be done with it. Basically, I am a blockchain lover so I started reading and developing all the blockchain-related things alongside developing cloud erp adoption. And for concerns such as an adversary spending other peoples’ coins or minting fraudulent coins, this is a valid response. We don’t have to worry about that happening until someone actually builds a quantum computer.

But post-quantum deanonymization is something we have to worry about now. It would be possible for a government agency to store the blockchain until they develop a quantum computer, and then retroactively deanonymize everyone who has ever used Zcash (if Zcash’s anonymity is quantum vulnerable), as they have all the records of every transaction already stored, just waiting for the technology to come along to process it. Even if Zcash updates to use post-quantum crypto at some point in the future, all transactions made before that point will be vulnerable for all eternity.

Is Zcash’s anonymity quantum vulnerable? I’m not as worried about Zcash itself being quantum safe (as the possibility of a quantum computer equipped attacker minting new Zcash is something we don’t have to worry about until a quantum computer is actually developed that can factor keypairs), just the anonymity aspect of the information stored on the Zcash blockchain.

Lattice-based cryptography is the generic term for constructions of cryptographic primitives that involve lattices, either in the construction itself or in the security proof. Lattice-based constructions are currently important candidates for post-quantum cryptography. Unlike more widely used and known public-key schemes such as the RSA or Diffie-Hellman cryptosystems, which are easily attacked by a quantum computer, some lattice-based constructions appear to be resistant to attack by both classical and quantum computers. Furthermore, many lattice-based constructions are known to be secure under the assumption that certain well-studied computational lattice problems cannot be solved efficiently.

Hope this article will help you.

1 Like

Hi owenj7920. The Zcash protocol specification can be found here: https://zips.z.cash/protocol/protocol.pdf. It is updated regularly and very thorough/detailed.

The question comes down to if/when quantum computing can crack key exchange and signatures, are any shielded transactions with exposed transaction IDs, z-addrs, or viewing keys actually exposed or able to be compromised? Would this equate to the same transparency as t-addrs like t1PKBiv7mtzD9bNafYaqyxaENeiNDbpKxxQ - where all transactions and values are shown and potentially leaked? I guess a challenge for an attacker would be who owns the addresses. I assume it would eventually link to a regulated exchange unless someone used decentralized/anonymous exchanges.The attacker would know how much ZEC and when it was moving; possibly with enough resources and access could correlate a node and IP address that wasn’t tor’d.

Quantum computers already exist, but not large scale enough to crack existing cryptography. At this time, the underlying symmetric methods are still considered secure vs large quantum computers with the recommendation to double the key size to increase long term strength.

Since this crypto is so widely used everywhere, we can be assured there will be global news and alerts from pretty much every secure web site/bank/healthcare/government/cryptocurrency for users to take action when this becomes an issue.

Ignoring public t-transactions that can be seen anyway - Sapling and newer [Orchard]) should be secure against quantum attacks given the public key (z-addr) is not exposed. Since the block chain does not record or see these shielded addresses, public key exchange attacks are mitigated. However, if someone publicly posts their z-addr without taking additional “churn” steps, it might be possible to link/spend some transactions in the future if the cryptography methods are cracked.

ZIP-316 (Unified Addresses/Keys) isn’t here yet (until NU5) but it seems to move things in a better direction - requiring at least one private address by default and an algorithm to protect against key replacement. I’m not sure how much protection these new addresses provide (if any). They appear to be encoded with bech32[m]. From Bitcoin taproot discussions, they advice against address re-use (public key for the spend is broadcast in transaction), but ECC/Zcash official say it is safe to re-use Shielded addresses.

Since we can’t count on people keeping their z-addr’s secure, moving funds into a new pool (sending to a new address format that supports post quantum resistance) will be the recommended action; but we are far from that as official protocols and methods are being finalized (globally) and the timeline for a successful attack is expected to be 10-20+ years out.

1 Like

At this point, I wouldn’t broadcast TXs through the node at all. You can proxy the RPC so when broadcast is called, your own script hooks into Tor and directly sends it to peers it knows of thanks to your node. That way your node isn’t flickering as you change circuits and you aren’t modifying it either.

This may be exactly what you’re suggesting (you did suggest an external script, yet via zcashd while reconnect suggests suggests your node DC’ing and therefore still managing these connections), and sorry if so. Just wanted to chime in myself.

If further anonymity is wanted in zcashd itself, which I am an advocate for as I believe anonymity is a part of privacy and anything Zcash can do to improve its privacy, the better, I’d recommend Dandelion++ which would help hinder network level analysis to note originating nodes.

2 Likes

Sounds interesting, but I’m confused. (A zcash-cli one-liner + what config to add would elucidate.)

Do you mean it’s possible to send an outgoing Tx’s tx message data directly to other nodes, in a way that bypasses your own full node, so that - (and you’re asking that) - THEY broadcast the very first inv message - and not your node? If so, how is that a privacy improvement over broadcasting from your own node? Surely spying nodes can see your Tor IP sending a request directly related to your outgoing Tx? And isn’t it a worse kind of communication because those nodes objectively KNOW your message is from the ORIGINAL Tx creator (instead of there being some deniability as to your IP being the original sender’s node under normal conditions)? And in other ways, could it create other extra unwanted fingerprint in terms of p2p network activity? (Fingerprinting principle: never do anything unusual or different from the software default method, at least if the difference is detectable by your threat actor.)


Also, I discovered the other day that there are only ~270 nodes on the network at present correction, just 206 on current block height, and thus participating in new transactions. That’s a woefully small anonymity set for a privacy coin, in terms of network-IP-address-to-Tx-sender unlinkability.

Source: Zcash / Node explorer — Blockchair (Comparatively, BTC has 100k nodes - nearly half of which may be on Tor IPs! - Monero 2.7k nodes - Tor has ~7k)

Among other things discussed, Zcash should donate to projects that specifically run non-malicious Zcashd nodes as a pure community service, just for making it harder to link transaction senders with node IPs on the network. (Similar projects have alredy been funded.) IMO, non-sexy but directly impactful things like that are what wins over Monero types, and turns around the bad taste many people have had regarding the centralised and for-profit nature Zcash launched with and still has in multiple ways pre-Halo 2. Perhaps the Grants fund should be more decentralised, even DAO-style - community voting of projects if you stake some ZEC. Then the ideological, less pragmatic Monero types at least feel in direct control of what happens to the biggest share of - (40% of) - Zcash’s 20% mining tax.

Regardless, Zcash remains an unusually powerful ‘ninja’ privacy tool - a real black hole - for those wanting to properly anonymise any other coin, including Monero. I’ll be storing money in Zcash, potentially in big amounts, both to store funds like a bank account, and as an investment. My instinct tells me this coin is going to pay off hugely in the next 1-2 years, I just feel it. Good time to buy right now too. :slight_smile:

So in time I will try to implement my node OPSEC to allow connection to only one random external node (and this being my second ‘guard’ node itself - I’ll use TWO nodes, two layers, to more stealthily broadcast a Tx to increase murkiness of origin node). I’ll have to research what upstream BTC community has explored regarding network graph analysis, and what practical measures BTC users have come up with for current BTC protocol. This is why Dandelion++ (etc.) should be implemented already, like yesterday. Is there a grant proposal for that work, or is ECC serious about implementing it with their own funds?

I now see Monero has at least TWO major features mitigating live network tracing that Zcash currently doesn’t have:

  • Dandelion++
  • Working functionality to run your node as an .onion service - AND - to ONLY connect to other .onion nodes. (There’s enough Monero Hidden Service nodes for it to work, see https://monero.fail/?onion=true for a live list.) This makes discoverability of a node’s IP address much harder - no visibility of a raw IP to any adjacent node - it’s a random .onion address, and it might be a one-time / disposable one! Onion node option is enough in fact to make Zcash’s low node count a much less dire problem. Since nodes can choose to connect to BOTH .onion and non-.onion peers for relaying transactions, even if there’s a tiny amount of .onion nodes, users can benefit from the whole node pool size: the extra fingerprint of ‘this is a very rare node that is an onion address, and this tx is most likely sent from such a very rare type of Zcash node’ is a heuristics linkability problem only if your threat actor runs many highly connected Zcash nodes which are surveilling p2p activity 24/7 - and there’s still some deniability in that case.) Sadly, Zcash’s nicely documented offering of this feature seems currently broken (Tor is v3-only now). That should be fixed ASAP, and certainly in time for Halo 2, so that the new shielded-ZEC-by-default design(?) and the new non-trusted setup(?) also come with .onion node creation being default for ALL Tor users out of the box, to really make more people consider Zcash again.
1 Like

My comment is about using unique Tor circuits to broadcast transactions. Some IP has to be the originator and a fresh Tor exit node is the best choice available for that. The issue, if you run zcashd behind Tor, is that you don’t get fine control over its networking and your best way to force it to have a new connection to Tor is to reboot it entirely. This can be disruptive and also raises its own metadata questions (as a node is going offline immediately before broadcasting just for a new node to come online and broadcast), yet if it’s solely behind Tor those may be considered negligible. I’m just discussing what the best path is, even if others are probably fine.

So if you want a fresh Tor circuit, without constantly rebooting zcashd or extensively modifying it, you want a separately run app entirely to connect over Tor, ensure uniqueness, and then broadcast TXs. This still could be a zcashd instance (boots up, presumably on a sufficiently unique circuit, broadcasts, killed) or a custom script which better integrates with and manages Tor, providing guarantees accordingly. So if we do write some Python script to handle this, the problem is you can only send transactions via some custom Python scripts where you have to manually ferry the bytes and…

That was the rest of my comment. You can have your Python script proxy zcashd’s RPC. Any wallet using the RPC to send transactions would have those calls intercepted, broadcasting TXs over fresh Tor circuits by the Python scripts. All of your other messages would still hit zcashd though and your wallet wouldn’t know the difference.

It’s the unique circuits part that makes this a better solution. Again, it’s probably fine just to have zcashd behind Tor as it should handle circuits per-socket, not per-app, meaning a few nodes will see your TXs from a few IPs already. The problem is when you do your second TX that will also be seen by a few nodes by a few IPs. Overtime, this could allow determining a series of TXs as all being from the same sender, despite coming from multiple Tor exit nodes. I’d have to check how frequently Tor rotates circuits, yet too frequently and you’ll have network stability issues, hence my commentary about a separate program effectively integrated with Tor which only lives for a few seconds for each individual TX.

I’ll again say Dandelion++ would also be a good step forward, and zcashd can do a lot with Tor itself to resolve these problems. My commentary about an additional service is because zcashd doesn’t and it’s much easier to write a script than maintain a fork of a large codebase you can’t quickly edit the networking stack of without risking ramifications. That doesn’t mean zcashd shouldn’t. Our grant to Arti should open this doorway more in the future, yet Arti has some code out we may be able to already work with, and failing that, we can even just work with the existing Tor codebase on these goals.

2 Likes

Right. Yeah, if you’re sending lots of transactions very close to each other, a script to force circuit change of course sounds useful.

Today I checked this - to chec my own node’s IP. It cycled through 5 IPs in the space of 6 minutes. Quite fast, must be the new connections which Tor keeps building new circuits for (new zcash peer adds, perhaps). Steps to collect changing IPs and timestamps: I temporarily added -listen -discover to my usual zcashd command, then it’s in log file in datadir, or while running: do tail -f 'debug.log' | grep advertizing

However in my use case so far, I will only be doing spaced out transactions for higher level anonymity (to thwart timing heuristics), so automation speedy circuit changing isn’t necessary. My OPSEC requires more spacing than that due to the extremely small anonymity set in terms of Tx timing heuristics. So things are fully manual - I lerrrv firing up that Z :heart: terminal, never gets old!

So in my case I have decorrelation between circuits between transactions due to Tor having been fully stopped and restarted between transactions anyway. I shut down Zcash, clear Zcash logs in case it helps (probably doesn’t but takes one second), reboot system (e.g. clear things stored in memory), and make sure a new Tor circuit is built, for the next time I fire up zcashd for the subsequent transaction.

(BTW, for more advanced Tor circuit differentiation, whatever the tempo of circuit change: rebooting Tor circuit only changes Tor’s middle node and exit node - not entry (guard) node. Against an advanced attacker watching guard nodes as well as exit nodes and capturing traffic for packet size timing analysis etc., to have all 3 nodes changed, delete Tor’s state file then restart Tor.)

What’s more alarming to me now - I’ve been learning just in the last few hours, and I’ll move this IP address surveillance discussion into a separate thread, perhaps tomorrow - is the simple fact of using Tor IP in Zcash, period - even if your Tx’s have decorrelated circuits. The FACT of Tor is a linkability signature in and of itself. Still better than anything else unique or static like your own VPS, but it means Tor doesn’t magically remove traceability of your ZEC, if almost no one else among Zcash nodes is using Tor as well.

Take a look at https://api.blockchair.com/zcash/nodes - NO Tor IPs are in that list! Clearly it’s not complete data since there’s at least 3 of us on this thread using Tor IP full nodes ourselves (either ninja style, i.e. node on and off, or 24/7) - and I’ve put in plenty of hours running zcashd so far - always on Tor, 8 peers connected etc). More investigation is needed to know the reality more, I’ll share my own findings in the breakout thread.

Perhaps you could try running this tool if you’re interested. I’ll try to run it for a few hours to see what peer IPs I collect, looks like a practical way to do it.

If our own peer scraping confirms there’s hardly any Tor IP Zcash nodes, it’s a disconcerting discovery. But am I going to abandon Zcash? OF COURSE NOT! By us sticking around and sharing how we use Zcash, lurkers will feel more confident that we can help cover their own Tor usage, and then vice versa. I’ll just implement my 1-peer-connection-only, super ninja zcashd method sooner than I planned.

I believe in good crypto.

I would be interested in hearing feedback from @kayabaNerve @Zchurn @secured2k regarding this new “node-Tor” Grant proposal:

Would node-Tor be effective for Zcash? Good approach? Worth the expense?

My hot take after 3 mins of scanning and not reading into detail: combining different protocols and things together (into one basket, nested in a way that is not compartmentalised and insulated well) sounds like a bad idea. Browser privacy (and even more, anonymity) is a nightmare. We already have multiple torified OS offerings to torify whole systems (how would this make torrents easier if it’s still Tor?) We should prioritise software like tor at the OS / non-browser level to torify Zcash nodes. One protocol (WebRTC) in the same basket (the browser) less private than the other weakens the stronger protocol (Tor). Seems complex and solution looking for a problem? What does it offer that other things don’t? Nothing spoke to me right away, just my hot take, could be wrong. One thing we need is core full, old fashioned zcash nodes running on Tor IPs (whether raw ip (v4/v6), or .onion), whose node behaviour metadata and signatures are indistinguishable from existing zcashd nodes. (Otherwise they have a distinctly different network-level anonymity set to sniffing nodes, even if also a Tor IP.) I know there’s snowflake for Tor though (runs in browser, it’s a type of Tor bridge, i.e. ‘node’ of sorts). But it needs ‘network effect’ and Zcash is struggling with its existing node anonymity set, as I’m investing currently.

2 Likes

Rotating here means at what point does it drop an old IP AND gain a new IP. If you’re still broadcasting off old IPs, there’s still metdata linkability concerns. I do understand Tor will offer several IPs and bifurcate as new sockets are created.

Full shutdowns are also valid :stuck_out_tongue: They’re just not as clean/efficient as a script could be.

The benefit to Tor even when no one else is using it is the plausible deniability by arguing no one knows how many people are using Tor. That said, yes, we should get a lot more Tor activity going. Beyond community initiatives to run nodes as hidden services, zcashd could be modified to ship with Tor so every node connects to every other possible node, not just the clearweb ones. Then again, D++.

Replied on that post with my opinions :wink: