OK, I’ve matured in my understanding of why and where churning is needed or not in Zcash. I cleaned up OP in this thread accordingly.
TL;DR: For even the highest security user, you don’t need multi-hop churning - one churn anonymises any given ZEC enough. But do chop it up, even for Z-to-Z transactions.
I mistakenly thought that there is a need to hide the zaddr of your hop1 (the initial ZEC after one churn) from people you then send the ZEC to externally - to insulate it in terms of both roles it plays, first as a recipient and then a sender.
I was thinking like Tor (or other elements of advanced IP address OPSEC), which has 3 node hops ergo 3 layers of isolation, all with purposeful compartmentalisation. In that case it’s needed because various parties see various elements of your Internet browsing at different places in the chain (such as IP address of user, IP address of website, and so on), all of which have different consequences - by having 3 stages, you ensure that generally, the first hop can’t speak to the last hop, so everybody only sees part of the picture.
But Zcash has remarkable cryptography such that you don’t need multiple, Tor-like layers, or isolation, in terms of your z-address. There’s ‘perfect privacy’ in the design - the cryptographic secrecy of the sender’s zaddr is itself a black hole. Churning won’t add more secrecy in terms of, ‘Who is the sender zaddr?’ We’re already there.
You still need one churn
It still remains that a zaddr known by anybody else - which then continues to be used on a zcashd node - is not good for the highest security user looking for the most privacy, because an attacker may try to send you transactions to that known zaddr (or do something with a known Tx still connected to your live wallet), to undermine your money’s privacy in ways including this:
-
As discussed, they can send you tracking ‘dust’ UTXOs - and it could happen at any time when you’re not expecting to receive money. You might keep on sending outputs without realising that some of it is new tracking dust, unless you diligently check your balance or UTXO count and compare that to last time,every single time you send ZEC.
-
Advanced concern, but a concern: They send you any non-dusty single input - a simple action of ‘tracking’ in the sense that the sender (attacker) knows the amount of the UTXO - and if Tx amounts and addresses are ever exposed by supercomputer/QC later on, then depending on your wallet balance at the time and subsequent Tx activity that may have spent that UTXO in a meaningfully statistically probabilistic way, attacker can trace such subsequent Tx to the ‘poisoned’ input they unsolicitedly sent you all that time ago. Stored forever on the blockchain, don’t forget.
-
They might use other newer subtle network timing attacks like in the paper referenced here (which had to be promptly patched by Zcash team). Based on other things I know, I know not to assume that a certain class of attack can’t have further variations on a theme re-emerge later, s.g. Spectre and Meltdown CPU attacks and RAM attacks like Row hammer keep spawning new variations, even after endless patches by kernel teams and firmware makers. Similarly, this same class of network traffic attack outlined in that paper might still be relevant today. It’s a big realm of attack.
This means for uber high security users: never use a recipient zaddr more than once. (Sender zaddr can be re-used, if no one else ever knows it.) Run any 24/7 full nodes with EMPTY wallets that contain no Tx’s.
Also, as a classic principle of compartmentalisation, I thought it best to have a rule of ‘1 outgoing Tx per wallet’. But this time it’s different. This is blockchain. Its attack surface is very centralised and quite devastating and the possibility of future exposure of Tx amounts and recipient addresses means that unnecessary churning compartmentalisation could only create extra metadata, where if you’re not doing it right - e.g. you’re churning the same amount each time and with obvious timing patterns - it could only bring further harm to yourself.
Best to keep your single, one-time-churned zaddr as your ‘black hole’, hopefully with quantum privacy for all your outgoing transactions long-term. Incoming transactions are more sensitive for you. Try to keep them to less often, larger amounts for highest possible privacy.
So you want to do away with classical compartmentalisation OPSEC? But my spidey sense tells me an attacker node could be sniffing for my node’s wallet to expose itself as the same sender of multiple transactions I pay for in ZEC, by using their txids garnered from external sources that I pay to - what can I do about it?
Making one extra small ‘chop’ hop to a new tiny temporary wallet just for all your outgoing Tx’s (my original idea), if it’s quantum decrypted one day, is a rare spending pattern which will make things far worse.
There is clearly a clash then between trying to protect yourself against:
-
The possible - present - real-time - active - network-level style of attack, transiently exposing links between past transactions, their nodes, and even wallets/zaddrs (depending on what other vectors they can connect together), as referenced here
-
The possible - future - static - passve - blockchain-level style of attack, permanently exposing Tx amounts, Tx recipient addresses, and Tx shielded memos as discussed here
Personally, I think supercomputer/QC exposure of Tx amounts and recipient addresses in future is a more inescapable thing than the real-time class of attack in [https://crypto.stanford.edu/timings/pingreject.pdf(https://crypto.stanford.edu/timings/pingreject.pdf).
So, my decision on the above: just use your wallet(s) in ninja mode - nodes that only briefly connect to other peers when SENDING and RECEIVING ZEC - not when merely updating your blocks or other things. My methods like -maxconnections=1, and my own ‘guard node’ peer to act as a blanket for my originating node, help mitigate that type of stuff. Yes, slower to send and receive - but like Tor’s slowness, it has a benefit.
So that’s my current conclusion. Keep ONE wallet for ALL your outgoing transactions, once it’s been churned ONCE, for as long as it has funds in it. (And begrudgingly do the best OPSEC you can in the upcoming Orchard move when deshielding.) Your final hop is still a black hole of sorts,even if certain vectors are unmasked by QCs one day.
This is why for best safety, if you’re comfortable attaching the profiling signature of ‘ZEC user’ to a given purchase / account on the Internet, instead of converting ZEC to XMR, BTC, etc., you should urge service providers to accept shielded ZEC.
Recap: Blockchain OPSEC is different, man.
Lots to learn here. Feels like new territory.
In browser compartmentalisation, you can visit just ONE website, with extremely good anonymity in an isolated tor Browser instance, if you know what to do, and what not to do. The website or the trackers on it never have full assurance that you’re not also browsing other websites in the same anonymity profile at the same time or at another time. (I probably minimise the power of JavaScript and the ad tech industry, but the larger point remains.)
On a Blockchain, by contrast - if Tx amounts and recipient addresses are exposed in future by QC - it’s different. Much more is visible and naked for the whole world to analyse. Imagine if everyone’s browser history were recorded on a blockchain - ‘but don’t worry it’s encrypted - at least right now has a supercomputer that can brute force it!’?
See how hard this is when you really take it seriously? (I know we can’t predict the future, but we shouldn’t not try to cater to it.)
Is there any inherent design change that could prevent the need for one ‘Z churn’?
I thought of a design idea, but it fell on its face. It was: Have wallets auto-flush and change zaddr (i.e. wallet keys) in the background, every time you receive funds - the entire wallet changes keys and zaddr, to one never known to other parties.
Attackers would no longer know the txids or your zaddrs to attack you with - either at network level in real-time, or via later blockchain analysis through known UTXO amounts or dust sent by the attacker. No dust relevant anymore. No churning needed. It’d clean itself every time.
Sounds amazing, but: it would be WORSE for future supercomputer decryption, as each new wallet flush would expose whole wallet amount and show where it keeps going. And there’s other fundamental problems I thought of, to do with network attacking.
I’m sure something could be thought of however. Nothing’s unsolvable.
Another little idea for paranoid users looking to minimise network attacking
Create ‘blocks’ of amounts of ZEC for different parts of your life, in different wallets. Chop up your big hop1 into multiple medium-sized hop2’s. Leave a big chunk left over in hop1 so exposed amounts can’t add up to earlier incoming Tx into hop1, then hop1 still serves as direct dark source of payments for one of your categories, until it runs out. Then you can not worry about being such a ninja node, if you don’t mind if Tx’s linked together within the same type of activity.
This is like browser compartmentalisation - different browsers for different areas of your life, to link them less to people looking at the traffic.
What do orgs do - more vulnerable situation including for its donors/payers?
Are blockchains doomed in terms of long-term privacy, even Zcash? Or can we ‘crypto’ our way out of it with further innovation?
Scenario: a non-profit organisation accepting donations with a public zaddr: a brutal regime could try to do traffic analysis to confirm other transactions belonging to the zaddr, which they then combine with other off-chain metadata which subsequently unmasks donors to the organisation who were anonymous.
Scenario: a privacy services provider (like a VPN), whose customer base paying the invoices is extra sensitive information.
I’m pretty sure it’s clear that zaddrs being shared in public - and wallets with known past receiving Tx’s which then remain in use - are sensitive and vulnerable to more than one type of advanced attack.
What’s the solution? Is there a secure script that can work in tandem with server-side ZEC wallet software to dynamically generate a new zaddr for a website (or app) every time the donation or payment form is loaded?
As I’ve said I think future quantum decryption is an underestimated and under discussed retroactive risk to blockchain privacy. This chain is what should lead the way in researching and mitigating that risk.
Perhaps instead of churning all incoming payments into a single hop1 for spending purposes, if an organisation or company wants to offer the highest protection for payers they should convert their separate zaddrs’ Tx’s to fiat and combine such cash away from a public blockchain.
Zcash has gone a long way vs. Bitcoin but I now see the fundamental public nature of blockchain means it ultimately has problems still needing solving. Zcash needs further innovation to be stronger. Combination of more quantum resistance (zk-STARK etc.) with improvements to avoid network analysis attacks to expose sensitive links to currently online wallets?
Also Mina (zk-SNARK based) seems interesting, if it solves anything.
Anyway, thus continues my exercise in paranoia + brainstorming worst case scenarios & best case solutions.