According to my Twitter poll with a modest 115 votes, the vast majority want the Dev Fund to only fund development. Why is this not being discussed enough here in the forums especially considering the timing with all the dev fund proposals.
3 Likes
Because that would require blowing up the current org structure and when you really dig into it, there’s no way ECC and ZF will let that happen.
I’d say restructure the ZCG to drive things, but the whole Zcash Media debacle that still hasn’t produced any real needle movers kinda shoots that idea down.
5 Likes
Good initiative, but I believe you question is misleading.
When you ask regular Zcash users if DEV FUND should be used for FUND DEVELOPMENT in all caps, you’re more or less forcing the users to vote for what you want.
The alternatives you gave are also misleading. What do you mean by “fund everything”? This is to broad and vague, this wording can really scare regular Zcash users. And ZCG certainly aren’t funding “everything”. I’m an avid reader of the ZCG meeting minutes, and I see a lot of rejected proposals for being out of scope.
Lastly, the word Development has many meanings, it’s not limited for software development.
2 Likes
As a developer who is paid from the dev fund, I have to say that I think that there is an incredible amount of value in both policy outreach and marketing. Policy outreach & legal ensure that I’m able to continue doing my job without risk of arrest, and marketing means that people actually get made aware of my work.
Development isn’t just writing code; there’s a whole bunch of support infrastructure funded by the development slice that makes it possible for programmers to be effective.
This is not to say that the dev fund should continue as it has (and I’m happy to see many proposals being put forward for ways to change it) but I think that “build it and they will come” has been demonstrably insufficient.
13 Likes
Marketing is even more important than policy outreach. Always has been. Not sure why no one at either of the orgs could ever figure this out.
Perhaps the hiring committees should focus on getting people who have actually had prior success in those particular roles, vs. taking flier on someone because it checks a diversity box.
1 Like
In my years of being here, it seems pretty obvious. They don’t feel that it is legal for them to market Zcash because it would most likely violate their 501C status.
4 Likes
By Development, I mean funding protocol development and anything tech related. Funding stuff like research, marketing, and think tanks just seems off to me. Not cypherpunk at all.
This should be left to people outside of ECC, ZF, ZCG because they believe in the cause. Trying to take ownership of everything is too burdensome and not a natural path to increasing adoption. I expect this from a normal startup or Fortune 500 company, not crypto.
All the money that’s been spent, yet we’re at an all time low and we’re barely seeing new Zcash enthusiasts join the community. The market is telling us something.
It’s just my opinion and I personally do see value in funding other stuff like ZECHUB (which costs us peanuts relative to other things), but the market obviously doesn’t.
1 Like
Fair point @nuttycom 
Considering all the funding and efforts that have gone into the two, why do you think the market hasn’t responded accordingly?
2 Likes
Well, think about it this way. In startups, you may think you have a great idea, or that you are approaching a problem with the correct solution, and the market disagrees with you. Startup founders look like geniuses when they happen to be right, and when they happen to be wrong they spend their efforts in places that don’t actually make a difference in terms of adoption, and often they build the wrong thing and fail.
In hindsight it’s really easy to see why something that may have seemed to make sense at the time was wrong. And, very often with each such decision, there are people who at the time who argued for a different approach who are proven right.
I think that ECC seeking an end to the trademark agreement is a step in the right direction here. Having more development orgs and less duplicated effort is another. More decentralization in general means more people looking at what needs to be done and doing it.
A lot of other projects started out with a significant premine, and I think that the Zcash approach to block reward based funding was a more ethical evolution of the premine approach. However, given how the block reward funding was allocated (and given the trademark) it still resulted in a degree of centralization that meant that the community as a whole has not been sufficiently empowered to make necessary changes. This is part of why I think that the fact that ECC has decided not to accept funds directly from the protocol under a new development fund (https://electriccoin.co/blog/eccs-position-on-the-zcash-dev-fund/) is an important step.
I want the Zcash community to be sufficiently empowered that if a problem like the “sandblasting” arises again, nobody is waiting on orgs like ECC or ZF to fix the problem. In that circumstance, Zooko was opposed to changing the fee structure and insisted that ECC focus its efforts on performance improvements; I don’t have insight into why ZF didn’t respond, because the ultimate fix to the fee structure didn’t involve a protocol change. Hahn responded by providing some somewhat-effective workarounds to the problem, but those workarounds were only accessible to YWallet users, and didn’t address the fundamental issue.
The response to the sandblasting is just one example among many, but I see it as emblematic of Zcash’s struggles to this point. Further decentralization will help, I hope, but I also don’t expect it to be a panacea - there will still always be lurking tragedies of the commons that the community will have to avoid falling victim to.
8 Likes
On the ycash side, the fee structure change took a month or two. Technically it is not a protocol change but when 99 % of the nodes run the software the ECC makes, the difference is moot.
Edit: IMO, having a solution that works for 99% of the people (I haven’t received a single complaint from a user, but I give you the 1% anyway) is largely preferable to having 1+ year of blockchain clog forever.
So the “somewhat-effective workaround” is a matter of opinion.
4 Likes
What I mean here is that it would have been possible for anyone to push forward the block-construction changes with zcashd, to make a PR and rally community support around it, or encourage miners to use a fork. I still don’t know why that didn’t happen.
1 Like
Would the impact of sandblasting have been mitigated sooner if ECC had focused on changing the fee structure?
This was discussed during the Sandblasting Retro (minutes, video).
With the benefit of hindsight, I think we were slow to recognise that there was a systemic issue because Zebra wasn’t significantly impacted (although the attack did expose a bug where Zebra was redundantly/repeatedly verifying Orchard proofs). Once the scale of the issue became apparent, ZF did offer to help ECC, and subsequently helped with ZIP 317, and implemented ZIP 317 in Zebra.
For my part, I knew that the risk of denial of service attacks was something the ECC engineers had looked closely at in 2019, and I believed that, in terms of expertise, knowledge of the protocol, etc., the ECC engineers were the best folks to address the issue, and the best thing we could do was to let them take the lead, and offer help and support. That’s what I told the ZF engineers, and (based on Daira’s comments during the Sandblasting Retro) I believe that the collaboration was productive.
Again, with the benefit of hindsight, I wish I had been more proactive (I would say “forceful” but, given all this occurred shortly after a period of strained ECC-ZF relations, that may have been counter-productive!).
I think there’s two factors at play here. The first was identified by @dontpanicburns, who pointed out that (paraphrasing) the Dev Fund has created a “no pay no play mentality” - i.e. anyone who was in a position to make the block-construction changes to zcashd likely did not feel any motivation or responsibility to do so, and instead believed that ECC (as the largest beneficiary of the Dev Fund) should be responsible for fixing such issues. If we had identified suh a person (or team), and asked them why they weren’t working on fixing the issues, I can imagine them responding with “Why do you expect me to do it? Isn’t that what we pay ECC for?”
Certainly, if a similar situation arose with Zebra, I would regard it as our (ZF’s) responsibility to make the fix (at least for as long as we have the resources to do so).
The second factor at play is that fact that ECC possessed – and still possesses – far greater capability to do the things you describe than any other person, team or entity in the Zcash ecosystem. Making changes to zcashd in a competent and timely fashion requires knowledge of the zcashd codebase (which primarily resides with the ECC engineers), the time to do so (which may be difficult to find if one has a day job), and the assistance of at least one other competent developer who can review your code for bugs.
Even if somebody (or a team) had made the changes, they would likely have found it very difficult to persuade miners to adopt their fork because (and this is based on ZF’s experience of trying to persuade miners to adopt Zebra instead of zcashd for block generation) it’s very difficult for anyone who isn’t ECC to gain traction when trying to engage with miners because (a) ECC has traditionally owned all those relationships (so it’s difficult to even know who to contact), and (b) the miners are unlikely to pay any attention to anyone who isn’t ECC.
Imagine some random Zcash community member emailing miners saying “Hey, we’ve forked zcashd to fix the wallet performance issues. Can you please switch to using our fork instead of ECC’s?”. I can’t imagine any miner paying attention to such a request.
Similarly, rallying community support around a fork of zcashd would probably be difficult without the explicit support of ECC.
A prerequisite for that is people being able to do stuff.
At an individual level, when one possesses expertise, experience and knowledge, has the time to devote to a task (because it’s your job, so you can dedicate 8+ hours a day to it), and has the support and assistance of a team of similarly-qualified people, it can be deceptively easy to assume that others possess the same capability. Drawing an owl is easy, right?
I think it’s very easy to underestimate the extent to which ECC has had an effective monopoly on the expertise (e.g. knowledge of the intricacies of the Zcash protocol, expertise relating to ZK proofs, familiarity with the zcashd codebase, and experience of developing zcashd) required to make changes to the Zcash protocol. That, combined that with the fact that ECC has received the lion’s share of the Dev Fund (40% more funding than the next largest beneficiary - i.e. ZF), means that progress on decentralization has been slower than we would all like.
We’ve been developing that some of those capabilities at ZF (albeit with Zebra as the platform, instead of zcashd) but it takes time.
ETA: Expertise relating to ZK proofs is something we have yet to make any meaningful progress on at ZF. I would be remiss in not highlighting the fact that QEDIT’s membership of the Zcash ecosystem is hugely important in terms of reducing our reliance on ECC in that regard.
One way we can speed the process up is by being proactive about sharing knowledge and expertise, which is one of the reasons I’m keen for the ECC and ZF engineers to work together on the zcashd deprecation project (as opposed to in separate silos), so that (a) the ZF engineers can learn more about Zcash wallet functionality, and libraries and crates like librustzcash and zcash_client_blackend, and (b) the ECC engineers can learn more about Zebra.
The more we collaborate, the more we can decentralize.
1 Like
Yes, absolutely. But ECC engineers were specifically forbidden to work on this effort, even in our spare time as personal contributions to the zcash ecosystem.
This experience is exactly why I think that more distributed capability and more distributed responsibility is so vitally important. If we end up in a similar situation after the transition to zebrad, such that ZF could block or fail to prioritize critical changes, then it will be an equally bad situation.
6 Likes
Emphasizing my strong agreement with the idea that Zcash needs distributed/ facilitated SME beyond just the ECC. Not a simple task, but certainly something everyone can be keeping in mind along the way.
Wow. Maybe the devfund should be decentralized away from executives who wield way too much control and influence?
Funny, I think I informally started talking to @NighthawkApps within weeks of the beginning of the sandblast. The initial idea I tossed out is basically the idea for fee changes that were formalized in zip317. In hindsight, was it not an obvious idea?
2 Likes
Here’s another poll.
2 Likes