Community Sentiment Polling Results (NU4) and draft ZIP 1014

Thanks Daira!!

Agreed.

3 Likes

How does the ZFND assess the consequences for the whole Zcash project in the case if the ECC stops developing Zcash?

Why is there no variation in the ZF slide?
Why did the ZFND exclude this possibility from the poll?
Why is this particular point not under debate?

1 Like

ECC has clearly stated that they will decline and not accept funding IF the community decides there should be a cap. You can re-read it somewhere even in this topics.

1.) Because the ZF has allready the smallest slice
2.) Because nobody asked in the discussion for a change of the ZF slice.

This might be true as you may have all the information, but the community has not. As an example, for me personally it’s still a miracle how the community is giving funding to the ECC without even knowing who the shareholders and owners of that for-profit company are. But that’s just me of course.

Did the ECC company make profit in the past years? Paid out dividends/bonuses/whatever to the owners/shareholders? You may know these details but we, the community, do not.

The voting results do not inform us why the community endorsed a cap although I doubt it was voted for solely due to price volatility. I can only speculate but I believe it is more focused on encouraging accountability and sustainability. I am certain that the CFO of the ECC is doing their best to manage currency risk as it arises.

In regards to handling volatility, fair point.

Indeed. A similar argument can be made in the opposite direction if I fully supported the cap. Several metrics indicate Zcash is fully valued without considering future inflation, market reflexivity, broader marketing, or any marked increase in adoption. This is speculation however so feel free to disregard it.

It is disappointing to see that the ECC is absolutely unable to operate under a different regime for any period of time. Frankly though, how do you quantify market uncertainty? Volatility, price decreases relative to the broader market, or some other metric?


I assume that the ZF would fill the gap that the ECC leaves behind if it came to that. The current employees seem to enjoy working on Zcash so the best course of action for the community and these individuals would be to transition them over. The structure of how the work gets accomplished would definitely change but I don’t see how this would irreparably harm all parties (excluding specific owners of the ECC).

Edit: Apologies for being so terse in my initial response @daira. I appreciate your comments very much.

3 Likes

As far as I can see we have have currently no evidence for ZFND’s efficiency to carry out the tasks entrusted to it. However there is some evidence for it’s inefficiency.

One of ZFND’s first larger technical projects is Zebra, an important project for many reasons - however it’s a relatively simple task in comparison to the tasks that the ECC is carrying out today.

The following question was posted by rex4539 after the ZFND presented its Engineering Roadmap for 2020 and remained unanswered.

Perhaps I’m alone here but I have to admit that I was kind of disappointed after reading it.

Parity-Zcash client is already syncing the Zcash blockchain and while I do hear the reason to (kind of) start from scratch, I can’t help to think that the Parity client was built for (sort of) nothing. All these months of development and money spent to finally decide it’s not good enough because it carries the Bitcoin baggage?

Based on the fact that the ZFND is aiming to play a major role in future Zcash development and by applying Josh Cincinnati’s personal standards:

I’m asking the ZFND to comment on this.

1 Like

I’m always happy to respond to reasonable critiques of the Foundation’s activities @mika. But before I do, I wanted to add to @boxalex’s response to your first question:

The answer lies earlier in this (admittedly ever-more-difficult to navigate) thread, in my detailed response to @aristarchus:

In other words: this particular point was under debate in the last round of sentiment collection and the community indicated they’d support the Foundation at either 25%, 30%, or 50% of the dev fund. We were happy to use the most supported proposal as a basis which minimizes the amount within that range (particularly if it supports developing more third-party contributions to Zcash).

For more context on what that actually means for the Foundation in ZEC disbursements, @joshs shared a very useful spreadsheet with possible coin allocations which includes the amount the Foundation would receive at 5% of the reward/25% of the dev fund: 5468.75 ZEC per month. Before the dilution agreed to by all FR recipients to bolster the ECC’s funding, the Foundation was expecting close to 260,000 ZEC over 4 years, which is pretty close to this amount per month (260,000/48 = 5416.66 ZEC).

To your question about @anon16456014’s comment, I think @sonya’s response did a great job of summarizing the thinking behind the decision here:

