What do we do about legacy value pools?

Is it possible to send an automatic message to all forum participants about the need to migrate?

It’s necessary to make every effort to cover this issue in special media. I think that it is possible to reduce the Sprout pool by at least 10 times.
Zcash has never been cheap, so there can’t be any lost coins in such a large amount.

Yes, but the issue is that there is no way to notify every single person who has ZEC sitting in the Sprout pool. Not everyone who holds ZEC has a forum account.

Provided people are given enough time & every attempt is made to tell holders…yeah, turn it off.

How about making a node shutdown every 50 blocks if it has a sprout balance - would encourage migration. Forced migration, sure - that’s a good final measure.

Its just a question of ‘how much time’ and ‘how many ways to tell everyone’.

109979 Sprouty ZEC - thought it’d be bigger.

1 Like

A 500 day runway (which is about what Daira proposes) is a good amount of time and, if the case, every best effort should be made throughout the community to make it as blatently obvious as possible.


This discussion should be fairly widely observable throughout the community as well. I think the overall consensus will be “hell yeah!” but destroying peoples money is serious. The fact were talking about it at all should come as an alert to any sprout users but should come as much before any decisions are made as possible.

1 Like

What I don’t quite understand about this is how anyone has funds still sitting in Sprout at all?

It’s been well published for years now that Sprout is old tech and should not be used, could it be that the ZEC sitting there represents “lost” ZEC? Similar to how they say that up to 20% of all BTC is inaccessible? Even at 100K the Sprout pool is about O.5% of all ZEC.

1 Like

Fun thought experiment…

What if the Sprout pool is eventually destroyed, but rather than destroying the funds, the funds are redistributed to people who do liquidate their funds from the Sprout pool? (In other words, you can purchase some kind of “shares” with your Sprout ZEC which eventually becomes redeemable for the corresponding fraction of the Sprout pool’s ZEC when it is destroyed.) This might incentivize people to move their funds from Sprout, no matter how small, as they could potentially extract enormous gains if a sizable portion of the Sprout pool are in lost keys. :stuck_out_tongue:


The most immediate obvious downside to me is that it would discourage people from ever migrating to a modern pool except when the old one is being destroyed, as they could earn money from lost funds… not sure how bad of a Bad Thing that is.


I could think of a case (and similar derivatives of that case) where somebody could have funds stored in the Sprout pool and will not access it in the foreseeable future.

Somebody sets up an “account” for a minor that could only be accessed once the minor is of legal age. Then a lawyer or trust gives access to the funds. Perhaps the contract is sealed and could only be opened after 10 years or the initiator has passed away.

But to the question of what we do with the funds, I’m definitely not in favor of “destroying” the Sprout pool (as in holders lose the funds). We should find a way to automatically force-migrate the funds to Sapling (or any future shielded pool for that matter) and have those funds available to the respective owners when and if they choose to access them. I understand that it may be impossible to do that in a decentralized way. Perhaps some smart folk can come up with an idea.

That said, if it’s decided to destroy the pool and funds either get lost or redistributed to all Sapling pool participants or whatever, I’ll back that decision too. But it will be a very controversial decision that I’d rather avoid.

In any case, I still think that destroying the transparent pool is a more important, pressing and fundamental matter. The Sprout pool decision can follow right after that…


Taddys is a different discussion and if we’re waiting until they deprecate first then I think its prolly gonna be a while. Assuming the technology would remain unchanged for a decade is more of a bitcoiner trait and then the question of why deprecate taddys at all comes up. The sprout pools been pretty much untouched for a while (a FEW coins here and there) and I share sentiments about destroying funds, I dont like it but like Shawn said its been up and coming for a while with its functionality beind reduced and will inevitably be deprecated and all sprout zec lost unless someone comes up with a clever workaround which hasn’t happened yet.

Isn’t the “clever workaround” in the meantime to continue supporting transactions sent from the Sprout pool? Inaction means that these funds aren’t lost. How will anyone take seriously the push to store funds in the Sapling shielded pool if we’re being so hasty here to kill the old pool and the funds in it? The threat of killing funds definitely weakens the argument in favor of shielding funds.


