(Speaking on my on behalf and not on ZF nor ZIP editors)
ZIP 2003 is being considered for NU7 which should activate around August 2025. It deprecates V4 transactions, leaving only V5 (which already exist) and V6 (which will be introduced along with NU7).
Its main side effect, though, it is that it will effectively deprecate Sprout, because Sprout transactions are only supported in V4.
I’ve seen concerns about this change not being visible enough, so in order to raise awareness I’m creating this poll mainly to get a “vibe check”. I don’t think this particular poll should be taken into consideration on whether we should include ZIP 2003 or not.
(Note that if we do not deprecate V4, it still won’t be possible to use Sprout anymore because the zcashd wallet replacement won’t support it. But it would be technically possible for someone to add support for it to some wallet if they wish to and have the means to.)
There is currently 26,054 ZEC in the Sprout pool.
Thanks you for your participation and feel free to explain your opinion in this thread.
Yes, I support deprecating V4 transactions (which also makes Sprout unspendable)
No, I do not support deprecating V4 transactions (which will keep Sprout spendable)
I think as long as we talk this up and its communicated in as many channels as possible, I think we should start the process. Thanks for making this thread!
Zcash is an extremely complex protocol. Some of that complexity comes from functionality that is now obsolete.
The Sprout shielded protocol was the first large-scale deployment of general-purpose zero-knowledge proofs, but suffered from long proving times and high memory requirements that limited its practicality. Its successors, the Sapling and Orchard shielded protocols, made substantial optimizations and added new functionality such as viewing keys and diversified addresses. As a result, Sprout is essentially unused at this point.
In the Sapling network upgrade, the proving system and the pairing-friendly curves used for Sprout were changed to be the same as for the Sapling shielded protocol, i.e. Groth16 and BLS12-381. So that part of the attack surface is shared between Sprout and Sapling. The magnitude of potential balance violation due to any weakness in Sprout’s cryptography is also limited by the “turnstile” mechanism defined in ZIP 209.
Nevertheless, the parts of Sprout that are not shared with Sapling, such as the JoinSplit circuit and the handling of Sprout nullifiers and note commitments, still impose a substantial burden on the complexity and attack surface of the Zcash protocol and of full node implementations. For instance, verification of transactions involving Sprout JoinSplit descriptions also has to be taken into account for potential denial-of-service attacks. Because of Sprout’s lack of use, there is little incentive for node implementations to optimize its verification, which may lead to such attacks imposing greater cost than they otherwise would.
The deprecation of zcashd, planned to be in advance of NU7, will also remove the only maintained software that still provides wallet functionality for Sprout, which would in any case make it impractical to move funds out of the Sprout pool. It is therefore necessary in any case to give holders of Sprout funds sufficient warning that they may be unable to retrieve them after zcashd deprecation.
Speaking for myself: given the cost of Sprout’s attack surface, it is absolutely not worth retaining that part of the Zcash protocol at this point. This step may flush out some remaining Sprout holders, but the rest have unfortunately probably lost their keys. There’s nothing we, or likely they, can do about that. If there is a chance of recovering those keys then they have until NU7 activation to do it.
ZIP 2003 doesn’t burn the funds. As for redeeming them later, it’s theoretically possible. (But if you are a Sprout holder who still has your keys or can recover them, please don’t make us waste time implementing that. Just move the funds now, while you can still do it with the zcashd wallet.)
I honestly think that Dodger’s “last resort” proposal is actually the best approach to solve this. If I recall correctly, it would involve allocating (via a protocol upgrade) the remaining Sprout funds to a single wallet, and an group/organization could pay from this fund to any users who can generate a ZK proof that they own a specific amount of ZEC in the Sprout pool (with some custom wallet code). With FROST we could even mitigate the biggest issue with the proposal which would be its glaring centralization.
To give my own opinion on this, I think we need to deprecate it, but I’m not fully convinced this is the right time. I like the idea of “soft-deprecating” it by not having any wallets supporting it, and if we don’t hear any complaints, we can go ahead and fully deprecate it. But then again, we might as well go ahead and deprecate it and if there is significant pushback we can always reintroduce V4 in a future network upgrade (or do the idea above).
Over 2.5 years ago, zcashd 4.7.0 removed the ability to send funds to Sprout recipients, preventing the creation of Sprout -> Sprout transactions unless manually running an older version of zcashd (but still permitting Sprout change to be created when incrementally moving funds out of the Sprout pool).
Just under 2.5 years ago, NU5 activated, meaning that older versions of zcashd that supported Sprout -> Sprout transactions could no longer be used on the network, making it even harder for someone to still be creating those transactions.
None of these changes resulted in any complaints being raised (that I observed). As such, we can be reasonably confident that the only usage of Sprout on the network today is solely for creating Sprout -> Other transactions (i.e. withdrawing funds from the Sprout pool).
I believe that some of the coins are from people who do not follow Zcash and do not know about the updates. There are probably people who compare Zcash and forgot about Zcash to sell it one day in the future and make a profit. I believe it is interesting to have a plan B so that in the future if there are complaints, there is a way to implement a solution for those who forgot about Zcash and only intend to move the coins in 10 or 20 years.
I say this for myself. At first, when I joined Zcash, I didn’t know that there were address changes according to network updates. I really liked the Z address, and when the U address appeared, I was reluctant to move coins to the U address. I only moved to the U address when I realized that the Zecwallet wallet had stopped working. When I moved to Ywallet, I was afraid that my coins would be stuck in Zecwallet. I confess that if it weren’t for that, I would still be using Z addresses today. If I hadn’t been keeping up to date with Zcash, I would probably be using the Z address and would only realize that it had been discontinued in 5 years or more.
I don’t like moving coins, I don’t like spending on fees, and I also don’t like moving coins so that I don’t make mistakes during the movement and send the coins to the wrong address.
People who hold ZEC with this expectation have not been supported by the Zcash network since 2018, when ZIP 200: Network Upgrade Mechanism was designed and deployed. That was the point at which the Zcash community at large decided to support regular consensus changes to improve the network (and the point at which anyone who disagreed with this forked the chain, though I do not recall anyone who did intentionally fork at the Overwinter network upgrade that introduced NUs). A necessary consequence of regular consensus changes to improve the network, is the potential for changes that deprecate and remove old functionality.
It is simply not possible to forget about Zcash entirely for 10-20 years and then expect your funds to be spendable, or even to exist. You need to either be paying attention to the Zcash network at least every few years to be aware of consensus changes, or delegate your spend authority to someone who is doing so on your behalf (which is what people storing their funds on exchanges or hosted wallets are in effect doing).
This is a user education failure on two parts:
There are two kinds of Z address: the Sprout Z address (what is being deprecated), and the Sapling Z address (unaffected by the above Sprout deprecation proposal).
U addresses are completely compatible with Sapling Z addresses (and indeed are intended to get rid of the confusion related to there being multiple payment protocols on the same Zcash network, by combining them into one address type).
Movement of coins is a necessary reality for ZEC. An individual coin is bound to a particular payment protocol, and the payment protocols in the Zcash network have undergone radical improvements over the 8 years that Zcash has existed. Wallets therefore need to over time move user funds from the older payment protocols (Sprout in this case) to newer ones (e.g. Orchard).
This was another reason for U addresses: individual users should not be doing this move themselves! Wallets should be handling it for their users (either completely internally and automatically via note management, or explicitly with a “migrate funds” button), and U addresses enable users to hold ZEC in multiple payment protocols at once while using them as a single “bucket of funds”.
this is crazy if you do it
total disrespect to early holders, miners, investors, privacy and to immutability.
this is making Zcash look bad, that a group of people can decide such things.
and sad to see how many people support this
treat sprout holders as ordinary consumers. They just purchased ZEC products and are not as familiar with the detailed development as developers and enthusiasts of this project.
Right, they are early personal full-node operators and early GPU miners.
Perhaps some personal family life reasons have caused interruptions in recent years.
Sure, ASAP deprecated the Sprout, then need provide interface to redeemable.