I added another edit with mandates for the ECC. I am targeting general requirements and not specific legal structures. Let me know if you guys think there is something important I should add/edit. .
I get your idea and i was thinking about nearly the same mechanism for voting but abandoned it because i think it’s causing more trouble than it helps. In generally the problems i see are:
It’s resulting in something like “Pay for vote”
On a POS design these might work as they get interest for it, on a POW design i doubt it’s going to work.
In my opinion it would lead to less voting while the target should be more voting.
Who takes responsibility if something happens with the wallet meanwhile, like the Komodo case where funds had to be moved in the shortest possible time out of the agama wallets for example? In my opinion “frozen” funds would be at higher risks.
It could be missused by groups/people that hold large stakes, hold them for longer and could that way outvote and go all-in for their agenda.
what if several votes have to be made within 1 year, let’s say for easyness every 3 months is a vote.
If the voter has frozen his funds allready at first vote for 12 months on the second vote 3 months later there are 2 possibilities only:
- his vote now is only “worth” 9 months, decresing further with each vote.
- he can’t vote because he allredy voted in the first one and has no ZEC to lock again.
could this open doors for a strategy to buy large amounts of ZEC just for voting to gain more influence temporary and than selling these to avoid financial risk?
It would exclude maybe several other groups that could have interest in voting due their affilation but don’t hold ZEC or only smaller amounts.
The absolute pro argument is of course: The more you put in (freeze/lock) the more you show skin and the more voting power you should have which is a valid argument in my opinion. But there is a big chance that the negatives outweight this valid argumentation at the end. Just some thoughts and dangers i see.
This assumes that only founders, investors are shareholders of the ECC, but the truth is we don’t know who is a share holder in the ECC. I didn’t get an answer to this as well and the foundation itself has as well know idea who is a shareholder in the ECC. What if some employees are as well share holders, just as an example? It’s just logical to assume that Zooko is a shareholder too. How does your proposal adress such possible scenario?
Someone could argue if a for-profit status is the better option than a non-profit status for such task. As an european i’am absolutly sure that in europe a non-profit status has way more weight than a for-profit status, is way more thrustworthy and often choosen by the governments themself to get advice, discussion, whatever. I have no idea how it’s in the US, but i see no reason why it should be much different. A for-profit always leave the taste of “they are doing it for profit”, legitime but not as thrustworthy as a non-profit.
As said, just some thoughts …
I think one solution would be to make the maximum lock time equal to/ or less than the time between elections, so that zec is never locked during an election.
I definitely wouldn’t want to discourage voting from people who are long term zec holders and care about development funding. I’m open to idea to improve the game theory here.
Regarding the for-profit/non-profit status, I don’t know which is best but I do know that I don’t want the ECC to be held back from any gov’t relations work. There are some restrictions on what type of things some U.S. non-profits can do in regard talking to regulators that do not apply to for-profits. There are also potential tax issues that apply to non-profits, where a non-profit could be vulnerable to the IRS. There issues are complicated and nuanced and I’m probably oversimplifying and not I’m definitely not a legal expert. Thats why I think we should just put what outcomes we want in our proposals and let a legal expert figure out the best solution to get that outcome.
Regarding my comment on shareholders, basically I just don’t want money from the dev fund to go to passive ECC stakeholders who are no longer involved in the Zcash community and have already been rewarded. Their exact identifies shouldn’t matter I think? I do however want to allow people working on Zcash at the ECC to be able to benefit from the potential upside of Zcash being very successful. I’m open to suggestions on rewording my mandates if these things were no clear.
no, i didn’t yet …
hey @aristarchus do you think your proposal is better and/or more fair then others suggested?
would you consider withdrawling your proposal?
If I didn’t think my proposal was good I wouldn’t be advocating for it.
Why don’t you give me some specific criticisms rather than ask me to withdraw it? That would be more constructive.
@johnwisdom First of all I believe that anyone should be able to make a proposal. You are trying to attack people making proposals and that is an attack on this whole process.
Not that is any of your business, but I have been following Zcash since I first read about in Wired in 2016 (months before it launched!). I have owned zec for years and I even run a node. Not everyone who follows and invests in Zcash is active on this forum.
I understand you are concerned about your investment, but I and many others also have invested in zec, and I simply disagree with you about the best way to make zcash better with a dev fund. You and others (mostly miners) are advocating to limit dev fund spending so that miners will receive more zec. I believe that this is short sighted and I am trying to maximize the value of zec over a multiyear timescale while miners often need to make a ROI in a matter of months.
I am truly trying to make zcash better, and it is fine to disagree with my ideas. It’s not ok to say that some ideas are illegitimate because of who you think is proposing them. I’m going to continue to advocate for whatever I think is best for zcash and I’m not going to be bullied into silence.
To answer your question, I do like my proposal the best so far, but I am open to suggestions from anyone to make it better. There are aspects of the Dev Fund Proposal: 20% to a 2-of-3 multisig with community-involved governance proposal that I and several others have already expressed concern about, but I am open to it if they can address the concerns raised.
I have absolutely zero affiliation with the ECC or the Foundation. I’ve never even met zooko. Not going to respond to any more attacks on my motivations for trying to make a good proposal.
I’ve written a lot already about why I believe having a substantial dev fund is good for zec. I do want a large dev fund because there is a lot of things that software engineers can build to make zec better. There is not a fixed set of things to achieve for zec, it can always be made much better with more engineering work.
The onus is on miners to explain why we need to decrease the dev fund substantially just to pay a little more for security.
You could read what I wrote above in my proposal too:
- 20% is a large enough percentage that there should be enough dev funding for many different Zec price scenarios. To those who want to decrease this percentage: Overpaying for security is a gift to miners, to the detriment of every other stakeholder in the Zcash community. I will even make the strong statement that intentionally overpaying the miners for security is stealing from the other stakeholders.
Just my personal opinion, but that’s one thing i absolutly agree with. Nobody should be bullied or silenced or forced to withdraw a proposal, no matter how abstract, unlogical ot whatever it might look in the personal view of the reader.
Daniel, i again can only say that i understand absolutly where you are coming from, what your intentions are and that i agree with a lot of the logic behind it. I really like you, believe me, but personal attacks are not doing any good here.
And again a reminder that any proposal has it’s place, even if a Monero guy is suggesting that 20% of the dev fee should go to the Monero Foundation, lol.
The important part is that a fair vote by the community is done and i think most of us should focus on this part as this is the important part where decisions are made, proposals are choosen or not.
If the decision making part is corrupted or flawed it doesn’t matter at all what kind of proposals we all make or how they are argumented.
I hope you take this as a friend-to-friend advice made with best intention and not as a personal attack!
I do and I know of my wrong doing. I won’t be posting anymore in this thread, if @moderators feel it’s better to erase my comments so be it.
That’s not my intention to keep you from asking questions or questioning a proposal, but it should not contain personal attacks. I know it’s a hard line and i myself cross it from time to time or walk borderline. There is enough room to ask a question why it should be $1.1M and not $700k for example, or whatever questions but no author of any proposal should be feeling bullied, forced, attacked or whatever. Maybe i’am very sensible as being myself part of such attacks. I just don’t want to see you get a warning, flagged posts or such.
@johnwisdom Personal attacks against the contributor of a ZIP are out of line.
Everyone is free to discuss the merits of a ZIP, the details are important.
However, personal attacks against the person’s motivation, character, and accusations of somehow colluding with ECC or Foundation with zero evidence is not acceptable.
@daira and I made an initial review pass over this PreZIP. This is not a formal part of the proposal process (in particular, @daira is not acting in hir role as ZIP editor); this is just a joint comment between @daira and myself on the current state of the PreZIP.
Overall this looks reasonable, but needs to be formatted as a ZIP draft. See the ZIP guide for details.
This is ambiguous as to the split. It should specify whether this is an even split, or what the intended percentages are.
It is ambiguous what this means for the consensus rules after the second halving, i.e. the default case if no subsequent NU changed the issuance rules. The above two sentences could be interpreted as:
- No dev fund allocation in consensus rules from the second halving, and a requirement by this ZIP to implement a dev fund with a voting mechanism in a subsequent NU.
- 20% dev fund allocation in consensus rules from the second halving (i.e. leaving in place the system in this ZIP), and a requirement by this ZIP to implement a voting mechanism in a subsequent NU to allocate the funds.
This should become / go in the Rationale section.
These would be good subsections of the Specification.
The phrase “even indirectly” makes this too strong; in particular, some employees and contractors are also founders or shareholders of the ECC, and this wording would prevent them from being paid for their work. We don’t think this is the intent of the requirement, so it needs to be reworded.
First of all really good work going through all proposals and make comments. Good job!
While so far all comments on all the proposals you comment are are clearly understandable i have some problems with this one:
- If an employee is as well a founder or shareholder he gets his wage as an employee, not? I think the proposal is clear that wages are ok, but not additional rewards to founders/shareholders or does he just have to add “additional rewards beside the wage” to make it confirm?
There is some context provided at the top which suggests this (hence why we didn’t think the intent of the requirement was to prevent the proper compensation of employees and contractors for their work). However, the wording of the requirement itself (which would be part of the actual specification) does not make that distinction, and that combined with the “even indirectly” is what causes the problem. The requirement could be amended in several ways to address this, such as folding the context into the specification itself.
In theory it shouldn’t matter what the ‘default’ case is, since the intention to have the dev fund after the second halving be voted on by coin holders. It seems the issue is what should the code say happens if somehow a dev fund voting system is not implemented by the second halving? In that case, which I would consider to be a violation of the mandate, I would not want either the ECC, the foundation, or the miners to have any incentive to say ‘let’s just go with the default since a voting system isn’t ready.’ So how about the setting the default case, in the event that the voting system isn’t implemented, to be to burn the 20% of funds intended to go to the ‘voting dev fund’.
How about this?
The revenue received from the Dev Fund should not be used to give further rewards to, even indirectly, the investors, founders, or shareholders of the ECC, who are not working on Zcash after the second halving.
Adding this to the specification would resolve this issue, and also make it much clearer that this proposal has a strong requirement for a funding system after the second halving.
The proposal starts from the first halving, so the addition would need to be “after the first halving.” Otherwise yes, this would address the raised issue.
Just out of curiousity, how do you define if someone works on Zcash or not?
For example is an advisor working on Zcash?
Is a founder being an advisor at the foundation working on Zcash?
Is a foundation member working on Zcash working on Zcash due your definition?
Is a shareholder not automaticly working on Zash just for being a shareholder of a company that works on Zcash?
Or how do you define work? Is someone doing a quick review on a Zcash issue for example working on it no matter it may take only 10 minutes a month? And so on.
By the way, just questions out of curiousity as it seems everything must be defined absolute exactly.
Good point. I’ll have to be a little more clear.
Shareholders are definitely not working on zcash just by owning shares.
It’s on GitHub now! https://github.com/zcash/zips/pull/276