Hello. Yesterday @oxarbitrage, @str4d, @nuttycom, @ebfull and I spent some time fleshing out the tasks that are necessary for zcashd deprecation, and the dependencies between them. You can see a live view of these (generated from GitHub and Zenhub data) under “zcashd deprecation DAG” at the Developer DAG page.
I hope that this will help to clarify the work toward zcashd deprecation that will need to be done in collaboration between ECC and ZF. There’s a lot to do! The graph will be refined and added to as we go along.
Working with ZF’s engineers and project manager @pili is always a pleasure, and I’m sure we can make progress at a good pace.
I’ve replicated this list of capabilities to the relevant GitHub issue. Anyone else who has specific functionality they are currently using, please post there or ping us so we can include it there!
We already had some issues related to pool deprecation; I’ve now added DAG renders for them: Zcash sprout-deprecation DAG, Zcash transparent-deprecation DAG. These graphs needs significantly more filling out, but any subsequent gardening on that front will now be more easily visible there.
ZF and ECC engineers have discussed the architecture that wallets will use for the functionality needed to replace zcashd, and I think we’re now roughly settled on what that will look like.
In the upcoming librustzcash crate releases (primarily zcash_client_backend 0.13.0 and zcash_client_sqlite 0.11.0) there are a number of improvements to make the way that data is stored for the transparent protocol more similar to the shielded protocol. These are essential prerequisites to bring librustzcash closer to supporting the full transparent protocol. They aren’t yet fully reflected in the closed issues because we’re still finishing up some review and loose ends.
As a side effect of ZIP 320 / TEX address support, we now have most of the framework for derivation of transparent addresses consistent with a gap limit as defined in BIP 44.