Churning Zcash for maximum anonymity and privacy


Wanted to share what I think is a useful tip with other Zcash users looking for very high anonymity and privacy. I’m surprised ‘churning’ hasn’t been discussed much in Zcash circles, I guess Zcash (so far) is a smaller community than Monero. Hope that changes! Think it will.

I recently read what must be every research paper on advanced attacks on Zcash, including active ones like dusting/gifting attacks. Some good reading if it matters to you:

(The last one: while it has some silly marketing hype words and some vague nonsense that shouldn’t be in a ‘paper’ like that, after further reading elsewhere, then coming back to it to double check, I saw there was substance to its core claim as well as its author’s other contributions on GitHub. Now I’m mystified as to how that paper actually carries out its “ITM attack” - by trying to resend other existing Txs’ raw notes via a custom raw transaction and seeing how the network responds, or something?)

I’ve concluded - similarly to a recommendation of one of the above papers - that ‘churning’ your own fully shielded ZEC one time - i.e. creating another local wallet controlled by yourself and using good OPSEC, transferring your initial ZEC to it - reliably eliminates, or is a required part of eliminating all of the above attacks. ‘Churning’ is already a well-known concept in the Monero community, indeed Monero needs way more churning than Zcash because its anonymity design is much poorer. Where I churned Zcash 1 time, I’d churn Monero an order of magnitude more. (And even then, not rely on Monero alone.)

No OPSEC can guarantee protection against a targeted attack, but certain OPSEC I’ve identified nullifies all general passive or active attacks I’ve seen that undermine Zcash’s anonymity. With Zcash, like Tor, using the tool alone doesn’t guarantee magic protection, you have to work with it with some skill and knowledge, and use other side protections at the same time.

Also, for those really serious about trying to be quantum private (see here) (and here), below I suggest an additional element to the churning to make that as least problematic as possible.

Here’s my tips (not necessarily my complete list):

  • When receiving ZEC initially from another party, even if to a locally controlled ZEC wallet, immediately churn it once. This will neutralise any ‘dust attacks’ described in the papers above. It’s that simple. Keep your large amount of ZEC funds in this first ‘hop’ which is result of your first proper churn. Hop1.

  • Try to get ZEC from someone else’s shielded address in the first place, not from a transparent address. Otherwise, churn it twice initially - a second time after the first ‘shielding’ tx churn. We really want to go ‘dark’. This churning is a ‘black hole’ to make the outgoing ZEC very, very untraceable.

  • Use your own zcashd full nodes (and cli if possible), not light wallets that use someone else’s node - yes it’s a lot of effort to set it up, but it plugs some of the important holes in the research papers.

  • Always leave some ZEC in your last hop upon each churn (e.g. a random amount between 1-3%, or random amount within a certain set range that you set for yourself as a randomised secret ‘fee’ for the sake of less traceability - make it random, use random number generator). Why? Quantum computers in next few years or decades might unfortunately expose all transaction output amounts within shielded ZEC pools. Either way it’s good habit for churning any cryptocurrency in general, to make any attack tracing transaction amounts less severe.

  • Round off churn amounts to be less unique (e.g. don’t transfer 0.176584, transfer 0.176 and leave the rest it costs nothing), and/or make the patterns non-similar - if you always move 2.573 or 1.573 in churns, that’s potentially linkable.

  • Randomise all what time of the day you churn every time (to not be similar to each other, e.g. correlated in terms of timezone statistical similarity).

  • Delay your churns and space out across multiple days. The more delay, the better (after several months is best of all - start churning NOW so later it’s only more anonymous when you’re ready to use money in your final top). Check the daily transaction numbers at or elsewhere. Right now there’s about 100 fully shielded tx happening per day. Not a lot, but workable, and it’s always improving over time - 2022 should be great year for Zcash! For strong anonymity I’d recommend space out your churns across 7 days at least.

  • Randomise the spacing between your churns, too. I have more tips like that but I’ve written enough. Just try to thwart timing analysis.

  • Study the anonymity set of the current main shielded tx pool. E.g. Zcash / Transactions — Blockchair (onion link) - make sure your transactions don’t stand out in ANY way, e.g. make sure churns have just one input and two outputs in this current Sapling era.

  • The wallets you use to churn multiple times (3 churns is enough, so that you have four locally controlled ZEC wallets - 4 hops - in total, all of them only ever having touched shielded ZEC in or out) - make them disposable ‘burner’ wallets only used for temporary, one-time, single-transaction churning (one tx in, then later one tx out) - NEVER never log into them ever again on the Zcash p2p network apart from doing the isolated churning events. (There’s an active malicious node attack that can target wallets connected in real-time to the network to reveal things normally hidden, so reduce that attack surface to keep your ‘black hole’ truly black.) I call this “churn ‘n’ burn”.

  • Always buy at least 2-3x your required ZEC coming in, and never spend the same initial amount in a single outgoing transaction within the shielded ZEC pool. The money you bring into ZEC should always be your largest amount sitting in a wallet by far. Hold all your ZEC funds at the first ‘hop’.

  • Only ever chop up your ZEC (never churn the whole amount from one address to the next). Why? Combined with timing randomness, this is my only known mitigation against the possible quantum privacy weakness of shielded ZEC as discussed in my other thread. If quantum attacker can see all transaction amounts (e.g. outputs), then at least don’t make two hops have the same amount, too close to each other in time. Start with as big an amount as possible, coming into ZEC.

  • Never recombine chopped up ZEC. This makes it worse upon possible future quantum decryption - it increases correlation and connection points if everything is unmasked. The ONLY quantum-safe way to recombine ZEC-anonymised funds is in the analog world, i.e. physical cash.

  • Regarding quantum concerns, you can achieve pretty good PQ privacy regarding linkage between your churn wallets because they’re all created locally and it can be done with good OPSEC like Tor and zcashd. When you finally spend the chopped up, highly anonymised ZEC, it’s at least quite hard for quantum attackers to determine where the ZEC originally came from, since sender addresses apparently remain private to quantum attacker.

