What do we do about legacy value pools?

I don’t think so, I think this is just about technical debt. Its a bad idea to have large pieces of old code laying around. it can break.


From a non-technical standpoint, this option sounds really promising.

Anyone that wants privacy is incentivized to exit before the deprecation. Whoever is left, you have no privacy left, but at least your funds aren’t destroyed.


Arnt the people who don’t migrate risking losing their investment if inflation as occurred?

1 Like

Yes, but that is always the case, regardless of whether you maintain the pool or deprecate it in some way. All the more reason to migrate sooner rather than later.

The bulk of the discussion in this topic is aimed at addressing a different set of risks. See this earlier comment in full:

It’s that sooner vs later concept that concerns me. If someone saves zec in storage. is there a risk when they try to re-deposit it, if there was inflation and they saved on a protocol that had inflation, they could lose it? If yes, then you would be protecting their money. Or if once you save it on hardware the zec is safe forever?

My understanding was migration uncovers the inflation, if any. So forcing/automating migration has the benefit of a) proving the supply and b) protecting owners because the last ones out lose. If there is inflation, the losses need to be socialized. Then, as people get confident the risk of inflation is low and the protocols are in place to ensure risks are reduced and hopefully ultimately eliminated from a supply perspective.

It would be great if zcash could make the statement. We had a bug where coins could have been created and the migration has proven there was no counterfeiting and the supply is x million. 0 risk to zcash. It’s the safest most secure private crypto.

I was under the impression that taddys would constitute the real extent of backwards compatibility at least for the forseeable future as the shielded pools are based on novel, rapidly advancing (and further funded for development as far as Zcash is concerned) mathematics and not the legacy clone though perhaps I’d feel otherwise if sprout pool functionality hadn’t already been significantly reduced.


Every time I create a cold storage wallet I send it a small amount and test recovery before trying again with a large amount.

The tool looks simple enough but I want to test migration process in the same manner before exposing my Sprout pool cold storage to the internet.

Unfortunately the network does not allow me to do this without help from someone with Sprout ZEC because I first need a small sprout hot wallet. I don’t have any way to send to a sprout address without first exposing my cold storage to the internet. I don’t want to do until after I have successfully tested the tool.


This is a joke post right?

I dont care how skilled at mental gymnastics you are, this was discussed in the dev fund debate. we as many other coins, like bitcoin, do not redistribute other people stuff (tho they are trying. coin taint/colouring is anti zcash right? or am i in the wrong place)

Also were you not arguing that deflation benefits everyone. remember burn? this is still burn. still just as abhorrent and hopefully still as hated by the SEC.

“If you dont do X i will take Y away from you”

I know/hope this is a playful thread, but people seem to be talking themselves into things.

1 Like

Curious, how Zcash community can do this? Is it done through some sort of poll then ECC makes software change, now it is upto partners & users to run it?

We’re all curious how ECC picks which consensus changes end up in zcashd. How can community influence these decisions? Zcash community has hired ECC, ZF, ZOMG for development, so it makes sense for this group to make software changes.

NOTE: this comment is neither supporting nor opposing sprout pool deprecation.


I guess I found the answer which I should’ve remembered.

[Extracted from z.cash]

In November 2019, Electric Coin Co. donated the Zcash trademark to the Zcash Foundation under an agreement that stipulates both parties must agree on any network upgrade that would create a new consensus protocol of Zcash. Zcash governance depends on community input. The trademark agreement prevents either party from taking action that is blatantly contrary to the clear consensus of the Zcash community. “Clear consensus” is determined through community polling within and outside of the Community Advisory Panel, a group of ~90 volunteers with extensive interest and/or knowledge of the Zcash ecosystem.

1 Like
  1. We should encourage long term cold storage (ZODL).
  2. Avoid creating new pools (new pool itself may have bugs while old pools are “proven” safe for longer periods of time).
  3. Kill mandatory turnstiles. It’s an ECC thing not sure if any Zcash user likes it.

With that said, we can make exceptions (ex: Sprout, Sapling have trusted setup, is that good enough reason?) or create incentives to move to new pool.

Off-topic: I feel like if we have PoS then we will see greater adoption of upgraded pools (old shielded pools cannot be staked but can be stored etc).

Again ZF, ECC, Zcash scientists, academia experts should work together & propose a plan for community & users approve of it.

How are exchanges meant to handle this?

1 Like

Sounds like the turnstiles was designed as a backstop measure to ensure no inflation. They are necessary until is proven no risk to inflation. Any other purpose?

1 Like

