Sprout is still on because nobody likes the idea of destroying peoples money. Despite the feelings implied by some I know they certainly wouldn’t want it to happen to them. That said, it outdated half-the-time-the-project-launched ago and no one is seriously suggesting a support halt in less than at least a year from now (a 4 year life seems pretty good, nice N square). Prof Millers idea seems dependent on that threshold. What if 1 zec were like $5000 and then why turn it off at all if to just reactivate it on edge cases? Is it practical to do that?
2 Likes
I think that idea involves disabling the sprout pool until it potentially needs re-enabled. I think you’re talking about splitting off that value pool but providing a consensus mechanism and ability to mine to sprout shielded coinbase so it continues. Whether thats possible to do or why any non-sprouters would want that (besides it being just another coin to try mining and probably empty blocks at that), I dont know. Seems easier to just chainfork but then, and like above, it isn’t Zcash anymore, maybe you can trade it for Zcash? Idk
2 Likes
Interesting parallels with how old-version bank notes are handled - you can exchange them for a while.
3 Likes
That is actually really interesting but these aren’t notes, we’d need a bank and I don’t think I’m the only one like not really hip to the banking system 
!
1 Like
How about this as a restriction/exchange for further down the line -
- Sprout ZEC can only be spent to a given Sprout Address and must include a memo containing a Sapling address
- The receiving Sprout address is special, its the only one that can do Z-to-T
- The receiving Sprout address migrates its funds into Sapling
- Funds are returned to the Sapling address provided by the original sender
It would have to be handled by a trustworthy org, it smells like a service an exchange could offer
EDIT: Gemini ??
1 Like
It shouldn’t be centralized (though exchange can do it automatically, I suspect they are using sprout at-all), at-least there should be open-source tools, wallets doing this for ZEC holders.
No one is going to oppose doing a hardfork (w/ additional tools) vs just destroying funds (imagine increased negativity towards zcash & frustration of sprout holders). If this works, then we could do it for halo etc
Even better, this could be done as part of halo upgrade! (in a single hardfork)
This “trade” is supposed to imply sending your forked-from-Zcash tokens to an exchange and maybe “trade” them to somebody who will give you Zcash and not a voucher system that negates the purpose of turning it off
why?
The FR was the anti ICO. I for one have never invested in one or have any concept of the rules. Neither did my brother when he bought and mined his zec.
I would run your idea across multiple lawyers across multiple justrictions.
just my 2zats
The thought experiment of — what should expectations for /future/ (i.e. post-Sapling) value pools be like? — is a good and worthwhile one. At the same time, destroying UTXOs and z-UTXOs /post-fact/ is not acceptable, and seems close to invalidating Bitcoin’s ECDSA UTXOs after Schnorr activates. (This, of course, is an imperfect comparison as merely 15% (edit: not majority) of shielded ZEC value is locked up in Sprout zUTXOs… yet ~all BTC value is locked up in ECDSA UTXOs.) Zcash users have a strong reliance interest of not having their ZEC savings wiped out, and changing this would damage the credibility of the project.
For some users, say, a two year warning might seem ample but this is infeasible for others who have long or expensive key recovery processes. For example, if one invalidated Sapling pool, it would crush the innovative ZEC Cabochon artwork.
What are the concrete ongoing maintenance tasks for Sprout? I’d definitely support making Sprout deprecated / “if you don’t migrate, you are on your own if someone finds a bug” (like users who have non-standard OP_RIPEMD160, instead of OP_HASH160 UTXOs would be) / you need to download this special software to create Groth16 proofs for Sprout migration, but that’s separate from keeping the mature Sprout Groth16 verification / nullifier check code in zcashd.
8 Likes
The problem that @ebfull is stating is less about ongoing maintenance to Sprout specifically, and more about ongoing maintenance to the Zcash protocol as a whole. Making any additions or changes (whether in network upgrades or just regular zcashd updates) requires reasoning about how the changes interact with the entire protocol, and so long as we maintain full protocol support for Sprout, it needs to be fully factored in. It also adds to the cognitive complexity of the protocol, which is a problem for new development teams who want to onboard to Zcash.
As a recent example: I have spent non-trivial time explaining the details of how the incremental Merkle trees work for Sprout and Sapling to the zebra developers (several times, because there’s a lot of nuance that takes time to absorb!), to help them understand how to integrate it into their tech stack. As long as full Sprout support is maintained in the Zcash protocol, we will need to keep explaining this facet of it, and making accordances in the various tech stacks to handle Sprout’s idiosyncracies.
3 Likes
Thanks for the explanation! Can totally see how maintaining full Sprout protocol compatibility is draining. But what about partial Sprout compatibility (being able to validate Sprout transactions)? For example, ZecWallet Lite and Nighthawk Wallet don’t support consuming Sprout UTXOs and thus don’t need to worry about Sprout key agreement/note construction/etc. (I don’t know if a treestate for tx validation is easier to maintain than a treestate for wallet, though…)
Because Sprout and Sapling prudently use domain separation and distinct cryptographic primitives, it would appear that possibility for something breaking in Sapling (or Pollard) because you were validating Sprout proofs (and checking Sprout nullifier duplication and updating treestates) is similar to something breaking there because we are still validating the transparent pool.
I’d even argue that it is fine (but likely not worth it, as it would require a new design) to eliminate JoinSplits (and thus adding to Sprout treestates), provided there is another way to consume Sprout zUTXOs. However, it is not fine to force ZEC held in cold storage on an upgrade treadmill. Just like for Bitcoin, the protocol can be forked (or improved on!) but the community/UTXO set can’t.
4 Likes
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).
- The
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.
8 Likes
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)
2 Likes
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.
Neat idea!
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.)
2 Likes
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.)
4 Likes