Zcashd Deprecation updates

Ecosystem Updates
51

February 21st

Hello fellow Zebras! I want to start this update with a gesture of appreciation for @decentralistdan, @nuttycom, @zancas and @pili and others that covered for me on my public commitments last Thursday. It’s been one of those ugly moments when you have to drop everything you are doing to attend an emergency and my Zcash colleagues were there. As you may notice this is not being published Friday evening as usual and for that, I apologize.

Outreach (@pili @decentralistdan @pacu):

* Status: on track

We are currently focusing on Tier-1 contacts only to try to get as much of those as possible. Special thanks to core developers who groomed some timelines to aid us respond to inquiries from exchanges and mining pools regarding timing of the events towards NU7.

Zebra

Project Roadmap board
Priority board

In case you haven’t seen it, Pili put together another Engineering Update a few days ago. There’s a lot going on at the Zcash Foundation. You may have attended the FROST server demo by Natalie and Conrado. What does this have to do with Zcashd deprecation? Now that the FROST team has developed the FROST server, ZF is pausing further development on FROST for the time being all of its resources are dedicated to Zcashd deprecation and it shows on their board. From a total of 46 agile points of the current sprint, 42 are Zcashd deprecation items. @dodger wrote up a post about a possible path towards NU7 you should check it out.

Zaino (ZingoLabs)

  • status: off-track :warning: (but catching up!!)

Project Board

Milestone 2 work is progressing and the team is catching up to the previously announced delay.
The team is close to wrapping up milestone 2. Currently there are 2 outstanding items

Attention to all devs! There are PRs that need review.

Wallet and Block Explorer operators please check:

This Issue is tracking the indices that Zaino devs are identifying as necessary. If anything that you rely on is not here please reach out by commenting on the issue.

In-Memory backend wrap up

- status: pending review :warning:

This has been falling through the cracks a bit, we still need to provide reviews to this PR https://github.com/zcash/librustzcash/pull/1634

“Zallet” (that’s pronounced Zallè, like ballet) formerly Zcash Wallet CLI

  • Status: delayed :warning: (but rapidly catching up)

ECC has notified a deviation of 2 months from the original schedule.

tracking work on this repository.

As it was announced by @joshs on this weekly update librustzcash has been updated and a new release version of all of its crates has been created.

This is important because it lays an important foundation for the ecosystem. We encourage all developers that maintain their own forks of librustzcash to use this version as a milestone to update them.

In a previous update I mentioned the gap limit work that ECC had been working on as an important milestone for Zallet and also wallets that use zcash_client_backend crates.

> There is also substantial progress on transparent Zcash support by the gap limit implementation that nuttycom has done that will allow zcashers to recover funds from any wallet of theirs that used transparent ZEC and followed Bitcoin account and address management conventions.

This work was cut out of this latest release, long story short, I’ll put it in Nuttycom’s own words: “the gap limit stuff is a large enough change that we thought it should go in a release on its own”.

Wallet Export format

  • Status: Ahead of schedule

One of the pieces of the ZeWIF format is the ZIP documents how the Zcashd wallet.dat format was defined on each released version of Zcashd. @dorianvp has proposed a set of changes that @daira has reviewed and you can see them here.

Dorian is all over the place when it comes to wallet information stored on files and looking to collaborate on how the librustzcash sqlite crates store that information and how it would it fit ZeWIF.

TESTING TESTING!

I forward you a message from Wolf McNally from Blockchain Commons

I’d be happy to test against any drained wallets provided, and would obviously keep them in confidence unless explicit permission to release them publicly were granted. Also, I don’t even have to know the identity of the provider, as that’s immaterial to ensuring compatibility. Obviously in that case there would be no way to identify the submitter and therefore no way for the submitter to grant permission for release, so any anonymously-submitted wallets would have to remain permanently confidential. I’m also fine with pledging to sequester them on separate storage, and destroy all copies once the work is complete.

This is quickly becoming CRITICAL PATH, so anything you can do to help Wolf push forward: testing, advice, comments, and wallet files would be greatly appreciated.

Regtest? What is that?

  • Status: On track

Well isn’t that what everybody is wondering these days? Well not really, but it’s an important question to answer for developers.

I progressed on the HackMD document that will convert into a draft-ZIP in the next hours.

Thank you for reading.

Enjoy your weekend!

11 Likes