With the upcoming [1.0.6 release] (1.0.6 Milestone · GitHub) slated for Monday (Feb. 13th), a lot of the engineering effort this week was focused on final editing and reviewing of pull requests. Our Monday engineering meeting took a look at all remaining issues in the 1.0.6 milestone and confirmed whether addressing them was feasible for this release or should be pushed back to [1.0.7] (1.0.7 Milestone · GitHub). To reiterate the 3 week release cycle process: last week’s triaging for the issues we would like to address in the upcoming release was done with a rather optimistic mindset while this week focused on realistic gauging of the current and next milestones. Next week we’ll look at big picture planning and then start the process over with optimistic issue triaging for 1.0.7.
In addition to all the new concepts we want to develop into Zcash, we’re also looking at the changes from Bitcoin v0.11.2 (the version from which Zcash forked) and Bitcoin v0.12.0 to see which parts we want to eventually merge into Zcash. Some of this work has already been done but engineering focused time this week on creating an overview of code changes between the two versions to give us a concrete list from which to work.
Our topical engineering meeting this week focused on [delegated proving] (ZIP: Delegated Proving T (DPT) Protocol · Issue #104 · zcash/zips · GitHub), a feature which will enable light client support for sending to shielded addresses. While one of our priorities is to reduce resource requirements for this operation, we think it is additionally important to prioritize alternative methods for shielded address support for hardware with significantly reduced resources, such as mobile devices and hardware wallets. One perspective of delegated proving is as a third-party service where the user’s trust should be minimal. Another option would be that the user sets up their own personal proving service allowing for much high trust. For example, a Zcash user may set up a delegated proving service on a home computer to offload some processes for transactions sent from their smartphone. Specification and development on this feature will be ongoing so keep an eye out for updates.
Specification on formalizing the [ZIP process] (GitHub - zcash/zips: Zcash Improvement Proposals) continued this week with some work put towards drafting the first ZIPs (i.e. [standardization of memo field formats] ([ZIP 302] Memo field format specification · Issue #366 · zcash/zips · GitHub) and [payment disclosure] (payment disclosure · Issue #2036 · zcash/zcash · GitHub)) which will continue next week. Additionally, the [protocol spec] (zips/protocol.pdf at main · zcash/zips · GitHub) has reached a state where it’s ready for publication. We plan to submit it to [Cryptology ePrint Archive] (http://eprint.iacr.org/) next week.
The network experienced a [security hiccup] (Security Information - Zcash) this week when a mining pool running Zcash v1.0.2 [could not sync with the main network past block 58969] (1.0.2 node unable to reorg to main chain past block 58969 · Issue #2076 · zcash/zcash · GitHub). It was determined this was most likely caused by a [bug] (Zcash Daemon Sync Issues · Issue #1769 · zcash/zcash · GitHub) which was fixed in later releases. An alert message was sent to nodes running v1.0.2 and below putting them into safe mode and disabling critical RPC functionality requiring an upgrade to a more recent version to re-enable. A lesser alert message was sent to v1.0.3 nodes requesting an upgrade to a more recent release without a safe mode trigger. This event prompted focus on improving [chain fork detection] (Internal Chain Fork Detector · Issue #1925 · zcash/zcash · GitHub) and discussion on improving communication on critical security events. The pool which reported this incident has since upgraded and are successfully mining on the main chain. We would like to take this time to encourage node operators to keep up-to-date with the newest versions and always review the [release notes] (releases Archives - Electric Coin Company) for security related information. Discussion on this particular event is happening in [this forum post] (Recent chain fork (not actually a chain fork)).
Additionally, improvements to the revamped https://z.cash were integrated and next week, we hope to include more documentation on zk-SNARK so the site can be a primary resource for those interested in learning more about this technology regardless of technical background.
Some research was also done on [user defined assets] ([ZIP 220] Zcash Shielded Assets (previously UDA or UIT) · Issue #830 · zcash/zcash · GitHub) and the [security level of the BN_128 curve in libsnark] (understand the concrete security level of the BN_128 curve in libsnark · Issue #714 · zcash/zcash · GitHub).
On the community side of things, we’re hosting another [technical AMA in 2 weeks] (Technical AMA w/ Zcash core devs Feb 24, 2017 noon PST) and will continue hosting monthly Show & Tell presentations after a [successful first event] (Zcash Show & Tell: David Mercer (Mac & Windows client port developer) - YouTube) which took place last Friday featuring @anon47418038 discussing his work on MacOS and Windows client ports. Let us know what you thought and any ideas for future presentation topics or projects.
Stay tuned for the 1.0.6 release announcement on Monday and next week’s engineering update!
