This week started off with a retrospective meeting on our release process and more specifically the most recent releases 1.0.10 and the subsequent 1.0.10-1 hotfix. For the upcoming 1.0.11 release, we’re attempting a process where project coordinators for each of the Github projects nominate a few tickets to be considered by placing them into the newly created 1.0.11 planning project which are then triaged by the release coordinator. The coordinators for each project are specified in the descriptions.
In reviewing what happened during investigation and response phases which resulted in the 1.0.10-1 hotfix, we discussed the varying situations which affect our internal security incident response procedure. Our intended goal for all security incident responses is to remain as transparent as possible without risking vulnerability to users, their ZEC or the Zcash network, however many incidents may stem from an already public report or obvious behavior of the client. In the case of 1.0.10, several folks noticed problems connecting to non-1.0.10 peers after updating. We’ll continue to refine this process but would like to re-emphasize to anyone who may discover a sensitive security vulnerability to contact [email protected] using this pgp key. Any public discussion of security investigations occur in the #zcash-dev community chat channel.
Beswick is the codename for the project focused on enhancing basic payment features in Zcash. We had a topical meeting about the scope of this project and decided that deprecating/bug fixing non-
z_ calls, improving
z_sendmany and introducing new
z_* calls would all be relevant. An example of an improvement to
z_sendmany is spending from multiple addresses to one or more shielded addresses (#2408). An example of a new call is
z_shieldcoinbase (#2248). Features like private multi-sig and anything else slated for the Sapling upgrade or specific to payment offloading/payment disclosure are out of scope.
We discussed the general bad UX of using json encoding for creating payments with
z_sendmany that we inherited from Bitcoin and floated around the idea of higher level calls to simplify the UX which we dubbed
easy_*. Creating a GUI also came up but for now, we want to maintain focus on the RPC, delegating GUI development to third-party wallets.
We’re also interested in surveying the community about how they use
zcash-cli from exchanges, pools, wallets and end-users.
Website, UX & Documentation
We’re working on smoothing out our translation management process of the website. While being able to communicate to the global Zcash community is important to us, our current translation management has a lot of overhead and we’re finding inaccuracies in some of the translations so restructuring this has become a priority for us.
We’re also continuing to consult about improving the flow for visitors through the website in considering the range of interest and experience: from technical/developer to mainstream/don’t know what cryptocurrencies are.
We’ve reviewed the reports from the first stage of the UX research project we started and will be distributing this information over the next few weeks via blogs and potentially a Google hangout presentation.
More progress was made on centralizing documentation and we hope to soon have a single place for users and developers to go for tutorials and valuable information on using or developing with Zcash. We’re also going to look for a tool to host some of our meeting notes for public access. By default, we’ve been keeping meeting notes private but in a lot of cases, they can be made open to the community.