Chop, churn ‘n’ burn. :woman_farmer:

Note: have refined the above as I learned more.


There really is no substance to that “Attacking Zcash for Fun and Profit” paper.

There’s also no need to “churn”. We’ll address dusting attacks when we have the engineering bandwidth to do so; attempting to mitigate them manually is unlikely to help IMHO.


If anonymity / TX unlinkability is a true goal of a ZEC user, then as noted by one of the decent papers linked above (not the last silly one), it seems straightforward to me that one (full wallet / address) ‘churn’ (or some other type of note-merging transaction) is needed with the current protocol (and upcoming Orchard too, which looks to me to have a similar fingerprintability with ‘actions’ e.g. number of actions per TX), because your untraceable outgoing transactions should only show the most anonymous TX fingerprint of ‘1 shielded input, 2 shielded outputs’ (i.e. have the current most commonly shown value for that on the public blockchain within that shielded pool).

The example attack: If you set up a new wallet with nothing in it yet, receive shielded ZEC from someone (e.g. an exchange or p2p trade), and you receive 13 unspent outputs as a result (where that initial TX to you exposes an unusual, uncommon amount of 13 inputs)* - now, the next transfer/payment you make, if it’s for the same amount of ZEC, it will expose 13 inputs, which is very unusual fingerprint, so unless you wait for months and another shielded TX (amongst the thousands per occurring per month as per present usage) has an unusual 13 inputs, it will correlate uniquely for tracking. Even if there’s another one, the anonymity set is still only a size of 2.

Am I understanding something wrong?

[*] e.g. because the seller is a malicious surveillance entity and tries to undermine untraceability of anyone they transfer ZEC to, or for an unintentional reason such as the seller having a lot of small outputs in their wallet (from having received lots of small payments?) and you then buy a large enough amount and are allocated several inputs as a result. Probably fairly low chances, but I already saw some unusual multi-input TXs on a blockchain explorer.

1 Like

Agree with @daira that there’s really no need for churning, especially if the funds will be used in the shielded pool. Also in Zecwallet, regardless of how the funds were received, all transparent balance ill be automatically shielded at the earliest opportunity. Shielded by default will also come to wallet SDK in NU5.


Welcome, and thanks for the thoughtful posts!

The example attack you describe is a “dusting” attack. Andrew Miller actually demonstrated it live on twitter one time — using 7 dust payments instead of 13. It looks like some of the tweets may have been deleted or something, but it was somewhere in this twitter thread… Oh, here’s the rest of the demo! (Thanks to TripsCrypto on twitter for linking to it.)

