Community Sentiment Polling Results (NU4) and draft ZIP 1014

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. https://www.zfnd.org/blog/zip-1014-poll/

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?

Do you really prefer to have state of the art mobile wallets in 10years and and not in 1?
Do you realize the consequences?

It is a naive idea - your cap will always be wrong - either to high or to low.
It is a much better idea to introduce a strategic reserve with particular access rules.
A strategic reserve is actually what you want, right?
And that’s what in fact most organizations are doing, nobody uses a cap for this purpose.

2 Likes

Please don’t put words into my mouth.

4 Likes

What is the name, if not centralization of a given project, when the cessation of support by one team leads to tragedy?

2 Likes

Some ECC employees will go to the fund and continue working on the project, after that there will be a developer and everything will go further, you have touched on the subject of wallets, so this topic works against you, as long as we waited for wallets with secure transfers, 3.5 years, and for ios we are still waiting Since you think ECC is the best for the project, I think that several people from ECC are the best for the project, and it would be better if they worked outside the current company, because the company can pursue its goals, which no one is aware of. The project is more important than one commercial company, but everyone says the opposite, that without ECC everything will fail. Without belittling their merits (and they are huge), I say that if this is so then it is already bad, and it is advisable to consider everything.

Your questions are valid and should be acknowledged/addressed. Whether ECC dicloses said information is not reason enough to cap (in usd/Fiat ) a company we hire to work on Zcash. That said the percentage of zcash (block reward) they receive is a sufficient cap. Ecc should be allowed to benefit from price increases.

Adoption going very in my view relative to zcash age. Remember ~50%of zcash existence has been in a bear market. Two of the Biggest on-ramps have added zcash. Not so with its competitors.

Block reward cap is sufficient. Simple! See below…

This is an excellent point. This proposal 1014 should be revised to, or add increased transparency. Block distribution of 50% ECC/ 20% zfd/ 20%grants/

And 10% strategic reserve this ensures funds will be available for zcash development well into the futute. This satisfies your/others concerns with regard to fiat capps while ensuring funding is Always available for development.

Fyi typing grom a phone. Good chat.

1 Like

I’m aware, 50 /50 was my original view…

Although now a 10%allocation for a strategic reserve seems to be a better path forward for sustained zcash funding well into the future.