What if it’s precisely because of the “devtax” that, in 2023, we are nowhere near complete ?!
1 Like
I did not propose any red herring. I dismantled your argument with facts.
I’m posting with my own identity, everyone knows what I do, they have my commits to judge my code and my picture is on my avatar. Even the forum says that I’m associated with ECC. You are treating others as dishonest with no proofs.
If the community clearly framed who is who, we could much more reasonably see the interests and conflicts of interest beneath the surface of our interactions.
I don’t agree. Even if leads to an uneven discussion, I defend your right to remain anonymous, my dear 4-day-old forum user.
7 Likes
OK then, let me play the devils advocate for a minute.
- What Great endeavors are you talking about ?
Well, something is valuable because people buy it.
Very concerning what you just said… Unarticulated efforts is literally a trademark of Zf and Ecc.
Some other people advocate for scraping Zf and ECC slices and let instead individuals apply for grants to ZCG. What about that ? Would you feel confortable opening a grant request and explaining what you’re gonna do for Zcash and providing estimate and timelines ? Please detail your answer.
Zcash used to be a top coin. After devfund, it’s going to the shithole.
Mildly. Barely.
The spam issue took months to get tackled. Come on.
What kind of operations are you talking about ?
Hey, you’re supposed to pat yourselves in the back in a more subtle manner lol. Anyway, your statement is subjective. I’ve seen 2 ECC members work in a github monero ticket while the spam situation was on going and a deadline was missed once again.
What happened to @reldev ? Can we know ?
2 Likes
Your comprehension ability is ridiculous. The link you cited is that contributed the most to the Linux 5.1 version, funny, this is only one of the release version. The success of Linux is due to more previous versions (1.x, 2. x, 3.x, 4.x) created.
Shown by the above data that an open source project with a good operation mode, will attract more excellent development resources. Isn’t this the way for Zcash halo2 (IMO, equivalent to Linux 2.4 version) should take now?
Just like the promise when the Zcash project was launched, the 20% founder reward will only last for four years. Although the 20% tax has been continued for another four years with a different name, it is time to have enough confidence and courage to cancel it.
1 Like
Maybe 4 days old, but have bought, sold, and held ZEC since 2018. To your hilarious point, my anonymity is mine and my pedigree as a Zcasher are not up for you to speculate about. Wearing your doxxed identity is righteous, I do respect that, but i also find it especially disgusting that you would disparage me or anyone else for remaining private.
You posed the original red herring:
Once again, if people on the dev-tax salary are only present for the salary, then there are deep cultural and structural problems in the core Zcash builder ecosystem.
Without a means of understanding who is here voting and positing pro-dev-tax opinions, that are also fully salaried by the dev-tax, as a community it is impossible to know the difference between ideological support for dev-tax, vs contemporary self-interested salary based support.
- Zcash’s Dev Fund it’s the way to ensure people dedicated to securing, developing, maintaining and evolving Zcash devote to it full-time with no conflict of interest issues and without putting the project in a second or third (or N-th) place.
Lol. The project already is in last place.
- Zcash’s Dev Fund it’s the way to ensure: A virtuous economic system can flourish out if it, as it has been proven. Zcash participation since Dev Fund has been growing in a diverse and global form.
Where has this been proven?
Daily operations? Such as the decision to fund and hire more engineers to fix the spam problem? Oh. Right…
It’s essential to acknowledge the valuable contributions made by people like @hanh, who developed YWallet as a side project before receiving any funding. This example demonstrates that passionate community members can still make a significant impact on the project even without being full-time employees.
It’s literally already been happening with the dev fund:
- dYdX
- bluesky
- whatever privacy thing henry is working on
??? Shielded Labs: An Independent, Non-US Organization - #18 by aquietinvestor
I get that this dev fund literally is your lifeline (as long as ECC is your employer), but it’s easy to see through the platitudes.
E: Exaggeration
C: Contradiction
C: Collapse
2 Likes
I have seen this and other comments like it, so i’ve got to clarifying my position and voting also. I voted against the dev-tax because this vote is applied to the exact current situation. In a grand theoretical sense, I do have support for the concept if it were being exercised well - with accountability, transparency, and regular iterative upgrades. I do not find that the current dev-tax situation works because the organizations (two of them - Boostrap and Zcash Foundation) have a great amount of unaccoutable power, and they have not shown the capacity to self-improve. This dev-tax solution has been alive for 4 years on the books, but quite a few years longer in the practical sense. Why do I suggest longer than 4 years? Its because the original “Founders Reward” was a more on the nose way of giving indiscriminate compensation to the essentially the same cohort of “Founders” back then, as became staff at Bootstrap, ECC, and ZF today.
If we could reorient our entire ecosystem to manage self-funding around the ZCG/ ZCAP model, where neither were nationally aligned, I’d be in support. But that is just a pipe dream as we know. The best that the Zcash ecosystem can achieve now is to allow the dev-tax to expire after the November 2024 halving. The Bootstrap and ZF can continue to collect their ZEC and if we begin to transition to Proof of Stake, their material interests will line up with delivery of the upgrade… afterall, subsequent to Proof of Stake, Bootstrap and Zcash Foundation can remain perpetually self-funded by the way of validator rewards.
Things are messy in this debate, I mean nobody personal offense! In an ideal 2023, we would have a ZEC coin valued better and that would make its substantially easier to phase out the dev-tax because the Bootstrap and ZF holdings would amply cover a decade of future work… rather than today, being only comfortable to cover another couple of years. The price of ZEC deeply affects this entire ecosystem’s ability to think, debate, and act rationally 
Best Karma to All to brighter years ahead.
2 Likes
Not to mention that the mobile wallet team and the light wallet working group seem to be underperforming, to say the least. Based on my review of meeting notes and progress reports, it appears that these teams are not making much headway. While it’s important to recognize that progress can be slow and that setbacks are a normal part of any project, it’s also critical to hold ourselves accountable for meeting our goals and delivering results.
If these teams are not meeting expectations, it may be time to reassess their strategies and consider whether changes need to be made to improve their performance.
It’s certainly frustrating when a “Wallet Performance Emergency Mode” is announced,
disrupts the work of everyone and then exited without any clear, quantifiable criteria.
The whole point of an emergency mode is to address a specific issue or problem and take action to resolve it. However, if the criteria for exiting that mode are unclear or vague, it leaves users feeling confused and uncertain about the effectiveness of the response.
Additionally, if all it takes to solve the spam is to increase fees, it raises questions about whether that response is truly addressing the underlying issue.
It’s important for wallet developers and other stakeholders to be transparent about their decision-making processes. This helps build trust and confidence among users and ensures that responses are effective and sustainable in the long term.
Furthermore, it’s important to note that the performance of any system in real-life applications must be verified and tested thoroughly. It’s not enough to simply rely on theoretical models or assumptions about how a system will perform in practice.
We must subject these systems to rigorous testing and evaluation in a variety of real-world scenarios to ensure that they are capable of performing as expected. This hasn’t happened for DagSync and yet the ECC declares the Emergency Mode completed.
I must say, this particular case is just one of several examples of poor strategic decision-making by grant recipients that make me question whether the dev fund is being used appropriately.
Edit: Correction, the EM is not exited yet. It will be at the end of this month.
2 Likes
Just a point of clarification that ECC is still in Emergency Mode.
Well, this is far more dismal than I had initially imagined.
The characteristics exhibited by this wallet are, in fact, precisely what one might anticipate from any functional wallet of its kind.
The performance parameters, however, are quite disconcerting.
It aims to take an entire hour to process merely one month’s worth of data, which, when you consider the true nature of real-life usage, is an egregiously sluggish pace.
I understand that this performance target could potentially be surpassed.
However, one must consider that establishing such a low benchmark is hardly an ambitious objective.
Indeed, it appears that this modest objective is remarkably out of alignment with the considerable efforts and resources that have been devoted to its realization.
3 Likes
This is what I call the unaccountability towards the community.
On the other hand, Hahn, a simple “contractor” saved the day. Easy pick.
Thanks for the feedback. Ultimately our objective is a world class UX with rapid mobile sync times leveraging our SDK, but this was the minimum standard we set for ECC exiting “emergency mode.” I’m encouraged by what I’ve seen from 5.5.0 and ZIP 317 so far, and optimistic about the performance we’ll see with DAG sync. The ECC team has a history of delivering ground-breaking, high quality cryptographic engineering and performance. I wouldn’t expect anything less.
8 Likes
It has come to my attention that there exists a multitude of field reports, detailing the experience of several users with YWallet getting up to speed within a mere hour.
This achievement signifies a leap of an entire order of magnitude in speed over DagSync goal.
However, it appears that the ECC has chosen a different path. Instead of embracing this demonstrably effective technology, they have opted to pursue their own research and development.
Though it is my fervent hope that, in due course, the ECC’s efforts will surpass the capabilities of Warp Sync, nonetheless, I cannot help but wonder the motives behind their reluctance to adopt Warp Sync, when the overarching goal should be the satisfaction of their user community.
This is another example of poor strategic decision-making by grant recipients that make me question whether the dev fund is being used appropriately .
3 Likes
To be clear, the published goal is not the end goal with DAGSync and the other performance-related changes we are working on. Full disclosure - I am an ECC employee. I left the company last year for a few months and returned at the end of the year with a goal to exit emergency mode. We have been on that plan with one exception - the Halbern vulnerability which our engineering teams worked to quickly identify the issue and craft a fix for it. Out of the 200+ impacted chains, we were one of a handful that produced a fix quickly.
When you state “getting up to speed within an hour,” let’s go a step further and define the specific case. I can fire up a wallet app, create a new seed, send funds to it from an exchange and be up in a few minutes. I could even send funds from a full node wallet if I wanted and still be up and running faster than the hour. We set a line in the sand from which to work.
We have been careful to ensure that our SDK and related code is fully compatible and compliant to all relevant Zcash ZIPs and protocol specifications.
If there are specific reports of situations that we can work from, by all means please share them so we all can benefit by ensuring our solution addresses those needs.
6 Likes
First and foremost, as the architect of your creation, the burden falls upon you to address the genuine concerns of your users. Failing to do so will inevitably result in an inefficient allocation of resources and squandered developmental efforts.
Now, it’s self-evident that initiating a new wallet can be accomplished in a matter of mere minutes, if not seconds. After all, there is no pre-existing history to restore.
However, it is crucial to consider the more common scenario in which an individual reaches for their wallet after a brief period of disuse, only to find themselves in a situation where time is of the essence. A delay exceeding 30 seconds would not only be embarrassing but also cause undue stress to others waiting in line.
Presently, DagSync is tailored to facilitate the swift utilization of funds recently acquired. Yet, the majority of users are not merchants who frequently receive payments. Besides, such merchants tend to maintain a perpetual connection to their wallet, rendering synchronization time irrelevant.
Thus, the singular practical scenario where DagSync’s efficiency shines is when someone lends funds and they can be accessed instantaneously. Surely, this is an infrequent occurrence, and alternative solutions to DagSync are adequate albeit less user-friendly.
Consequently, it’s imperative to reassess the utility of DagSync to a broader range of user experiences.
4 Likes
There are some of us who can actually read git. To be totally honest, “our engineering teams” are not entitled to take a credit neither for identifying nor for producing a quick fix. Mentioned vulnerability has been fixed in Bitcoin (our upstream) since August 2021. We “had” to wait Halborn company until February 2023 to evaluate other project’s security (Doge), spot the fix missing and luckily notify us via responsible disclosure channel. “Producing a fix” was nothing more than backporting those (year and a half old) commits from Bitcoin, plus some minor adjustments to cover code divergence (Comparing v5.3.2...v5.3.3 · zcash/zcash · GitHub). Thus, I find your statement highly biased, even manipulative. But yes, we belong to these 200+ Bitcoin forks who aren’t vigilant enough to track what happens upstream. Tech debt pile is big. Btw, have you heard of “Erebus attack” (https://erebus-attack.comp.nus.edu.sg) … Or we wait for experts to hashtag zcash as a possible target?
11 Likes
Yes, we need to move past the trial decryption paradigm. I’ve written about the options we have for doing that privately and proposed a solution that makes instant sync possible at some cost of reduced privacy and adding trust assumptions; hopefully actually focusing protocol changes towards making Zcash usable will be the next priority.
There’s a lot of anger in this whole thread, and I’m betting a lot of it comes from frustration that the dev fund has largely not been spent on improvements that directly and observably make Zcash better for its users.
I feel all of your frustrations; I’ve been saying things like this for years, even objecting to NU5/Orchard in favour of prioritizing messaging use cases and solving performance blockers. I’ll keep repeating these same points until my message is heard.
I think some admission that the dev fund has been used to lay a solid technical foundation, but actual usability (in terms of libraries for devs, availability of different kinds of wallets, performance blockers) has been mostly neglected (except what we’re seeing now from ZCG), would go a long way to assuage the anger in this thread. I don’t think it’s anyone’s fault really, usability is way harder and more all-encompassing problem than most people realize.
8 Likes
In the real world, when people fuck up, there’s something called the pink slip.
Most importantly, how do we prevent damages to happen again ? We can’t let unrestricted funding continue or we are all f****ing morons.
1 Like
In roughly the past 12 calendar months, the Electric Coin Company spent on an average $450,000-550,000 every month on activities characterized as “Growth and Regulatory” and “General Admin”.
These are the past 12 months where the Zcash ecosystem had the majority of its primary use cases broken. Wallets did not sync, user funds were effectively locked, and full node operation became unfeasible (causing the network node distribution to drop down to the neighborhood of 150-170, hardly decentralized if you ask me). The long term damage to Zcash that happened since June 2022 is hard to truly measure.
$6,000,000 total dollars were spent by ECC on non-development activities. Can any of you imagine a grant requestor to ZCG demanded $450,000 a month of funding for what are intangible and occasionally Zcash adjacent-only projects?
Part of phasing out the Dev Fund will involve the instigation of some serious soul searching for the Electric Coin Company. Zcash at 7 years of life remains, relatively speaking, unused compared to many of its 2015-2017 conceived altcoin peers. The value proposition of ZEC has been totally abysmal, which I assert plays in as a huge driver of Zcash’s lack of use. The abysmal performance of ZEC is also what is driving so much dissent in this thread. We’ve really got to ask ourselves, what does “Growth” mean to the Electric Coin Company and what have they been spending all of that money and other resources on?
The Dev Fund organizations have spent too much free money in endeavors that demonstrably have not accrued value to Zcash. There are also plenty of risk assessment and management problems in our rear view mirror (and on the road ahead).
A new concept of protocol self-funding should involve the phasing out of the Dev Fund in some rough approximation to the upgrade to Proof of Stake (hopefully this deliverable is nearing mainnet by late 2024 or early 2025). The ECC and Foundation and ZCG can all continue (post Dev Fund) to support this ecosystem, while generating passive income by way of ZEC staking/ validating rewards on what will be huge sums of ZEC by the time Proof of Stake arrives. (Keep in mind that the dev funding mechanism will certainly remain in place for another 16-17 months into the future. This current debate only ponders what to do after the late 2024 halving).
I’ll be spending time to review the past year or two of Zcash Foundation tax documents and transparency reports and share any notable findings there also (I do not intend this critique of ECC to imply that I’ve got a favorite among these two). In order for Zcash to fulfil its mission as a network for decentralized private money, there cannot be any more reliance on these big two Dev Fund institutions that have done some excellent work, but who have also cost Zcash and the community so much.
7 Likes