Is Zcash actually quantum private?

Technology
21

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
22

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
23

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
24

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.

25

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?

26

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
27

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++.

28

Replied on that post with my opinions :wink:

29

Sigh…

At this point I do not think implementing it is worth it.

This thread went from questions of Post Quantum Privacy to extreme ways to try to stay anonymous.

I don’t think true anonymity is possible with our technology while maintaining reasonable usability. Some of the replies and the proposal is all about how we can actually stay anonymous when we are still using an underlying public IP Protocol. An attacker with enough resources is always going to be able to tell someone was connected and sent and received something. The real protection is in the cryptography to protect that data.

Changes for basic networking connectivtiy to provide anonymity is going to need to be something standards based at the IETF level… and I can imagine the regulation pushback or bans from governments if that happened. Governments already want to backdoor encryption!

Points about small pools of nodes and malicious nodes are valid, but what can an attacker do with that information? They can see or possibly trace back to an IP that someone did something without knowing what or they can DoS and block a transaction from propagating. The same thing happens with tor - the attacker either knows something was sent or they block the transaction.

The problem with the anonymity level being discussed is you need a large pool of components that look identical to each other. Once a system becomes a larger pool of the whole system, then more anonymity can be assured. But when using tor or not, or a smaller network like Zcash, the users will always stick out when analyzed because they are in the minority. Attempts to keep the transmission packet sizes constant and randomize the sending time (usually not as desirable) and randomized destinations can help a lot more. I briefly looked at node-tor and it is set to use user browsers running peersm, but I have my doubts to how large a pool that will be and how well that will increase any real anonymity. Perhaps if it gets absorbed into a large project like Chromium it will be worth it as it would greatly increase the pool size.

So what about solutions that I mentioned like Lokinet/OXEN? It suffers the exact same problem - it’s still based on IP and if you want to talk to the rest of the world, you have to exit somewhere… and the number of exits and swarms connections is relatively extremely small.

Comments on using tor/onion further try to obfuscate the connection and most regular entities are not going to get any useful data from that, but well funded adversaries might. This is the case with Dandelion++ as well. It is an improvement on the gossip protocol but still not a guarantee against an attacker with resources to monitor at the ISP level. At this point, the best protection (legally) would be deniability - because it would be difficult to prove that a connection through an exit node really came from a specific source.

All this being said, I am not against improving the anonymity layer of Zcash. Adding things like Dandelion++ and implementing ways to control tor connections like the tor browser would be helpful. However, I think we need to keep it real in understanding that as big data and processing power increases, it is increasing more and more difficult to obtain true anonymity. Instead we should be aiming for sufficient enough so that is it not worth an attackers time and resources. Smart attackers are always going to go for the weakest link… and unless you never “exit” the Zcash network, you can never actually use its value. At some point if you ever send to someone else or an Exchange, chances are that attacker will be watching there to start linking transactions.

image
image1000×567 50.5 KB

image

1 Like
30

While I agree these will always be possible attacks and we can’t eliminate them, I do believe Dandelion++ would immediately prevent random nodes from being able to figure out TX origins as currently possible. There’s a Monero thread where a chain analysis company tried to track a Monero TX which I really like. https://twitter.com/fluffypony/status/1410383416722403328

I’m not here to discuss the RingCT aspects, nor the fact that the person in question prefers ZEC, nor the further tribalism on Monero’s side. What I do want to highlight is someone who has technology attempting to deanonymize Monero, presumably Sybil attacking Monero to the point of receiving TXs from their source as they’re initially broadcasted, claimed a TX came out of a Japanese node when it didn’t. While that may be for a reason as simple as being a work in progress piece of tech, or blind luck, I’d call this evidence of Dandelion++ steepening the curve by a good bit.