I think you’re right that it is a real possible attack, but imho it wouldn’t typically be easy for an attacker to leverage it to learn much more. I explained why I think that in detail in this twitter thread.

As an aside, this is totally different in Zcash than in Monero! In Zcash (Sapling), all that is revealed on the blockchain is the total number of input notes used and the total number of output notes created in the transaction. In Monero what is revealed is which specific input notes/decoys—out of all possible input notes on the blockchain—were used and which specific output notes were created. That is a much richer set of information to give to the attacker, and it is the basis for the devastating attack on Monero that I describe in this video, which I call “the Make Two Controlled Purchases Attack” and which the Monero researchers call “EAE” Attack (Eve-Alice-Eve).

Now the suggested defense of sending the dust inputs to yourself is a strong defense in Zcash, because after you’ve done that a single time, no further information derived from those dust inputs will ever be revealed either on the blockchain, through the network layer, or to your recipients. (Aside: unlike in Monero, where more information continues to be leaked to the attacker, and churning is kind of swimming upstream against the attacker’s information-theoretical advantage. It could even do more harm in Monero. But not in Zcash.)

However, this is the kind of thing that wallets should do for the user automatically instead of the user having to become an opsec expert and try to outfox their attacker. Halo+Orchard will make this possible! Let me explain…

There is a bundle of interacting issues in the wallet’s decisions about whether to send funds to yourself and when, and what notes to use. These include autoshielding (moving funds from the t-pool to the latest shielded pool), automigration (moving funds from older shielded pools to the latest shielded pool), defending against dust attacks, how long it takes to generate a transaction, and also the “I can’t tip the barista!” problem. Let me explain that last one…

The “I can’t tip the barista problem” has to do with the fact that when you use an unspent input note to pay someone, and you send the change from it back to yourself, you can’t spend that change for a while until the transaction that produced it has finalized. That’s why in most/all Zcash wallets, after you make a payment, your “available balance” temporarily goes down. If all of your ZEC was in that one note you used (which isn’t uncommon, as we’ll see below) then your “available balance” temporarily goes down to zero.

That means if you use a note to pay for coffee with ZEC (which I do almost every day), and then you want to give a tip to the barista (which I also do almost every day), then sometimes you can’t, because all or almost all of your ZEC is still in pending state waiting for that change to come back to you.

Okay, so there is a multidimensional tradeoff here. Your wallet could make it possible for you to make multiple successive transactions if it maintained many small notes instead of one large note. And it could help protect you from dust attacks if it either (A) Used more input notes in a typical transaction so that it could use some dust inputs in a transaction while that transaction would still be indistinguishable from a typical transaction, and/or (B) Sent funds to yourself in a transaction (like it does with auto-shielding and auto-migration) just for merging dust.

Now the current behavior in all Zcash shielded wallets does the opposite! It basically tries to keep your ZEC in few big notes instead of many small notes, and it tries to use few input notes in each transaction. This means it yields pretty bad results on the resistance-to-dusting tradeoff and on the “I can’t tip the barista” tradeoff, but it optimizes for the other one I mentioned up there — the time it takes to generate a transaction!

(And remember, even though the current Zcash wallets do this in a way that makes them vulnerable to dusting attacks, I still think — as far as I can tell — that dusting attacks are not a huge threat against Zcash users in the use cases that I can imagine…)

So why do wallets do it this way? Because in Zcash Sapling (with the Groth16 ZKP), the time it takes to generate a transaction is approximately ~0.1 seconds plus ~4 seconds per input note. That means if you were using, let’s say, 10 inputs notes in a transaction, it would take maybe 40 seconds of waiting.

So what’s going to be better in Orchard (with the Halo ZKP)? Two things:

  1. The time it takes to generate an Orchard proof is more like ~4 seconds per transaction plus ~0.1 seconds per note. [*** Caveat: these timings are approximate. Real, precise and reliable numbers will come from actual benchmarks.] Therefore you could generate a 10-input transaction proof in only ~5 seconds.

  2. The ECC core team came up with a really cool hack in Orchard to improve privacy and usability, which is that on the blockchain, input notes and output notes are indistinguishable! So instead of the eavesdropper seeing that X input notes were used and Y output notes were created, all they see is that Z input-and-output-notes were involved in this transaction.

