There is no current proposal to make Zcash fully resistant to attacks from quantum computers. I recommend watching my “Post-Quantum Zcash” talk at Zcon VI (slides, video) to see where we are and what the challenges will be. That talk was before I had the idea of my “Orchard Quantum Recoverability” proposal, but it is otherwise pretty thorough.
Despite being ECC’s resident advocate for the importance of post-quantum crypto, I don’t think PQC should be the number one priority, mainly because it can’t be a drop-in replacement. The post-quantum encryption scheme and zk proof system we would need to be able to replace ECIES and Halo 2 without other design changes simply don’t exist: current candidates have public keys, ciphertexts, and proofs that are just too large.
That said, I am pushing for post-quantum security to be taken into account in the design of Tachyon. Deployment of Tachyon is unlikely to block on having a post-quantum recursive proof system available, but recursive proofs take the pressure off needing to put large proofs on-chain somewhat.
I also think it’s likely at some point that we will develop a long-term cold storage pool that will be fully post-quantum. There is no roadmap for when. You will probably not be able to receive from other parties directly into the long-term pool; it will assume that the party that transfers funds into that pool is the same party who will later withdraw them (so that it is not necessary to use public-key crypto in that shielded protocol). An interesting point is that it is probably not necessary to restrict the ability to pay from the long-term pool to another party in a single transaction. The advantage of this approach is that there would be no latency penalty to payments of holding most of your funds in the long-term pool.
What would be the difference between a “regular” pool and a “long term storage one”? Is the long term here to provide an option to store ZEC for 10+ years without having to worry about random pool deprecations? I would very much be in support of that.
To be clear, I’m saying “random” because in the case of Sprout, from the outside, it does appear like it may happen at a completely random time, there’s no public schedule that I know of.
(“at some point” was edited in but that was before you replied.)
Your quote is misleadingly selective. Please be more careful when you quote me.
You’re asking about a feature that has not been designed yet. The policy would be described when it is designed. Please note that the policy is likely to be more nuanced than that and to allow for the fact that there might be still be reason to require such funds to be moved for major security or scalability changes. If we are able to design it in the way I anticipate, that case would be much less likely.
Hope you get to have some time off to enjoy the summer and touch grass @daira. I know we clearly have our differents, but I can’t imagine this level of nitpicking is necessary. I’m only saying I’m in support of what you are suggesting, not creating some kind of contractual expectations…
I did in fact touch grass yesterday (not too much grass due to an allergy), lying down on a trans flag in Sackville gardens with one of my partners. It was nice to enjoy the sunshine and the temporary distraction from passive-aggressive forum posts and from the attempts to sabotage trans people’s healthcare and exclude us from public toilets.
It is necessary (and not nitpicking) because “we will develop” could be taken as a commitment, and “I also think it’s likely at some point that we will develop” cannot.
Supporting Sprout adds to protocol complexity and complexity is enemy of security. Though, maybe it is price we pay for world’s first mathematically fungible sound money…
Q: How much of this complexity comes from interaction between different shielded pools?
For example, here is an alternative proposal - rather than disable v4 tx, further restrict them. “Only valid v4 transactions SHALL be those that contain exactly one JoinSplit and transparent outputs. Mixed pool v4 transactions are not allowed.” This achieves two things: first, we don’t need to worry about how Sprout interacts with Sapling, or about tx with more than one JoinSplit (maybe there is batch verification complexity this lets us eliminate); second, it avoids making Sprout funds unspendable. Could also add further restrictions like asking for a higher fee for DoS prevention. (Similarly, if complexity comes from v4 tx format, could one could special-case some very restricted form of Sprout spendability in a more modern tx format?)
Of course, unspendability is a spectrum. Bitcoin is not completely “pure” - if I had pre-signed transactions before 2014 then BIP-66 had high probability of invalidating them (by enforcing strict DER encoding). Zcash doesn’t support many pre-signed transaction use cases (because every NU changes consensus branch ID); similar with Monero and tx version changes. Ethereum reprices opcode gas consumption so pre-signed tx can be invalidated as well (if you didn’t supply enough gas and now it requires more). I think Satoshis own coins can’t be spent normally - they have to be included by the miner directly because plain P2PK violates tx standardness rules and thus will not be relayed by the network.
I would generally prefer if we were on a point of this spectrum where Sprout funds are technically spendable but users are responsible for effectuating how (Satoshi-style; no official v4 tx creation code in zallet/etc).
My suggestion on deprecating sprout is to have a very clean last withdraw day, that is long-dated (3-5 years out), so any last straggler can leave the pool. While its been deprecated for years, a final date that can be clearly communicated is very valuable. (And time from this day being decided to enacted being years is clear)
While its a really long time, this is the price of competing for being a store of value. Its exactly the point people will criticize for years.
And in the meantime, we can disable scope further, just to preserve withdraw-ability to transparent. (E.g. @madars proposal)
This, unfortunately. The narrative skews hard against this, giving sufficiently unwanted ammunition to Zcash detractors to say we’ve robbed zodlrs of their funds and undermined the soundness of self-custody. Sadly, optics is the highest of reasons I’m not convinced of this at this time, despite agreeing with almost every point @daira and others have made here. If the community ends up voting against this proposal, I hope it’s not seen as rejecting further approaches such as @str4d’s ZSA route or @madars’s, or even setting an explicit end-of-validity height that’s widely announced (though that itself will fuel detractors).
Sprout was deprecated by ZIP 211, deployed with Canopy, which activated on November 18, 2020 — more than 5 years ago. Sprout holders have been repeatedly told to leave the pool since then. Sprout will have no wallet support after zcashd stops working at NU7.
I expect that if this (NU7) opportunity is missed, 3 years from now someone will still be saying something like: “My suggestion on deprecating sprout is to have a very clean last withdraw day, that is long-dated (3-5 years out), so any last straggler can leave the pool.”
It must become possible to remove the complexity and attack surface of Sprout from Zcash specifications and node implementations.
No significant complexity is actually removed by your suggestion, because JoinSplit proofs and signatures still have to be validated. “Mixed-pool” transactions are not what introduces complexity. They are just a consequence of how the transparent transaction value pool naturally works, which nodes and wallets must support anyway. In fact it adds complexity because the only current implementation of wallet support for Sprout —the migration functionality of the zcashd internal wallet— produces transactions that violate this restriction. So if you wanted to fork that implementation or somehow maintain it after NU7, you’d have to do extra work.
This does address one point in the Motivations section of ZIP 2003, but for me that point was mostly an afterthought, not the main motivation.
At least to me, the important part is having a clean, long-dated last day that can be communicated. It has been 5 years which is great! However, the final notice itself needs a buffer. Perhaps since its been 5 years of deprecation to date, it can be shorter for the final window. Having the final date be set with sub-1 year notice seems very bad for something trying to be money.
Else it’ll always be a criticism that “one day people decided to just remove it in the next upgrade”, that will run counter to a moneyness narrative.
I suggest a dedicated token holder vote on canonicalizing such a final day.
v4 transactions can’t have Orchard outputs, and only Orchard notes (and later pools) will be quantum-recoverable. Lack of quantum recoverability arguably runs far more strongly and importantly “counter to a moneyness narrative”, because it affects all holders of Zcash funds — not just hypothetical Zcash early adopters who are now for some reason stubbornly clinging to a deprecated protocol (or more likely people who have lost their keys and will never recover those funds anyway).
Wallets are going to have to move all funds to Orchard (or a later pool, e.g. Tachyon). It’s just a matter of time.
I feel like there is a bunch of people violently agreeing here. I think it is just a matter of the particular thing being voted, i.e. ZIP 2003: Disallow version 4 transactions proposes deploying with NU7 which I don’t think meets any >= 1 year window being discussed here. IMO it should actually propose a date, people should discuss that date, and after we’re have enough support we should just set the date into stone and start announcing it.
In the spirit of trying to be the change we want to see in the world, here is a topic and poll to discuss when should we deprecate Sprout: When should we deprecate Sprout?
I don’t understand why anyone thinks extending the window to a year would help. It would only provide an excuse for people to procrastinate further. And if we’re imagining that there will be additional publicity that might attract the attention of Sprout holders to the need to move their funds, it would in practice just delay that publicity to the end of the year-long period.
The only situation where I could imagine this helping at all is if you’re facing some technical difficulty in moving the funds that takes time to resolve and already has the attention of people who can solve it. But if anyone has such a problem then they need to tell us now.
Note that ZIP 2003 was merged in November 2024. I expected the set of specs to be included in NU7 to have been nailed down at the beginning of 2025. Failing to do so during 2025 has been contrary to my explicit advice stated on many occasions. If that advice had been followed, we’d have had the year-long window.
It is simply awareness. We have a very skewed perception of what is happening in the ecosystem because we are in the middle of it. Most people that use Zcash have no idea what is happening in the forums or what a ZIP is.
These are completely different things:
“there are discussions about deprecating Sprout, and a proposal to effectively deprecate it by disallowing V4 transactions which, if approved by a bunch of polls, will happen when NU7 activates, which we still have no idea when it is going to happen”
and, e.g.,
“The Sprout pool will be deprecated on February 1st, 2027. You need to move your Sprout funds before that date or you will lose them”
The second is much easier to digest, and most importantly, announce in a way that is more likely to be picked up by crypto news sites and whatnot to maximize the chance that it will reach the people who still hold Sprout funds.
The gradual fee approach: 100% → 75% → 50% → 25% → 0% over a set period. Each step down is a news event. Each step is another reason for wallets and exchanges to notify users.
This isn’t about delaying. It’s about creating multiple signals instead of one cliff.
@daira’s frustration is valid. Sprout has been deprecated for 5+ years. Extending the window just kicks the can. But @conradoplg is also right that “Sprout deprecated February 1, 2027” is infinitely more communicable than “pending polls, unknown NU7 date.”
The gradual approach gives both: a specific schedule that media can cover, plus built-in second chances for stragglers who miss the first announcement.
It also sets a precedent for future deprecations. Sapling will need this conversation eventually. Might as well establish a method now.
