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.)
As time has passed, I have changed my opinion on this and suspect that I am not alone. I believe that a new poll should take place given urgent recent changes in priorities.
I support deprecating v4 as soon as possible. This is to reduce surface area for both auditors and potential attackers, and to reduce the amount of work to be done over the coming weeks as we race towards Ironwood and zcashd deprecation.
It is already the case that there will be no Sprout wallet in two months. librustzcash and Zallet will not support Sprout.
Let’s deprecate Sprout in the next upgrade. And absolutely provide a way for Sprout holders to prove that they held Sprout and receive a reimbursement from one of our ecosystem’s nonprofit lockbox/reward recipients, time-boxed to a year or something. Let’s earmark funds for that, then return the funds after the time period expires.
Reduce surface area, speed up velocity. Ironwood is the way.