This past week saw a lot of improvements on the near [future priorities] (The Near Future of Zcash - Electric Coin Company) and improvements for the [1.0.8 release] (1.0.8 Milestone · GitHub).
Some issues we’re looking at include setting up better stress tests for memory usage of the client ([#2155] (Add long running test to profile memory usage of zcashd · Issue #2155 · zcash/zcash · GitHub)), 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:
- No contingency for block space (what we currently see now)
- An intermediate phase (perhaps when we see the first full block or a first spam attack)
- 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 https://z.cash 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] (Explaining SNARKs Part II: Blind Evaluation of Polynomials - Electric Coin Company) 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] (Show & Tell: Using Zcash encrypted memo field with zmsg - YouTube) to take place on March 31st, featuring [zmsg] (GitHub - whyrusleeping/zmsg: A small program for sending messages via zcash encrypted memo fields), 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] (Announcing the Zcash Foundation - Electric Coin Company). 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] (https://forum.zcashcommunity.com/c/foundation) in this forum specifically for suggestions to the Foundation and hope the community takes advantage of it – especially in these early days!