A note on Electric Coin Company process



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.

January 11, 2019 - Weekly Update (Community + Comms)

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.

From the Foundation perspective, I think it would be great to foster more public discussion (and proposals for inclusion) into NU3, and the ZIP process is a great match for that. Additionally, it would be great for the Company to submit its own ideas through such a process, so the public would have an opportunity to discuss them with a fair amount of leeway before a network upgrade; would help a great deal with transparency and help transition to more input from more stakeholders prior to a network upgrade.

Speaking of the ZIP process, I’ve been working on a draft of a new iteration of the process that I hope the Foundation can take the lead on—still waiting on some feedback but hope to share it soon and that it might encourage more submission and discussion as above.


Josh: this sounds like a great idea! I’d definitely be into having the new proposals put forward by the company go through this pre-specification process before Feature Selection. Also I’d strongly encourage others to submit proposals. Topics that I’d love to see proposals for include:

  • Toxic-waste-free proving systems (Bulletproofs!) or other cryptographic techniques to further prevent and mitigate cryptographic breakthroughs, bugs, etc
  • Vitalik Buterin’s min-fee proposal: https://github.com/zcash/zcash/issues/3473 I guess the github issue he opened doesn’t count as a proposal for this new process, though, and instead he or someone needs to reformat it as a ZIP and submit it? I’d like to know precisely what the difference is between a github issue like that one and a Draft ZIP.
  • Rental fees for old UTXOs and spends from old shielded pools: https://github.com/zcash/zcash/issues/3693 (This is probably the best, most immediate step in the project of “deprecate taddrs”.)
  • Switch from Dual-PoW to Triple-PoW/PoW/Proof-of-Stake
  • Payments to Sprout (Zcash 1.0) zaddrs are consensus-invalid
  • Reserve space in each block for fully shielded transactions: https://github.com/zcash/zcash/issues/1133 (This could now be updated to say reserve space for Sapling-only transactions.)
  • https://github.com/zcash/zcash/issues/829 / https://github.com/zcash/zcash/issues/3667
  • “Slow Money Spell”, “I-Got-Burgled Button”, shielded time-locks

In addition I’d love to see what other ideas people have that they are willing to write up a Draft ZIP for.

Remember, the deadline for Draft ZIPs to be considered in the Electric Coin Company’s NU3 Feature-Selection process is end of March, so that there are two months between submission of the Draft ZIPs and the final Feature Selection. https://z.cash/blog/the-zcash-network-upgrade-pipeline/ If a Draft ZIP misses that deadline, the deadline for inclusion in the NU4 Feature Selection process is end of September.


For clarity on ZIPS https://zcash.readthedocs.io/en/latest/rtd_pages/index_zips.html


I agree with this ONLY if them voices will matter. Having open disucussion is great and all, but if the end result is they have zero effect on the “vote” why even have a discussion than?

There was TONS of discussion on ASIC when they were announced, the “majority” of people on the fourms were totally against them. But they were a “minority” of the people that used Zcash I guess, so they were not heard it seems. How can we prevent this in the future, and make everyones voice count.


Decisions about the trajectory of Zcash are not democratic and I doubt that they ever will be. Feedback is taken into account — by ZcashCo (I have observed) and the Zcash Foundation (I know), in our respective decisions — but neither entity is bound to do what the loudest voices want.


Thank you for making this clear, I will point this out next time there is a voting panel and people think the vote counted.

EDIT: Im saying this because there was confusion with members saying the reason we are ASIC now is because the panel voted for it.


See the reply Andrew left in the other thread: Zcash Foundations Voting and Governance Panel


FWIW @Lisfin the governance panel did have effects on Foundation policy. It determined the makeup of two Board seats and set priorities for the Foundation. The Foundation was not beholden to the vote, it was advisory—but it still mattered to us, because community involvement and influence is very much central to our Mission.

We (the Foundation) are not in control of the Zcash Co, nor should we be. They can and should do whatever they think is in their best interest (which no doubt includes factoring in community feedback).

I expect that as Foundation influence grows on the network (particularly with things like the Parity node work we’re funding, and all the wallet work we’ve been funding as well) Foundation influence will more directly affect the trajectory of the network. But I wouldn’t expect the Foundation to be purely a democratic projection of power on the network; there are many decisions that need to be made technocratically, and the main difficulty for the Zcash ecosystem at large is deciding which is which and how to weigh feedback accordingly. It’s also the fundamental governance challenge of any group of people, TBQH, and it’s a tough one.

EDIT: @sonya’s link above to Andrew’s reply is also worth reading and echoes my sentiments


See this is the part that is making me confused.

The Foundation says we can vote, and we have a choice as a community. Ok understood.
Than the foundation turns around and than says “we are not in control of the Zcash Co”. Ok understood.

Well, ZcashCo seems to be the one with the final call, so how does voting for anything the foundation proposes have any effect if ZcashCo just says no even tho you have a mountain of evidence and the votes to support it.

This makes it sound like it has no effect, a mod has come out and said the panel had no effect on the outcome of ASICs. This does not sound like the voting counted. Sure you guys hear us and can see how the community feels. But it seems it doesnt matter, ZcashCo will do what they want anyway.

Im not sure how much influence the foundation has, but from what I have gathered you can only “propose” ideas to ZcashCo? I could be completely wrong on this.

This is disingenuous voting then. People would expect since look 90/100 people voted for this, it will pass. and ZcashCo can just be like nope. Does the votes really count than?

I am very thankful you guys have a voting panel, but from what I understood at the time(incorrectly), it was the “community” voting for it, not just a suggestion.



Here’s another one I’d love to see a Draft-ZIP for for NU3!