A new mix adjoins be added
Take 5% from mg and zf to allocate for strategic reserve of 10%. Ecc 50/mg 20/zf 20/ sr 10.
A new mix adjoins be added
Take 5% from mg and zf to allocate for strategic reserve of 10%. Ecc 50/mg 20/zf 20/ sr 10.
Maybe I’ve made my position not clear enough.
I think in order to make zcash more robust against all kind of attacks the power i.e. the dev fund should be split between multiple parties.
I think it also makes zcash more robust if the dev fund is equally split between 3 parties in comparison to a split between 2 parties.
I thinks it’s very alarming if there is a single party which tries to control the majority or even 100% of the dev fund.
To make my point even clearer I’m asking the ZFND the following question:
Does the ZFND make strategic decisions and/or actions to gain (more)control over zcash?
The answer should be yes, otherwise the ZFND loses its credibility, since there is already enough evidence - one of them are ZFND’s actions during the trademark debate.
Given this the ZFND must be treated equally to any other entity which is trying to gain control over zcash to prevent abuse of power.
Further, given the above reasoning we should critically ask the ZFND if the current cap debate is used strategically to gain more, potentially 100%, control over the dev fund - especially because there are alternatives to a cap which avoid the questionable properties of it.
Regarding your point about wallets: I cap prevents you from reinvesting which is very bad idea. If you are mainly interested in a reserve for bad times than agree to allocate a particular percentage of the dev fund for a strategic reserve with particular access rules. This is a much better approach compared to an absolute cap mainly because it’s relative and not absolute. It ensures you have your reserve and doesn’t prevent you from reinvesting.
Everything you said about the control applies to the ECC as well, and the trademark debate showed this, because they unilaterally rejected the previous agreements, remember?
As for the 3 sides, I totally agree! Understand correctly, I am not opposed to working without a limit in dollars, I am even against this restriction, but I am also against the position of the ECC, which, after voting, states that it will not work on this proposal, while it does not try to come to an agreement and just goes to pressure ( without us everything will be bad), where is the solution to this issue? Either we or no one is a solution, because I believe that they will not find funding even at 700 thousand a month, simply no one will invest such money.
(As ZIP Editor.)
The vote on existing options has already started. This proposal doesn’t have enough detail to vote on: who would manage the 10% SR?, how would it be allocated between ECC and ZF?, etc.
(Speaking for myself.)
Suppose for example that you think that authority over the SR should be apportioned equally between ECC and ZF. That’s (approximately) already implementable within the current ZIP 1014 and the options we’re voting on; just add 5% to ECC’s slice and let them manage that as an SR. ZF can also do this with 5% from the 25% they’re allocated. The slices need to be uncapped for this to work (otherwise, ECC would refuse their slice).
Safe keeping/custodian would be zfd. Although their is flexibly as to how via perhaps your 10%split between both ecc and zfd since as you state above can be done on this proposal. Specific wording to indicate those allocations are guaranteed for this(SR) purpose only could be acceptable in my view. It would be great to have additional input/ideas from the community as to which would be best. And how to use the funds long term. Idealy community would control the fund 10% via voting… Or combination of zfd/community voting.
Agreed all allocation for ecc should be uncapped. This (SR) may satisfy those who favor capping due to concern over potential money mismanagement or the longevity of this project due to perpetual 20% dev fund. The Strategic Reserve would also serve as an attractive feature for new comers who see value in a self funding project among other things. Open to input.
Credit this idea to Boxalex.
(Speaking for myself.)
The practical effect of this would be similar to keeping back some of the dev fund allocated to the Major Grants slice, which ZIP 1014 allows if the ZF and/or Community Panel (depending on the outcome of one of the questions in the poll) choose to do that:
Dev Fund ZEC that has been received, not placed in the Volatility Reserve, and has not yet been used or disbursed, SHALL be kept by the corresponding party (as ZEC, or sold and invested) for later use under the terms of the corresponding slice.
(The “not placed in the Volatility Reserve” part would be removed in the case of no funding caps.)
Then ECC could apply to use the kept-back funds in a subsequent Major Grant.
So I don’t see that there’s any justification for changing what we’re currently voting on, even if voting hadn’t already started.
Happy cake day!
[edited to add: in response to Community Sentiment Polling Results (NU4) and draft ZIP 1014]
(Hey, friends! Happy Martin Luther King, Jr. day. This is the day that Americans celebrate an American who practiced effective, non-violent, protest and organization. https://en.wikipedia.org/wiki/Martin_Luther_King_Jr. Coincidentally, I’ve been writing a post about permissionless petitioning, and today is the day I finished it and am ready to post it, so I added this note at the top before posting. :-))
I believe that permissionless, unstoppable Coin Holders Petitioning is strategically important for the long-term success of Zcash. I’m gonna briefly lay out my reasons here just so I have something I can link people to if they ask me why I encourage coin holders to do this.
First of all, there are reasons why people shouldn’t. I’m not going to go into all the details here because it would turn this comment into a book chapter. You can read this thread to find lots of discussion about the risks and negatives of Coin Holders Petitions. They are real—I’m not discounting them, but my arguments here are at a different level. I have four arguments. These are from the least important to the most important argument, so if you’re in a hurry skip to Point 4.
The risks and tradeoffs are not that bad. Everything in life is risky and comes with tradeoffs. There’s never gonna be a perfect anything, including there’s never gonna be a perfect on-chain voting mechanism. But, what we have in Zcash already works, and it is a beautiful thing. We used it last time around, and it was a success.
The best way to learn and to improve something is to do it over and over. We could spend years debating the risks and designing improvements, but our “Perfectionism and Worry (PAW)” emotions will never be assuaged no matter how much we do that. We learn more in one month of trying something imperfect and risky than we would learn in years of debate and design. We’ve already learned a great deal from the first Coin Holders Petition. And you learn more from doing a thing twice in a row than from doing it once.
It’s permissionless and unstoppable. Using the current Zcash blockchain, Coin Holders can voice their opinions, backed by their ZEC, in an anonymous and unspoofable way. We can’t silence them. We should pay attention to what they are saying.
Coin Holders, large and small, are treasured parts of the Zcash community. They aren’t the be-all and end-all of the community, but neither is anyone else. They are dedicated, valued allies supporting our mission. They’re important for our future. It’s possible that some of them can’t or won’t participate in the other community sentiment gathering methods, such as the Community Governance Panel, for many reasons, perhaps because they didn’t sign up before the cutoff, or because doing so could compromise their privacy. We should encourage Coin Holders of all sizes to know that their voice matters.
Okay, those are my arguments. Reason number 4 is my overriding reason which I think it is an important long-term strategic advantage to Zcash for us to keep pushing it forward.
In a subsequent post I’m going to make a few simple, actionable recommendations.
[Edited to add: instructions for participating]
@zooko, this thread is already overloaded and overlong; can we please conduct the renewed discussion of coin-weighted voted in a separate thread (whether a new one, or continuing one of the dedicated existing ones)?
Also (and pertinently to this thread): we have a tight schedule. The Helios vote will close on Jan 27th
28th, and hopefully things will then move very quickly towards implementation. So a new coin-weighted signal, introduced this late in the game, will either have inadequate time to crystallize, communicate and execute (presumably it would require people to pull funds out of their cold wallets and suchlike), and/or it may delay the overall process.
In my previous comment I told you why I care so much about Coin-Holders Petition that I think we should keep pushing it forward despite the risks.
Here are three simple, actionable, observations:
If you’re considering participating in a Coin Holders Petition, and you’re concerned about the risk of your coins being lost to accident or theft, then just use a fraction (like 1%) of your coins in your petition. That still shows that you exist and raises your voice while leaving the vast majority of your coins as safe as before. Of course, it also means your vote only weighs 1/100 as much as if you voted all your coins. Your call.
If you’re worried about the risk of your privacy being compromised by participating in a Coin Holders petition, I would say this. At the risk of oversimplifying, it’s all about where you store your ZEC long-term. If you’re currently storing your ZEC in a t-address, and you use your ZEC, or part of it, in the petition, then on-chain data will allow blockchain-observers to link your vote to the t-address of your stash. And moving your ZEC through a z-address will not help. You have to store your ZEC in a z-address if you want on-chain privacy. But the good news is that if you’re currently storing your ZEC in a z-address, then you can participate in a coin-holders petition with basically no real loss of on-chain privacy. There are probably valid exceptions or arguments to that, but basically if you store your ZEC in your z-address, then it’s pretty damn private.
See how I said “on-chain” whenever I said “privacy”, in Point 2, above? Point 2 is all about on-chain privacy, but that’s not the only kind of privacy that might matter to you. One particular off-chain data leakage that you should be aware of is the network layer. Even if you’re using z-addresses, someone who is watching the network layer will be able to see the IP address and the timing of when you make transactions. That means that even if you’re using z-addresses, they’ll probably be able to link your vote in the Coin Holders Petition with other transactions you make from the same IP address, including shielded and partially shielded transactions, even if they can’t learn anything about which z-addresses are involved in shielded or partially-shielded transactions. Whether this is a problem for you in practice really depends on your situation. Participating in the Coin Holders Petition probably doesn’t, for most people, make this problem substantially worse than it already is. If you’re a real privacy ninja, you could mitigate this risk by using Tor in a particular way.
Only vote with as many of your coins as you’re willing to risk moving.
If you store your coins long-term in a t-address, then blockchain observers may be able to link your vote with your long-term holdings and your other transactions. Blockchain-only observers won’t be able to do so if you store your coins in a z-address long-term. Moving your coins through a z-address does not change this. What changes this is whether you store your coins in a z-address.
Think about the fact that a network observer can link your IP address with other transactions you make from the same IP address. The consequences of this are confusing to think about, but if you have concerns about your privacy even though you are using a z-address for long-term storage, then you need to think through this network-level privacy leakage.
I can move it to the original topic: Staked Poll on Zcash Dev Fund Debate
(With moderator hat.) A few comments on this topic are fine, IMHO; if it turns into an extended discussion then it should be moved.
Okay, head over to the Stake-Weighted Poll thread for instructions on how to petition using your coins.
This is a valid concern. This is the sort of reason why I wrote why this is overwhelmingly important to me despite the drawbacks, so that you could know what my reason is (mainly just “Reason 4”), whether or not you agree with it.
Yes, we do. But critically the Foundation is not seeking unilateral power over Zcash. As I wrote in the conclusion to last year’s State of the Foundation:
Looking beyond the Foundation, I think it’s critical to reflect on where power — and expertise — sits in the Zcash ecosystem today. As I’ve said above, the central issue that faces our community today is centralization of power in the Company. But it’s a necessary centralization… for now. The Company employs many of the world’s top experts in zero-knowledge systems, and their contributions are critical to the development of the protocol.
If the Company were to disappear today, that would be a tragedy for the ecosystem. It would set us back by years if not decades. And that’s a fundamental problem for a protocol that’s meant to be robust as currency, that’s meant to protect privacy and adapt to the unforeseen privacy challenges of tomorrow. For the Foundation — and the ecosystem at large — it’s imperative that we encourage Company contributions to Zcash while paradoxically (and amicably) reducing their burden as stewards of the protocol.
Or as I wrote in June in Zcash Governance: A Step Toward Decentralization:
In my report on the Foundation’s 2018 progress and 2019 plans, I explained why and how the Zcash Foundation must counterbalance the Electric Coin Company’s power over the Zcash ecosystem. My concern is not that the Electric Coin Company does subvert Zcash to serve its own interests; my concern is that the ECC would be able to do so.
Unilateral power in either the ZF or the ECC would be a terrible outcome, and I for one think the project would suffer greatly if either group managed to exert undue influence on Zcash in the long term.
[takes Foundation hat off, puts personal Zcash community member hat on]
The ECC has made it clear that they would not accept funding if it included a cap. After a lot of thought and consideration, I’m personally voting against the cap because I very much want them to continue to be involved in this project.
Honestly though, this was a hard decision for me to make; it doesn’t change my opinion that the ECC’s official explanation leaves much to be desired. (the personal, unofficial ones on the other hand — that the ECC prefers having flexibility to spend more than the cap without having to go through a potentially onerous ZF, ECC, CAP process to up their limit — make much more sense to me)
When presented with a choice between Zcash with the ECC’s involvement with or without the ECC…well, I still think it would be a tragedy if the ECC walked away from the project, even if they do so for reasons that are still not rigorously explained officially.
[puts Foundation hat back on]
Regardless of my personal opinion, the Foundation will honor the results from our final Helios poll:
29 posts were merged into an existing topic: Staked Poll on Zcash Dev Fund Debate
Indeed, I was for capping the ECC and leaving the MG slice uncapped, and have since mostly come around to an uncapped ECC slice.
As a potential MG recipient who will ultimately be making a bet on the future of the coin, it better aligns interests and gives me a chance for asymmetric upside. I need that to choose something like Zcash dev as an MG recipient over other ecosystem opportunities.
I mean I’m really interested now! I think making any sort of coin vote mech recognized by the ZF for sentiment collection this time around would be dangerous (for the above reasons)… that said, the last petition not “appearing to matter” is why I didn’t take the time to vote myself.
Anyway, weighing in further in the other thread to not pollute this one too much.
This is the proposal I believe would be most beneficial to the longevity of the project.
ECC 50 /SR 25 /ZF 25 MG would fall under SR.
There are community members who are for the cap. Knowing that funds are being allocated specifically for long term development/adoption etc would help change minds to favor uncapped proposals.The community having a fund slice under their control (at a min 3/4 majority control via voting) would all so help with external optics as this would decentralize control of the project while preparing for the day when(if) ecc/zfd decide to part ways. ECC and ZFD would continue their work so long as the community sees fit. MG slice would fall under Strategic Reserve and should be majority controlled by the community (not any other party ecc or zfd) for the specific purpose of community approved Projects/Major Grants/external marketing etc. No burns coin burn.
Wording plays an important role in external optics. Major Grant in my view should be changed to Strategic Reserve (Major Grants would then fall under SR) and majority control should be the community and custody (only) by the zfd until a better method comes to light. These funds to remain locked and shall only move with community approval.
Clearly i do not have all the answer however these ideas i believe have merit and should be strongly consider by the community. Always open to ideas.
Keep up the good work Daira.
At first look a cap seems a responsible thing to have, but it causes other problems. Voted against it.
Excellent choice, how are things shaping up so far. Where is the majority sentiment at this point?