What the Foundation has stated is that Zebra will not have a built-in wallet, like zcashd does.
However, we are prepared to collaborate with the ECC engineering team on a joint effort to create a separate CLI wallet (that uses zebrad as its back end) that can replace the zcashd built-in wallet for key users (e.g. exchanges).
Great. Thank you for the clarification.
Is the ZF open to owning and supporting a CLI wallet for third parties?
I think the primary concern right now are miners and some exchanges. The exchanges all use taddrs, it’s more complicated with the mining community.
Perhaps there needs to be some clarification on exactly what functionality Zcashd provides for miners and exchanges that Zebra backed wallets like Zingo, Ywallet, Zashi, etc… currently do not.
Desktop version? Linux version? Multi-sig? Interface with BTC era mining pool software?
With Zebra as the backend it may make sense to simply support one of the existing wallet development teams to add the needed functions to one of their wallets?
Although I must say I already don’t like the direction this is headed, for 8 years we have been at the mercy of fickle wallet teams (WinZEC, ZecWallet, etc…) and look where it has gotten us, fragmentation.
Once a “good enough for exchanges/miners” version of a Zebra interface is up and running could not one of the core teams (ECC/ZF) hire a dedicated engineer to update and maintain it?
ZF’s resources are already stretched. We receive the smallest slice of the Dev Fund, and our engineers have no prior experience building a CLI wallet. The expertise in that area lies with ECC’s engineers, who built and have been maintaining, upgrading and supporting the zcashd CLI wallet for the past eight years.
We agreed to work with ECC to make it possible to deprecate zcashd and allow users to migrate to Zebra, including working together to build a new CLI wallet that uses Zebra as its backend. And if we build it together, we need to work together to maintain and support it.
We have been discussing this internally and have had prior conversations with others in the community. There are a few possible paths here.
Earlier today, I sent you an email requesting a special edition of the Arborist call that includes you, Shielded Labs, Qedit, and us to discuss the scope and timelines of NU6 (Q4) and NU7 (target Q1 '25 along with zcashd deprecation). Let me know if that won’t work, and we’ll coordinate a separate public meeting. We need to move quickly, as we’ve run short on time for NU6 updates if the upgrade is to occur in November.
One team one dream right?
So much talent and heart in these orgs.
(I’ve created a separate topic re: scheduling the NU6 and NU7 discussion.)
What are the possible paths as you understand them?
Who are these “others”, what have they built, and if they have built something that may be useful (which would be great news!), let’s invite them to Thursdays call?
(By the way, if you’re referring to QEDIT’s transaction testing tool, it only supports Orchard transactions currently.)
I don’t think anyone’s suggested doing a simple cutover. Users are going to need time to test and migrate to the new solution(s) for their use case(s). That’s why we need to develop a sense of urgency - the time to migrate is not trivial.