…the best way to look at it is that Parity-Zcash was a proof of concept, and the options were to improve the existing code or to rewrite. ZF’s team decided that rewrite would result in a better product in the end without inflating the timeline too much (since improving Parity-Zcash would have also required lots of eng time).

The engineering roadmap post contains a more detailed rationale.

Would it have been better to start from scratch earlier? Of course. But when working on complex software — I heartily disagree that this is a “relatively simple task” — there are always degrees of ambiguity and unknowable unknowns, and more often than not what you think is the best possible decision is actually a local maxima. I don’t regret engaging in that project with the information I had then, and I don’t regret it now; it provided valuable feedback to our own efforts and gave us a blueprint of a proof of concept Zebra.

Most importantly, I completely agree with @anon16456014’s conclusion in the same comment you referenced:

You might also be interested in our annual State of the Foundation post, which I will be publishing in the coming weeks. Like the previous years’ updates I intend for it to provide a realistic, honest self-assessment of our progress.

9 Likes

25% for its own operations looks very inefficient to me in comparison to let’s say a slice of 35% for the ECC. If we apply the same efficiency standards to ECC’s 35% slice then the ECC would require 25% of the dev fund for it’s own operations which in fact means only 10% (35%-25%=10%) would remain for the actual work.

This doesn’t make it more efficient and is in fact a complete useless contribution to this topic.

To be able to make a reliable statement about ZFND’s efficiency the ZFND has to provide numbers. How much money and how much time did the “Parity-Zcash client” consume? How much money and how much time will the rewrite approximately consume? Why was the ZFND not capable to avoid a rewrite?

This is of particular interest especially because the ZFND is aming to play a major role in future development of Zcash and hasn’t provided any proof of its actual capabilities to develop, maintain, research and so on.

I disagree even more heartily. It is a relatively simple task, the emphasis is on “relatively”. You have already a working implementation and an excellent protocol specification which makes a huge difference. Relatively to the task that the ECC has performed: doing the necessary research, bringing zero knowledge proofs to blockchains, doing all this from scratch and make this all production ready in a very short time. It is surely a relatively simple task in comparison. Like I already said, this is of particular interest since the ZFND is aiming to play a major role in the development of Zcash and hasn’t provided any proof of its actual efficiency and capabilities. Your response clearly indicates there are huge deficits.

(Speaking for myself.)

That’s taking a lot for granted, honestly. In that event we would each have to make our own decisions based on many factors.

8 Likes

(Speaking for myself.)

The shielded parts of Zcash are well-specified (if I say so myself, and with thanks to my coauthors and the other people acknowledged in that spec). The transparent parts are unfortunately not, due to inheriting a snapshot of the woefully underspecified Bitcoin protocol. @acityinohio is basically right about implementation of Zcash being far from a simple task. It made sense, given what ZF knew at the time, to start from an existing implementation of Bitcoin. I think perhaps too much was inferred from Parity-Bitcoin being written in Rust, but that was an understandable mistake.

7 Likes

In my understanding, the situation is somewhat more complicated than leaving or not the current developers in the person of ECC, I understand that at the moment you and many from this forum claim that zcash is so centralized that it will not do without ECC, in my opinion this is the main problem for today (not counting the popularity and acceptance) and even when it is necessary to compromise, all participants defend only their opinion (considering it the best). As for me, you cannot question the project because of finances, no one knows what will happen next, a complete ban is possible. A project without ECC will fail, which means it is not viable in the current version.
There is a financing project, and the fund team, supplement it with engineers and key figures from ECC in the ranks of a non-profit organization — I consider this a way out. This will confirm that the project lives on, and so, maybe tomorrow or the day after tomorrow ECC does not want to work on it and that’s it.
I clarify that under the outlet I am talking about a possible solution and not about my opinion, that without ECC nothing would happen if you do so, so you don’t need to say that everything is lost.
In the current situation, there is too little information from the readers of the forum, I can’t understand why there is still no solution after the negotiations, I understand that each side defends only its opinion, but you can get all the zecs that are laid by ECC, just not by default, which is a bad option ( I read that the option is not acceptable and disagree with him from ECC, but why?)

