March 17, 2017 - Dev update

This past week saw a lot of improvements on the near future priorities and improvements for the 1.0.8 release.

Some issues we're looking at include setting up better stress tests for memory usage of the client (#2155), hosting a testnet faucet to help with various zcash development (#2119), a small bug in progress reporting in debug logs (#2111), adding a build flag for when dependencies aren't available (#2096) and cleaning up some references to bitcoin from the original fork (#1756).

We also had a topical meeting to discuss fee mechanisms. We started the discussion by breaking down the effects of fees in 3 stages:

  1. No contingency for block space (what we currently see now)
  2. An intermediate phase (perhaps when we see the first full block or a first spam attack)
  3. When there's high demand for transaction throughput

We didn't end up at a concrete solution but definitely made progress on considering the various options (constant fee, weighted randomized fee, dynamic fee based on average block availability, etc) and their consequences.We're thinking that by the time stage 3 would happen, we would already have solutions in place to mitigate it like BOLT and/or a blocksize increase. Our goals are to make fees as natural and user friendly as possible while maintaining security against detrimental flood attacks (while also considering the fact that the more minor flood/dos attacks we've seen in bitcoin have no lasting effect and should not stress too much about those.)
Because Zcash transactions with transparent addresses are lighter weight but don't offer privacy and transactions with shielded addresses are heavier weight but offer the private capabilities that we want to promote the use of, all of the models we discussed were not based on actual transaction size.

While we already have a Tor service hosting the site (zcashph5mxqjjby2.onion), we now have for I2P as well (zcash.i2p)!

We're still putting some final touches on privacy and security recommendations but are getting quite close.

We released the second part of our series on explaining zk-SNARKs to continue our effort in decypering the “moon math” behind the zero-knowledge system driving the privacy in Zcash.

As mentioned last week, a few of us will be attending the Tor meeting to see what kind of support our teams can give to one another. And relatedly, it's great to see the Zcash community thinking along the same lines.

We also set the next Show & Tell to take place on March 31st, featuring zmsg, a small program for sending messages via zcash encrypted memo fields.

Finally, while not explicitly engineering related, the Zcash Foundation initial board was announced today. This is the next step in pushing Zcash to a more community centric operation and we look forward to the Foundation's growth in promoting these values. There's a new category in this forum specifically for suggestions to the Foundation and hope the community takes advantage of it – especially in these early days!