June 30, 2017 - Dev update

Release Retrospective
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 security@z.cash using this pgp key. Any public discussion of security investigations occur in the #zcash-dev community chat channel.

Beswick
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.

8 Likes

First Great Job to the ZcashCo Team for quickly releasing a hotfix due to an issue created from an update. This brings up a question of If the engineer’s that are currently working on the JPMorgan project been onsite, would the additional personnel caught the issue while in testing/ before it went live?

That’s a good issue to raise, but I don’t think having more engineers available would have been sufficient. The PR that caused the bug (Delete old protocol version constants and simplify code that used them. by daira · Pull Request #2245 · zcash/zcash · GitHub) was ACKed by two engineers independently of the person who wrote it (me), including one who was also working on the J.P. Morgan project. In my opinion, the problem in this instance wasn’t so much that we didn’t have engineers available to do testing and/or review, it was that neither our PR acceptance policy nor our release acceptance policy insisted on the testing that would have been required to detect this particular protocol incompatibility. (Those policies will be more stringent for 1.0.11 and future releases.) We also relied too much on our mental models of how the protocol negotiation from upstream Bitcoin worked, without verifying those models.

7 Likes