Exchanges are like anyone else: They need to know in advance what our deprecation schedule is going to be, if any, so they can keep custody of their funds. We haven’t really established a schedule or any long-term expectations, which is my main concern.


I see where you are coming from.

im reading this two ways
1 - no one should know the depreciation schedule, isnt that what gives coins value? I thought zcash was 21m max not 21m.

2 - I disagree with the attitude, but it is similar to halvings. my main issue is explaining to people who have their zec stashed away. bitcoin made a massive point of your priv key will always work. This seems like a massive deviation.

3 - i get the problem and something needs to be done about it.

oh and 4 - you are just speaking outloud, no need for pitchforks.


And if none of this applies(like old paper wallets) Make available a simple linux-cli software made to allow users to move the funds one-way to the latest shielded pool?


The following are my own opinions, and not indicative of any ECC policy.

I think what @ebfull is pointing out is that there is a maintenance cost associated with maintaining the ability of the network to verify spend authority of notes in old pools. That cost is somewhat higher for a cryptocurrency network than it is in other kinds of applications, because security analysis must take into account any potential interactions between newly added features and old, deprecated ones.

If deprecation is never followed by removal, then the cost continues to grow over time. If that cost grows so high that new features cannot reasonably be added to the protocol, then what will probably eventually happen is that a fork of the project will remove the ability to spend from those pools, just so that the technology can move forward. In my opinion, what this discussion is about is explicitly planning for such an event, rather than having it happen in a more uncontrolled and/or damaging fashion.

I think that this is also what @zooko means when he says that it’s up to the community. If a future fork of the Zcash blockchain (regardless of what that fork might be named) delivers better value to a majority of Zcash users in such a way that the dominant fraction of the exchange value Zcash notes follows that fork, there is no guarantee that those coin holders of “legacy” pools left behind by that fork would have any ability to spend their funds (on the new fork). So paper wallets, crypto cabochons, and so forth might lose value. And that’s not something that any entity has control over - it’s a collective decision made by a market.

I interpret the purpose of this discussion to be find a path that minimizes the fragmentation by having a transparent discussion of all these issues ahead of time. Then if at some point such a fork occurs… well, at least it won’t be unexpected?

With respect to the idea of software that allows users to move funds one-way, such software depends upon the network being able to validate that move. So there’s not a straightforward way to reduce the technical debt I mentioned earlier until the network can stop validating those moves.

Without knowing the detailed implementation and technical debts, would it be possible to remove support for deprecated pools from zcashd while still having the ability to enable one-way claiming of deprecated pool funds to “generate-new-coins” in the latest shielded pool by maybe just storing a snapshot of the deprecated pool?

With the ECC & ZF entities having a direct control over the software released by them, the market is more likely to default to the decisions made by people in power.

To convince new users, I believe the guarantee of support to claim funds from user’s old savings is a very important aspect of digital money or else the project is no different from a bank in a corrupt system that keeps draining user’s long term untouched funds. There has to be a way to redeem old funds even via a snapshot like system.


To convince new users, I believe the guarantee of support to claim funds from user’s old savings is a very important aspect of digital money or else the project is no different from a bank in a corrupt system that keeps draining user’s long term untouched funds. There has to be a way to redeem old funds even via a snapshot like system.

I don’t disagree that I would also personally like such a guarantee! What I’m saying is that I don’t think anyone (including ECC and ZF) can, or should be thought to be able to, project that degree of influence into the indefinite future. And I think that’s at the heart of the problem. The ECC and/or ZF could make statements about what kinds of backwards compatibility they intend to support, and then someone could fork the chain with new functionality that’s so compelling that everyone would move away from the ECC/ZF supported protocol anyway. The “market deference” you mention is the only thing that prevents that, and I believe that the market will only remain “deferential” insofar as the ECC and ZF serve the needs of the community. If the ECC and ZF don’t serve those needs, people are much more likely to just go use other coins.

So, if the community puts a high priority on backwards compatibility, it’s much more likely that the ECC and ZF will try to find a way to keep it. Snapshotting the chain might be part of such a solution, or there might be other options. Maybe this discussion is inextricable from understanding fully the possible implementation of such solutions.


Looks like rules are being defined for (new) shielded pools: https://github.com/zcash/orchard/pull/6#issuecomment-756427210

Please discuss with Zcash community & users before ECC makes any rules (please don’t say you can fork or run modified software, it makes Zcash funding ECC through block reward meaningless if majority of users, partners, miners run Zcashd).

cc @tromer @Matthewdgreen @secparam

1 Like