While I don’t care to personally run a Python script to manage Tor circuits, agreeing it’s overkill, I’d love it if zcashd had a built in Tor node AND implemented Dandelion++ as both should substantially increase privacy (there are also studies of D++'s theoretical effects, D++ itself being a result of the complete failure D was once sufficiently reviewed).

And yes, this has gotten very off topic from the original… all valuable and natural development though?

1 Like
31

Yep. See my continuation of this IP address issue here with some research I’ve done.

Let’s try to move Tor / IP issues there, and keep this to quantum matters mostly. Or, just let it flow because in the end, the quantum computer will be the end of us all. This is the end thread, my friend.

No perfect anonymity/security/privacy exists - but no perfect attacker exists either. Powerful entitiescan be unimpressive at times, and surprisingly make many mistakes, and also they have their own weak points and design weaknesses. One should assume nothing for 100% sure, which includes assumptions about threat actor’s abilities too.

I think Zcash, if the best technically possible OPSEC is applied to it, as I am working out*, approaches NSA-proof levels of money anonymisation (at least in the present day - who knows about post quantum), due to the default crypto design. To even discover this is astounding. No other coin AFAIK is at this level (and/r combination of enough network effect). This one is it. Innovate or die!

This ‘NSA-proof’ level of using Zcash is not (currently) convenient - zcash-cli could do with much more hand-holding like monero-wallet-cli - but it works! I agree with Zooko though that no level of privacy should be made hard or non-default for any user. It should ‘just work’. Outside of that, those who really want it can do these things discussed.

It’s not dangerous for Zcash to talk about this idea - what else seems NSA proof, ‘if done right’? Physical cash, AES-256, other pure crypto, other crypto designs and implementations (e.g. I think Signal messenger, i.e. the pure content encryption, not metadata). And no one’s banning those. I know money is especially touchy regarding the powers that be - money is directly tied to power and resources, which is what runs the world - but competing governments and corporations need to hide their information from each other too! The world needs perfect privacy, because everyone does.

I now think Zcash can have a beneficial symbiosis with Monero in terms of treatment by the powers that be, so that neither is ‘banned’ into oblivion. I’d bet that most Monero transactions are practically traceable by the NSA - much more than Tor - so it’s beneficial for them to keep it around and let people think they’re much safer than they are.

Whereas Zcash is the one actually securely private - and surely seen as beneficial to governments as an option when necessary, like Tor is. (I assume it needs to be a publicly traded commodity like Tor being a publicly used resource, to blend in with other parties, for public deniability.)

The people coming to Zcash are the few who ‘see the light’, by actually studying it. Maybe status quo of Zcash not being as commonly used as we’d prefer isn’t too bad, but some bolts need tightening and adding for sure. But if it shoots to the moon in usage or value for some reason, then woohoo, of course!

That’s the conclusion I’ve come to as well. It’s only about being anonymous ‘enough’, and trying your best. Pragmatism. Realism.

[*] and aside from being targetted specifically by nation state actors for existing, other reasons than just using shielded Zcash

32

My talk for Zcon3 will discuss post-quantum privacy of Sapling and Orchard, hopefully in some detail (I’m not exactly sure how much will fit in the time available for the talk).

13 Likes
33

This may be a stupid question, but it was mentioned in this thread that z-addresses are still private post-quantum, if the address is not known.

But what if someone that has sent you money or that you have sent money to, is trying to deanonymize transactions?

They will have your z-address, so can deanonymize that address and associated transactions.

So even if you churned which was suggested here, they would see the previous z-address from seeing all the transactions the first z-address used.

Wouldn’t this continue in steps until a quantum computer could basically de-anonymize everything?

Maybe I’m misunderstanding

34

Without including the sender addy in the memo the receiver doesn’t know it, shielded addresses don’t appear on the blockchain

35

But doesn’t the receiver see what z-address the transaction is sent from? Without it being included in the memo?

1 Like
36

Nope. Any shielded tx you receive, without some other kind of notice like a memo or anything else, could be from potentially anybody in the shielded pool.

2 Likes
37

Good question. The answer is that if they have your address, and can break discrete logarithms, then they can compute the ivk (incoming viewing key) for that address. However, they can’t then get from the ivk to other elements in the key structure, i.e. {ak, nk, ovk, rivk, dk}, because ivk is connected to them only as the output of a perfectly hiding (and therefore post-quantum hiding) commitment in the case of Orchard, or of a plausibly post-quantum preimage-resistant hash function (BLAKE2s) in the case of Sapling.

Therefore, the discrete-log-breaking address holder can only see incoming transfers to that address (i.e. what a legitimate holder of ivk would see), not outgoing ones, and not including the addresses of the other senders provided they are not included in memos. If you are aiming for post-quantum privacy then you should not include addresses in memos, which is not an onerous additional restriction if you need to keep addresses secret anyway.

There is no other information transmitted in the protocol that, given some subset of ivks, would reveal other addresses or ivks:

  • For spend authorization signatures, the key pair (ak, ask) is perfectly blinded to get the signature public key (rk, sk). Note that a discrete-log-breaking adversary is able to compute sk, but this (rk, sk, signature) reveals no information about ak. The blinding value 𝛼 is hidden as a witness of the zk proof which is perfectly zero knowledge, and therefore post-quantum zero knowledge.
  • Binding signatures reveal no information about addresses. They also don’t reveal any more information about note values than the value commitments do. (Given that the value commitments are perfectly hiding and bvk is public, it can be inferred that being able to compute the signing key bsk by breaking discrete log doesn’t yield additional information beyond the fact that the Sapling or Orchard transfers balance.)
  • As mentioned above, value commitments are perfectly hiding, and in any case don’t involve addresses.
  • The encryption is post-quantum private when the destination address is unknown. The detail will be explained in my Zcon3 talk.
  • Revealed note commitments and nullifiers also don’t give significant information to a quantum adversary. Again, detail in the talk.
9 Likes
38

My Zcon3 talk was presented on August 9th. Here are the video and the slides. Enjoy!

In particular I’d like to hear if anything about the post-quantum privacy analysis is unclear.

11 Likes
39

OK I watched it all @daira, thanks for linking it here! I think some thoughts of mine below might help further make things clear for fellow readers.

Firstly I want to publicly share that seeing one of Zcash’s core cryptographers expressing hir views on the importance of, and explicitly giving certain real-world, serious scenarios of, why absolute privacy of money is essential for normal and reasonable people is a really positive signal. It says that people directly managing this complicated cryptosystem have skin in the game that is strong and personal.

I feel very safe in Daira’s hands (and str4d’s, etc), and I’m sure that ze must feel fulfilled by working on this system. We cypherpunks have to do what we can to help everyone. We have a duty.

Given Daira’s useful talk and recent reply, my current further clear thoughts on being quantum forward private (and I will edit anything accordingly if corrected):

  • If a quantum adversary knows your address (e.g. when they send you money, when you send them money and you unnecessarily give them your sender address for some reason, or if you advertise an address in public), then due to cracking to the ivk (incoming viewing key) they can view all your past or future incoming transactions to that address. (Thankfully though, not outgoing txs - that would be far worse, basically decrypting potentially all or most of the entire pool.) For this reason, since I want the highest future-proof privacy possible, when someone sends me ZEC I give them an address I’ve never used to receive ZEC and never will again, so that no further information is leaked other than what they already could discover, whether post-quantum or not. I practice strong OPSEC hygiene. It can be done.

  • For all Zcashers, it’s really not good that any publicly advertised Zcash address (in the past or for the forseeable future) might one day have its entire incoming transaction activity (leaking most critical information like amounts, and which particular txids they are, which reveals timestamps) trivially decrypted in public. Zcash is world leading (in terms of market share combined with privacy strength), but I urge the team to make ivk use a quantum secure scheme ASAP. Is this prioritised in the roadmap? Is it feasible using current audited libraries? Thoughts, @str4d?

  • This means that a charity or political organisation who wants future-proof privacy of their own org’s incoming donation activity should not re-use their donation address, nor even advertise a static address publicly. (As discussed above, fortunately sender addresses aren’t revealed even to the donee originally, so people won’t be able to suddenly discover donor addresses en masse, just the amounts and exact timestamps - not too bad for individual donor OPSEC, but still something. Why it may still be bad: if someone says on Signal messenger “Hey I just donated to the X political organisation!” and sadly their Signal friend had their phone seized by police and contents gathered as a result of compelled phone unlocking, now the government can correlate that timestamp to probabilistically determine (and convince a court as to) which donation it was, and revealing its amount due to what was now quantumly decrypted at the org’s Zcash end). An org wanting fullest privacy (and to give donors automatic extra protection), perhaps like Tor bridges project, could offer prospective donors a function request a special non-publicly advertised unique one-time U-address just for that donor. However this is not trustless. Luckily, donors can make their outgoing donating addresses to be ‘clean’ and use-once only themselves, to trustlessly guarantee decent post quantum privacy no matter what, and minimise consequences of this DL-breaking leakage.

  • A reminder: once quantum computers can decrypt ivk, anyone can decrypt it, not just NSA. Assume that it fast becomes publicly leaked information. People can already rent Amazon low-qubit quantum compute sessions.

So my updated short summary:

  • As a sender, you have decent quantum-safe default protection. Sender address is never revealed to even recipients themselves. (And as I’ve noted elsewhere a sender can guarantee full privacy policy when sending, unlike when receiving.) However, your outgoing txs’ amounts and timestamps (txids) may be trivially decryptable one day (thus combining timestamp analysis with revealed amounts). So if your needs are extreme enough, further compartmentalise and think about OPSEC techniques like churning and chopping and mitigating timing analysis.

  • As a receiver, you’re more vulnerable. If you want quantum privacy now, you definitely need to compartmentalise. Always use a new address every time you get more ZEC. (To make spending more convenient, you can just pool together disparate funds into a single wallet whose address is never shared with anyone.) Since known addresses are quantum vulnerable in the ways discussed above, consider your receiving addresses as ‘burner’ / use-once only.

Again: all of the above would be fixed if the dev team can make ivk quantum resistant. I would love to hear how feasible that might be.

2 Likes
40

See Post-quantum privacy for Zcash · Issue #6121 · zcash/zcash · GitHub . Note that this is speculative and is not currently on the roadmap. It would presumably take substantial interest from the Zcash community, and/or a stronger sense in the cryptographic community that cryptographically relevant quantum computers are inevitable, to raise its priority. The main engineering obstacle, in my view, is address size.