1 Like

My first post.
In this early stage of zcash development it would be wise for the entire community to vote for and retain (by voting not to cap ECC) the services of Zooko snd the ECC. Why handyCAP? As a community Zooko, Ecc and zfd have presented the comunity with an opertunity to determine the path forward for zcash and change the optics of all outsiders… Ecc in my view has acted in good faith and done a stellar job thus far with development, adoption and talent acquisition. I would never dream of capping someone’s incentive to produce exceptional results. Think what Ecc can turn out the next few years. 50/50 split in zcash no cap. The only cap should forever only apply to total supply 21m. Thank for reading.

3 Likes

Ecc has manage funds well in the past, i see no evidence that would suggest the community need be involved in funds management or cappping at this point. If their (Ecc/zfd) dev funds increase via price gains thats what you call incentive to produce. The portion of dev fund they receive should not be regulated/cap based on how much usd it is worth.

4 Likes

How do you know? There is not enough transparency to make such call …

Do you have evidence to suggest otherwise? My statment is based on the adoption ie markets such as Coinbase/Gemini etc which is no small feat. Are you for cap on funds? Perhaps you would be satisfied with occasional increased transparency reports from Ecc? Maybe you agree with me that allowing for no cap based in usd incentiveises dev to perform in favor of price appreciation to say the least.

1 Like

You are absolutely right, 12 and 13. Mix it together Let’s vote on it and move forward.
Option 13 would be best at this early stage of zcash development. No caps. Simplify.

1 Like

Your call was that the ECC manages funds well in the past and i argued that you/we can’t know it due the lack of transparency:

Here just some examples where i think we have not enough information:

  • ECC is a for profit company, did they make any profit in the past years?
  • Who are the owners and shareholders of the ECC and did they get dividends/profit/bonuses?
  • How much was the compensation for the Simon [Liu] law suit? 1M, 2M, more, less? Paid from the dev fund or who paid it?
  • Do advisors get paid and if yes how much?

We won’t get answers on the above, hence it’s impossible to say if they used funds very well or not in the past.

In short. Adoption is poor, but Coinbase and Gemini are indeed achievements.

Yes, i would, but that’s not going to happen, at least not to the level it should be that all such info (like the above i asked for) will be disclosed, hence why i’am personally for a cap.

It’s maybe worth to mention that to some extent currently it isn’t that much different under the founders reward. Or in other words the ECC has to work with the funds the founders give to the ECC, which was increased (June 2019?) by them when the price droped. Netherless the ECC only receives a small portion of the whole founders reward.

And my main argument for a cap is simply that i personally would prefer a strategic reserve to be in place for long time development. If the price (hopefully) rises it would mean that exceed funds could be used to have a big reserve for developement for a really long time and not just 4 years which in my opinion would add way more value to Zcash than a massive short time development in “only” 4 years.

1 Like

Welcome to the forums @KeepECC :slightly_smiling_face:

The text I quoted is directly from ZIP 1014

ZIP 1014 dosent set a 50/50 split but:

  • 35% for the Electric Coin Company (denoted ECC slice );
  • 25% for the Zcash Foundation, for general use (denoted ZF-GU slice );
  • 40% for additional “Major Grants” for large-scale long-term projects (denoted ZF-MG slice ).

However that is not set in stone, at the moment the Community Advisory Panel is voting on several possible outcomes as Josh mentioned:

The voting is currently ongoing, we will have to wait and see what the outcome is. Polling Community Sentiment on ZIP 1014 - zcash foundation

5 Likes

I guess its too late to add ‘bring back the swag shop’ to ZIP1014 ? :wink:

5 Likes

There is no question that most of us want zcash to be more robust against all kind of attacks by decentralising it. However you don’t make zcash more decentralized by exchanging one controlling entity with another.

To be more precise, I consider an entity to be in control over zcash iff. it’s in control over money, in this particular case iff. it’s in control over the dev fund. (In addition to zcash users ability to decide to run a particular version of zcash-software.)

It’s somewhat difficult to understand, could you please describe it in more detail?