Another reason for migrating to Sapling is because Sprout was where the counterfeiting vulnerability was discovered and is sole the reason for turnstile.
This is actually the direction I would prefer to go. I agree it is more work and more risk (due to writing another new circuit), but it might be the required direction if we want to keep Sprout support in a scalable design. We’re actually lucky here that Sprout doesn’t rely on curve-specific primitives (we already leveraged this to switch to Sprout-on-Groth16). Deprecating Sapling would be more costly in a non-BLS12-381 circuit, but I’m okay with higher prover costs (minutes, not hours) for legacy redemption (and a recursive or accumulating proving system would minimise the verification cost of legacy redemptions for full nodes).
One of the benefits to the Zcash protocol’s current design is that it explicitly doesn’t support the “create a transaction now and mine it in 10 years” use case, because transactions commit to the NU they must be spent in, and we have regular NUs. So the design space for “legacy Sprout support” (or legacy support for any other Zcash pool) is only constrained by the key trees (because people back up spending keys and addresses), and the way in which note commitments and nullifiers are generated.
This is what I think a legacy Sprout could look like:
- The Sprout commitment tree is frozen, and the chain is checkpointed. Full nodes delete all the code for handling existing Sprout commitment trees (including intra-transaction trees).
- All Sprout commitments that were leaves of the now-frozen tree are formed into a new tree that is efficient to compute inside the new circuit.
- A new “Sprout redemption” circuit is written. It only supports spending notes from the new fixed tree (we’d bake its root into the circuit), and uses the exact same value commitment method as Sapling to balance values (eliminating the need for intra-transaction tree logic outside the circuit).
vjoinsplitsection of the transaction format is deleted, replaced with a section dedicated to legacy pool redemption (ideally of any legacy pool type).
- If TZEs are deployed then we could decouple this even further (TZEs are required to interact with the chain through a
Contextobject, so we can tightly scope the interface to minimise its interaction with the rest of the Zcash protocol).
- If TZEs are deployed then we could decouple this even further (TZEs are required to interact with the chain through a
- Full nodes still need to append to the Sprout nullifier set, and check for duplicates. Hopefully the nullifier component of any scaling solution we deploy could be applied here, but this is the most problematic component.
More generally, in a post-halo2 Zcash world, changing the circuit is as “easy” as any other consensus change (due to no longer requiring a new MPC for generating parameters) - still non-trivial skilled engineering work, but not impractical. I think we will see more circuit changes deployed over time, as the primitives improve, we identify new functionality we want to add to existing pools, or we deprecate older pools.
So what’s ECC plan to deprecate shielded pools in the future (no just sprout!)
Looking at this conversation, it feels to me that social cost of using shielded pool is way higher than transparent pool. This will hinder shielded pool adoption for users (due to constant need to upgrade to newer pool, not a viable crypto for long term storage, fear of unspendability etc)
Taddys comprise the legacy value pool because the odds of changes to the btc protocol and subsequently the Zcash side of it not happening is a far safer assumption than the other.
This idea seems pretty similar to PRINCE — Privacy Incentives for ZEC, except applied to the Sprout pool instead of to the transparent pool. In general, I don’t see why the Zcash community should pay more costs and risks to maintain old UTXOs than they do for old shielded pools, which is why I bundled the two together in my proposal “charge higher fees for spending old UTXOs and Notes”.
To put that in a stronger and more positive way, what if the Zcash community signaled to all future users that we’re not going to support taddresses indefinitely, and we’re not going to support old shielded pools like the Sprout pool indefinitely but at least you can be assured that we won’t discriminate between one or the other. If you move your money into ZEC today, you can choose to put it into the t-pool or into the current z-pool with a similar level of expectation that the Zcash community will accept it and support it for a similar number of years into the future.
In contrast, if we continue to impose limitations and costs onto the Sprout pool (the first z-pool), but we don’t impose similar limitations and costs onto the t-pool, then that will signal to people that if they want to move their money into ZEC for long-term holding, that they had better move it into the t-pool.
I think there is a “social layer of governance” dynamic here that a lot of people are underestimating — I suspect a lot of people in these threads imagine that if the ZCAP, the Zcash Foundation, the Electric Coin Co, and 99% of people on this forum, all decide to implement some new policy, then all Zcash users will accept it and it will become the policy of the blockchain in the next future Network Upgrade. I really doubt that’s the way that it would play out!
I guess that if all of the above decided to institute a “hard/brittle” new policy like “taddresses just don’t work any more”, that there would be chain-fork and that the vast majority of the value and the usage would remain on the status quo fork of chain — the one that continued to provide working t-addresses. Those users like using t-addresses, they have their reasons, and we can’t force them to stop using t-addresses even if we wanted to. Nobody can!
On the other hand, if we instituted a “soft/incremental” new policy like “taddresses start paying 1% per year fee to reimburse the rest of the users for the costs of storage, technical debt, and excessive transparency”, I guess that it would go through — that literally everybody would upgrade to that new consensus rules set and the status quo chain would simply stop getting new blocks and new usage and would simply come to an end, just like what happened with the Overwinter, Sapling, Blossom, and Heartwood forks [*].
Your fun thought experiment above, and the related concept in PRINCE, could potentially improve that calculus by motivating a lot of users to support the new policy since they would see it as a more direct benefit to them and to other proactive, socially-helpful users.
[*] You might wonder why I don’t include Canopy in that list. Because that didn’t happen with Canopy! With Overwinter, Sapling, Blossom, and Heartwood that’s what happened — everyone chose to go with the new chain-fork with the new rules, and nobody chose to keep using the alternative. With Canopy there is a chain that people are using that keeps the alternative rules — Ycash. (Technically Ycash forked before some of the other Zcash Network Upgrades, just like technically Bitcoin Cash/BCH chain-forked from Bitcoin/BTC before the block size conflict was finally resolved, but politically, that doesn’t matter. Overwinter, Sapling, Blossom, and Heartwood were “uncontested forks” in which literally everyone upgraded at the same time as each other, just like the network upgrades that have happened on Ethereum. Canopy was, in contrast, a Friendly Fork event in which the blockchain split into two blockchains with a shared history, and now everybody can use either one or both.)
I think this is misleading terminology. It isn’t destroying funds, it’s choosing not to accept them.
A man walks into a shop. He says “I’ll take that product there! Here’s my payment.”
The shopkeeper says “Oh, sorry, I don’t take that kind of money. It doesn’t satisfy my requirements, and the people in my community don’t accept that kind. So I don’t want it.”
The man says “You can’t do that! You’re destroying my funds!”
The shopkeeper says “Whatever, buddy. I’m not destroying your funds. I’m just saying I’d rather hang onto my product until someone offers me the kind of money I accept in return for it. If you’ve got some of the kind of money that I accept, then that could be you! If not, good day to you.”
It isn’t the Zcash community “destroying other people’s funds”. It is the Zcash community saying “After a certain date, we’re going to stop accepting those funds”. That’s very different. (Or, after a certain date, we’re going to accept them but only at 99% value and redistribute the other 1% to the miners/dev-funds, or we’re going to accept them but only after imposing a 24-hour delay, or whatever terms they choose to impose before they’ll accept something.)
paper currency gets forked… try buying something with a really old $20 note
For what it is worth, I don’t know what other people’s reasons are for the turnstile, but my reason for the turnstile was formed before Zcash launched in 2016. While designing Zcash with the original team, I came to believe that widespread, long-term confidence in the soundness of the monetary base would require regular turnstiles. Everything that’s happened since then has reinforced my belief about that.
This directly conflicts with this
So if I understand you correctly, there is a hard cap at 21m and under no scenario can there be more than 21m. Any counterfeiting that occurs would be related to increasing the supply for coins not yet mined; but even if there was counterfeiting zcash hard cap at 21m would be enforced . is that right?
No, consider the following (extremely unlikely but theoretically possible) scenario. There is a bug that allows “counterfeiting” within the Sapling pool, and an attacker spends 50,000 ZEC out of thin air. There is now 50,000 more ZEC in existence than there is supposed to be, but no one knows it except for the attacker.
The bug (but not the attack that took advantage of the bug) is subsequently uncovered, and a new pool is created without the bug. Users are encouraged to migrate to the new pool, and it is decided that the Sapling pool will be deprecated within a year. As users move their coins from Sapling to the new pool, ZIP 209 preserves the integrity of the money supply going forward. That is, the incorrect “surplus” of 50,000 ZEC will not carry over to the new pool.
The “loss” of 50,000 ZEC is borne by the users who are last out the door of the Sapling pool. For simplicity, let’s say that everyone successfully migrated out except for one whale, who legitimately stored 100,000 ZEC in the Sapling pool. The whale decides to migrate to the new pool, 10,000 ZEC at a time. The first five migration transactions work fine, but when she tries to make the sixth migration transaction, it will be rejected because it would cause the expected balance of the Sapling pool to be negative. (Specifically, a block containing that sixth migration transaction will be rejected by nodes as a violation of the consensus rules.) So the whale is out 50,000 ZEC.
I like ZIP 209, because it restores the integrity of the money supply going forward. But there are other potential approaches, like “socializing” the harm caused by the attack (allowing the surplus of 50,000 ZEC to carry over to the new pool).
Got it—If someone is going to counterfeit and it’s private. It’s going to be massive—millions of coins. Seems like there has to be a better way. Such as connecting the creation of zec to time/block/something. It’s gets a stamp that can be traced back to its creation. If there is a conflict, then at least the bad actors can be more easily identified??
When was the last migration (date we know the supply is good)?
But that would seem to contradict the entire reason for a shielded pool in the first place, which is enhanced privacy and/or fungibility.
Because the Sprout pool has not been deprecated, such a “migrate and deprecate” process has never occurred. So it is impossible to definitively rule out the possibility of CVE-2019-7167 having been exploited. With that said, given the nature of the bug and the complete lack of any evidence that it was ever exploited, I myself believe that it was never exploited.
On the issue of deprecating old pools, the discussion in this recently started topic is excellent:
+1 Let’s have discussion about shielded pools in ebfull’s thread.
I don’t think this is a big deal since you can just write implementation details in a spec and have it continuously updated. For anything more specific, people can always just ask about it.
I’m missing something.
- drop support for previous value pools and maybe their snarks
- let you move funds out (transparently if necessary) forever?
Safety - people need to know when they buy zcash their money is safe. If someone bought 10,000 ZEC and put it into a trust, they need to know the investment is safe in 10, 20, 50 or 100 years from now. They should be able to put it onto a safe and know they don’t have risk associated with not moving to a new pool. Protocols need to be put in place to ensure people are protected from both inflation and changes made. It seems like something is missing here?
I’m having a hard time understanding how owners are not just moved automatically from Sprout to Sapling. If not automatically moved, it adds to the risk of owning Zcash doesn’t it? Although People should be given the choice to opt out (for who knows why they would).
This either requires a SNARK, or revealing the transaction graph for all unspent notes (in order to just open their value commitments). And the latter can’t be protected by having people spend to new notes before revealing, because doing that requires the SNARK that was just removed.
Some shielded pools might be amenable to implementing the removal process somewhat efficiently on a newer SNARK, but you still need one or more SNARKs that implement at least some parts of the prior protocols, and you need them around as long as you support moving funds out.
Right, it would be in the clear. So you’d have x years to get your money out of e.g. sprout in a private way. Then after that the money is gone unless you want to do it in a non-private way. Bad, maybe. Seems better than just saying the money is gone and you should have known because the plans “have been on display at your local planning department … for 50 of your Earth year”