“The Sprout pool will be deprecated on February 1st, 2027. You need to move your Sprout funds before that date or you will lose them.”
I would very much like to be able to say that, but I can’t, because I don’t have authority to. It can only be a community decision. But we can certainly say now that an NU7 won’t activate earlier than, say, 18 weeks from when it is decided what will be included in it. So why not let that be the deadline for moving funds, rather than insisting that the deadline be the actual NU activation date? The latter has nothing particularly to do with this proposal and can be addressed separately.
The crypto press won’t report a deadline a year from now. Trust me. They won’t care. And even if, for the sake of argument, some did, those articles will sink without trace and people will still be complaining that they weren’t prominent enough.
I would very much like to be able to say that, but I can’t, because I don’t have authority to. It can only be a community decision. But we can certainly say now that an NU7 won’t activate earlier than, say, 18 weeks from when it is decided what will be included in it. So why not let that be the deadline for moving funds, rather than insisting that the deadline be the actual NU activation date? The latter has nothing particularly to do with this proposal and can be addressed separately.
My suggested process:
Token holder vote to ratify a final date
NU7 (or NU7.1) includes logic to say on blocks with timestamp > XYZ (AND blockheight > XYZ), v4 is disabled
Then we are fully done. So then the date gets encoded into the chain + software, instead of being at a coordinated upgrade day.
What’s the benefit? Are humans, in general, incapable of meeting a deadline that isn’t physically enforced? The zcashd internal wallet is going away, and we’re not going to delay that for a year. The community doesn’t want us to delay it for a year, and also, you can’t make us continue to maintain C++ code! (Tongue only slightly in cheek.) And therefore, any Sprout support after NU7 would be unusable, because even folks like @hanh who want to talk about hypothetical Sprout-supporting wallets other than the zcashd internal wallet, don’t actually want to implement one.
The possibility of someone being able to try to make it happen is fundamentally useful, and different from removing that ability. (E.g. someone could vibecode a zcashd fork that didn’t validate block data, and just peered to a single trusted zebrad)
Maintaining the possibility for a fixed period of time is valuable, even if noone is maintaining an option for it.
To be clear I am not saying that you should do that, I am saying that we as a community should have committed to a date at this point.
Yes, some people might still miss the announcements, the point is that having a committed deadline is to me simply a basic requirement for deprecating an entire pool.
And this is indeed orthogonal to V4 deprecation, the point is whether it is spendable or not, and not of there is a specific tool to migrate or not (but indeed, announcing the deprecation while having no working mechanism to migrate would also be not great)
The tool to migrate is a zcashd node with the -migration and -migrationdestaddress flags set. It was released in zcashd 2.0.5, in May 2019, over 6 years ago.
(Note that Sprout was only usable via a zcashd node in the first place.)