So you could imagine a wallet that, for every typical transaction it makes, it tries to use the same number of notes (inputs and outputs added together) as all other wallets’s typical transactions, and that number could be—let’s say—10 and then the wallet would have the flexibility to do a better job of keeping extra ZEC available for immediate use, protecting the user from dust attacks, and still generating transactions quickly so the user doesn’t have to wait.

Most importantly, wallets might be able to do this without requiring the user to understand these issues or to make any explicit decisions.

However, it still won’t be easy! Balancing multiway tradeoffs like this is tricky. At ECC, we’re currently focused on shipping a bulletproof Halo, Orchard, and Shielded By Default!

Thanks again for the thoughtful posts on this and on the quantum computers topic.


That was a long read @zooko :sweat_smile:

I just want to point out that specific note selection (by way of specific note exclusion) is functionality in WarpWallet that exists today. That’s a good way to see potential dust notes and exclude them.

Also, the “tip the barista” problem can be solved using the note splitting feature in WarpWallet. Send [yourself] a transaction from the wallet while setting the “max per note” so that you always have a good distribution of sized notes that you need. (User preferences will differ)

If you haven’t used these features, check out YWallet/WarpWallet by @hanh


@zooko this is too great. Thanks for sharing. @joshs we need to get this messaging out on how awesome Orchard is going to be.


Yep, I had read your twitter thread reply / rebuttal and it was excellent - a level-headed, realistic assessment of the severity of the issue! (Yes, it exists, but isn’t necessarily a very common problem.)

But for some, the likelihood of the problem needs to be shifted closer to zero, or completely be zero, hence this (hopefully only pre-Halo) tip of basic churning.

As you say:

Indeed, consequences of Zcash tracing should be understood in context. Maybe one’s shielded ZEC (or whatever they attach it to off-chain) is anonymous enough to an attacker that they can’t do anything with the linkage anyway. (But it’s also about minimising ZCash as a possible weak point in their privacy/anonymity - or, optimistically, making it your strongest point.)

Jeez. Each time I learn something new about Monero, the worse it looks. I already had given up hope in Monero (but hope they improve it of course), except to use it as another layer sometimes (e.g. a final payment layer post-ZEC if some product seller doesn’t accept ZEC, or for other forms of layering for reasons like hiding the fact from a merchant that I have (‘further’) ‘anonymised’ some XMR with ZEC technology (to not reveal to them exactly how anonymised the money is), or for other reasons).

To me, now, XMR seems best to use while covering your eyes and hoping for the best (i.e. faith, religion).* Funny how people think of it as the ‘Tor’ of cryptocurrency. Zcash is BETTER than Tor, for cryptocurrency. (It provides superior anonymity and privacy protection for your money than Tor does for your IP address. It’s quantum private. Tor isn’t.) This astounding fact is still sinking in, it’s amazing, and it seems it’s been this good basically from the beginning. :slight_smile: Corrected in subsequent post below.

(I would have just churned at least once back in the Sprout era, though the smaller shielded crowd to hide in would have made it less convenient - more time between churning required, and more stressful - to be at the same level of OPSEC compared to what’s reasonably doable currently. As for the Orchard+ future with shielding / shielded much more defaulted, it looks BRIGHT!)

[*] XMR developers are probably just as honest as Zcash team - I noticed the ‘Breaking Monero’ series - I’m really dissing the Monero user crowd, which seems in complete denial very often.

@zooko thanks for the tip about monero churning possibly making monero OPSEC worse. Will look into that. I know a big principle is that extra complexity in security can make it worse - simplicity can be safer and secure (less ‘attack surface’ and points of failure). Sometimes more complexity is better (it makes it harder for a certain attacker to hack their way through the extra sh!t you put in front of them) - but it depends on the mechanism at play. When more complexity does help, I call it “defence surface” (a larger shield to fend off the incoming arrows - more points of failure for the attacker) - I see others use that term. Can also be complex. If you have multiple simultaneous enemies, it may be better to be (or to look) simpler to one enemy, but more complex (e.g. more parts to your chain) to the other enemy, so you must compromise in the middle, choose which enemy to defend against more strongly, or compartmentalise, which is a lot of work and inconvenience, but very powerful. Complicated, but always fun. :slight_smile:

So on to the main course: are decisions still being made (for reference wallets) on what the default number of notes per transaction will be (and/or auto merging/splitting behaviour)?

