This note is about the Electric Coin Company’s process for deciding what features it will implement and support in its
zcashd software. This is not about what the Zcash community will or won’t do with that software. That’s outside of my purview. The purpose of this note is to clarify some things about our current process within the company.
The main focus of the current process is the Network Upgrade Pipeline: https://z.cash/blog/the-zcash-network-upgrade-pipeline/
One really neat thing about this system (designed by Nathan Wilcox with help from Mary Moore Simmons and others) is that there are now “entry points” where external third parties could supply Zcash Improvement Proposals, implementations, etc., and we know where those could “plug in” to this pipeline. The next deadline for that is the end of February to submit Zcash Improvement Proposals which we could consider for inclusion in NU3. The Feature Selection step for Network Upgrade 3 (which will activate in the spring of 2020) is at the end of May of this year. It’s the green “Upgrade A” bar on the diagram.
Now about the Feature Selection process: What we currently do in the Electric Coin Company is that we have one person who is the decision-maker for the next network upgrade. That’s typically Nathan Wilcox, the company’s Chief Technology Officer, and he approved all of candidate features that we were considering before he left for vacation (including Harmony Mining, and the time-locked-Alg-B-rewards part of Harmony Mining). Since he left for a long winter vacation, he left me in charge of that role, and the rest of the engineering team and me subsequently dug into a lot of details about the various proposals that he had approved and decided to exclude the vast majority of them because we wouldn’t have time to do more than a couple of them right. We wound up with Harmony Mining, Faster Blocks, Split Founders Reward, and “keep tx v4 working through ‘Blossom’ Network Upgrade 2” Blossom Upgrade Goals.
Now we could have a process in which there were multiple decision makers who had to collectively agree on the contents of such decisions, effectively giving multiple decision makers a veto, or having a panel or board or group which voted and having some threshold of votes, or something, but I think that would be a bad idea. I think for safety/security, coherence, and speed of execution it is better to have a single decision-maker.
Now you might disagree! That’s fine. Maybe you think it would be better if the Electric Coin Company used a different process than this one, or had a different person than me serving as the final decision-maker. I encourage you to make up your own mind about such things. The purpose of this note is to let everyone know what the current process is, so that you can have accurate expectations what the Electric Coin Company will do in the future, and you can decide how you want to deal with that expected behavior.
So, our current process means that with regard to the dual-PoW component of Harmony Mining, as well as with regard to the time-locked-mining-rewards portion, as well as with regard to the Faster Blocks part, anyone else, such as Daira, has until tomorrow (Monday the 7th) to convince me that it is such a bad idea that we have to throw out our entire plan and ship the Blossom software with a radically reduced set of changes. If they don’t, then we (the company) will commit to vetting and implementing the chosen set of changes. We’ll then have about 9 months to verify that there aren’t design or implementation flaws which could threaten the safety of users — that’s the biggest part of why the Network Upgrade Pipeline takes so long — before it activates on mainnet.
In particular, note that the process does not require persuading Daira that a particular feature is a good idea. We can go ahead with this process as designed even while Daira thinks that some elements of it are terrible ideas. That’s a healthy and normal expected part of this process.
I’ve seen that Daira recently posted some simulation results on the github thread showing security trade-offs of dual-PoW mining. That’s great! That’s exactly the sort of precise, critical analysis that we need. I intend to spend much of the rest of today studying that. The results are currently quite preliminary and I expect it will take several weeks — at least — of refined analysis and discussion to understand the precise impact, if any, on user safety. We could lean to the side of caution by removing Harmony Mining from the NU2 Goals now, allowing us to focus on just Faster Blocks, Split Founders Reward, and Keep-Txv4-Working for NU2, or we could lean to the side of ambition by keeping Harmony Mining in the Goals, at the risk that it would subsequently turn out that it wasn’t safe to deploy, and we would have spent time and effort on it which we could have spent on other projects. I’ll be making that call tomorrow.
By the way, I think the new “Grin” coin, which is due to launch soon, is doing a dual-PoW system, too. This is very good for us, because it means we can learn from what happens to Grin in practice, as well as learning from their design decisions and analysis. Going the other direction, if there are any Grin people reading this, you might want to check out the analysis we’re doing on the Harmony Mining github thread! It’s a lot more urgent for Grin than for Zcash since Grin is going live with it quite soon if I understand correctly.