How would you know which addresses to give funds to? Would they be sent to the same transparent addresses that receive funds from Sprout? What if they migrated without using a t-address?

To be clear I think that killing of funds in any form is a terrible place to be. Continuing support for sending funds from Sprout should be the top priority.

We can’t support Sprout forever, someday it needs to die. (For one thing, it will not operate at scale, and for another, it is a permanent burden and security risk for the protocol.) Different people will have different interpretations of “hasty” and in fact my goal of opening this thread was to begin a conversation with the community that can set the stage for deprecating Sprout on whatever timeline is appropriate – even if it’s years from now. We can’t just start having this conversation when the burden of maintaining Sprout becomes more dire. (In addition, having the conversation now allows us to set better expectations for what will happen with Sapling.)

I’d also like to know what people’s appetite is for destroying the funds (versus other options). Clearly you’re strongly against destroying funds on principle. I and several other people in the community don’t care about destroying abandoned funds nearly as much. Some people think destroying abandoned funds is a good thing regardless of the goal of deprecating old protocol baggage.

Hopefully we can start to tease out a consensus.

1 Like

The idea (which is more of a thought exercise meant to tease out other options on the table) would be to let people who still have ZEC in the Sprout pool to “spend” it in exchange for some instrument which then obtains a proportional amount of ZEC when the Sprout pool is destroyed. ex: If 10 people do this with 1000 ZEC each, but 90000 ZEC remain in the Sprout pool, they split the 100k ZEC ten ways.

The staggering difference in performance should have basically clued everyone in as to whats what and Im sure there was some chatter here or there about the eventuality. This was 2 years ago and another year and half I think certainly counts as an extensive window. Deadlines are good, gets people motivated.

1 Like

After reflecting on this a while, I’m now even more strongly in favor of the idea i posted up thread a bit…

Let me explain it again a different way though… the idea is that we introduce a new consensus rule that deems legacy Sprout transactions invalid, however we also commit to providing some kind of tool that someone could post somehow out of band (via zboard, the forum, or whatever)… (Even just a valid transaction crafted by an old version of zcash would be sufficient)… If someone posts such a transaction, i.e. proof that they wish to move something from the sprout pool, then we’ll commit to supporting it at some later date.

This gives the technical benefits of dropping support for the legacy sprout pool in the typical/expected case, while still offering a backup social process that avoids actually destroying anyone’s legacy coins.

Pretty much the only downside here is that someone with Sprout dust could go and grief and trigger this legacy development debt scenario. Maybe setting some threshold amount would address this…


Make sprout minimum fee really expensive (0.5 Z) starting from next NU, double it every NU for a while, then kill it.

Otherwise we have ‘backwards compatibility’ forced on us by squatting sprout trolls - anything that gets in the way of scaling has to die.


I want to push back against the “security risk” point. That’s what mandatory transparent migrations (turnstiles) address, no? You’re addressing the security risk of these Sprout funds possibly being unspendable by making them what, definitely unspendable? Am I missing something?

1 Like

I like this idea a lot. To play devil’s advocate, I’d suspect that a huge portion of people who suddenly decide they want to spend their Sprout ZEC suddenly years from now are doing so because ZEC mooned and they saw it in the news and remembered they had some lying around on an old laptop. They’d be pretty unhappy to find out they may not be able to spend it for a while during a market bubble.

Nevertheless that seems like a decent trade-off.


The security risk isn’t just that Sprout would be compromised and allow inflation. That’s actually the least concerning risk, IMO, because of the turnstile.

The real risk is how Sprout interacts with the rest of the protocol. It’s a portion of the transaction structure, its value flows in and out of other value pools, nodes must track and maintain the nullifier set and commitment tree, signatures must be checked over hashes of portions of the transaction and these change as the transaction format changes, Sprout uses ed25519 for this so we have to keep ed25519 support forever, similarly we’d need a Sprout proof verifier code written in potentially antiquated libraries and curve implementations, … I could probably think of a few other things.

Generally, the less stuff happening in the protocol, the simpler it is to maintain and improve with minimal security risk going forward. (Similarly, I anticipate Sapling will be in the same position as Sprout someday.)