IIUC, no higher amount of default notes (inputs/outputs/actions) set per transaction could be reliably safe against dusting, since attacker only needs to send a TX to a victim with more than the default number of inputs (so say it were set to 10, they’ll just dust you 11 - then, if you want to send the full wallet’s amount in a subsequent outgoing TX and didn’t have any other notes prior to that, the TX will show the ‘1 more note than usual’ count, and stand out - UNLESS wallets auto merged >10 unspent notes always to a maximum of 10, but that seems unnecessarily expensive, e.g. outgoing TX would have to always split or merge into preisely 10 notes).

To reconcile insta-tipping with de-dusting, could the ideal default (to not have to churn, even for high security users) be:

  • Auto note merging into exactly 1 note at all times (attackers thus can’t possibly succeed - even if they send muli-note ‘dust’ to someone e.g. via a custom, non-official, third-party client taking advantage of the fact that multi-note transferring is still flexibly allowed by the protocol, users of official/reference wallets are auto-protected from dust due to auto-merging, thus churning is not required.) [Then official wallet might not even need to decide on how many notes to set as default in outgoing TXs - with default settings it’s necessarily 1 note always, as that’s all there is to choose from.]
  • Rely on Orchard transactions being fast enough so that insta-tipping will only be a few seconds wait?

So: indeed, do what @daira has suggested in 2020? Note merging as a defence against input arity correlation attacks · Issue #4332 · zcash/zcash · GitHub

Whatever happens (Halo sounds better every time I learn more about it, best of luck in this final prep period next few months), I’ll always at least check on a ZEC blockchain explorer what the current most common input/output/action ‘fingerprint’ is (i.e. how many of such things show on TXs), and just do what I need to do, if need be, to match that.

Of course, unnecessary OPSEC isn’t desired even by me, so if I don’t have to churn in Halo+Orchard after verifying how it finally behaves, then that’s fantastic, I can put my hoe down, grab a coffee, then tip someone only ~4 seconds later. :slight_smile:

PS: why can’t protocol just change to not allow dusting? (Typical use looks like only one output note goes to recipient,s so why allow someone to send dusty TXs to people? There must be legit use I don’t know about - efficiency or something fundamental. I’m still a cryptocurrency newbie, apologies.)

1 Like

Self correction: my hype of Zcash’s superiority over Tor was unfounded. I forgot that Zcash is still on a public blockchain, subject in the future to advanced retrospective analysis by any party with a bit of money to partially decrypt it, such as quantum in the future (or who knows, even fully decrypt if it’s really far future with enough qubits).

And even before quantum arrives, Zcash’s blockchain data is already subject to passive timing attacks (i.e. analysing the blockchain). It’s easy for a shielded ZEC user to have bad or lazy OPSEC which makes their transactions easily linkable - something Zcash can’t possibly help with apart from community education (similar to how Tor project can’t help if someone reveals their real identity while on Tor).

Tor has an advantageous aspect in not having a public blockchain: only global passive adversaries (along with anyone they share that data with like other government agencies or people in power) could possibly emulate such an equivalent to blockchain graphs. They would have to have all or most of the Internet’s traffic (or just that known to be Tor-related) mapped out, which is vastly more data than Zcash’s ~34 GB so far. But apparently HDD storage is cheap, and NSA’s Utah data centre is plausibly conjectured to be intended for permanent storage of certain massive datasets considered worth keeping for later timing analysis and/or direct quantum decryption (normally NSA throws away most of what they collect away after a week etc.). So to at least one adversary out there, probably Tor is still just as problematic as a privacy coin blockchain. However, not everyone has that adversary, and nasty data brokers can analyse Zcash, but not Tor traffic, so Tor remains mighty against most attackers.

Zcash itself (no matter how much you self-churn) has two data realms I know of so far: the permanent public blockchain, and then the transient, real-time, p2p network data privately collectable by some nodes, some of the time.

So: Zcash and Tor aren’t that directly comparable. In the end, balancing all threat models, perhaps both are kind of on par with each other. But I compared an apple to an orange.

(This means Monero combines the worst elements of Zcash and Tor’s respective weaknesses: a permanent public blockchain, AND Tor’s level of quantum vulnerability. It’s a distant third place. Poor Monero.)

1 Like

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 [

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.