Thanks for reporting that! And to corroborate: I found a 2019 paper that explores some of this network graph analysis category of attack:
https://arxiv.org/pdf/1907.09755.pdf
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.xto 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? 
)
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.