I’m worried that the more used coinholder voting becomes, the more incentive there becomes for people holding lots of zec to attempt some sort 51% attack.
The biggest takeaway I have from this is that I strongly agree with Zooko when he said “The big thing that I want out of it currently is diversity of governance. I don’t necessarily think it’s better than ZAC and ZCAP, but it’s at least different, and I’d rather have two different things with different strengths and weaknesses”.
I think a coinholder vote is a fantastic metric, my concerns with it arise when it would be used as the only source of decision-making.
I’m willing to pay attention to your point, but please elaborate as I personally don’t think this is a problem at all. If 51% of the network believes something should happen, that something should certainly happen. If that leads to a fork, then what’s the big deal?
It’s important to understand that it will never be the only source of decision making. Talking of forks, people get scared of those but the reality is that they are a governance mechanism that can essentially bypass any stakeholders decision. Less dramatic but no less effective, developers have a large amount of power into what gets implemented.
I remain a lot more concerned about the centralization of trust around the governance of the dev fund, specifically. People receiving money from it have no place voting for how or even whether, it should continue. It’s obvious, yet, it’s happening today.
But I do share some of your concern. I think we, stakeholders, are winning. The future protocol change (PoS) is going to give us the upper hand and the current vote is highly likely to to give us power we did not have before.
I urge you to do your research on how much trust the project currently relies on, versus how much it really needs. On my side, because of that shared concern, I am starting to look into not just how to get stakeholders to vote, but also how to make sure they have the right, unbias, executive summaries they need to make the highest quality decisions. What I see happening on ZCAP right now doesn’t exactly give me confidence they are going to be that useful going forward for that purpose.
I spend a lot of my time and effort onboarding people into Zcash. I’m pretty good at it, many readers of this post learned about ZEC directly, or indirectly from me. I’m always interested in making that “Zonboarding Role” easier for myself.
I like the idea that as soon as a person goes from having 0-ZEC to having more than 0, they also hold tokens that empower them to vote on the definition of ZEC.
So, I would like to see coin-holder voting that empowers new ZEC holders.. not to “distribute power/wealth”, but to encourage new onboards.
Lotsa’ classic babble about wealth distribution assumes a system that one cannot opt-into.
But Zcash is such a system, a system that can be opted into and out of.
I think Zcash is more attractive if having ZEC immediately grants voting power.
It seems to me that it would be pretty simple to set things up such that this is the case.
There’s a fact about the universe that automatically gives “Elder ZECers” extra influence.. namely.. time is unidirectional.
So, you can’t vote on any issue in the past. Did you have ZEC back when the vote was cast? Yes? Then you had the option to vote, and that vote shifted the course of ZEC.
No need to destroy the fungibility of ZEC to enhance the influence of the past… physics makes the past influential naturally.
Per the benefit of empowering new ZECers to vote.. I think it’s obvious, it incentivizes the spread of mindshare.
I guess I frame it as, If I really want to voice my opinion on something I deeply care about, I will lock up my ZEC for a longer period of time to signal that. So in a way its like a purchase but allows one with less to signal magnitude.
Yep, exactly what I’ve been arguing for, and currently doing!
Currently, transparent addresses are more powerful at achieving that compared to shielded addresses. It’s a very consequential point; we cannot deprecate t-addrs until we can offer all the same features and more with shielded addrs.
And it matters not just for that, but also for delegation. I can prove fellow stakeholders eventually delegating to me that I voted one way. Can shielded voters do the same?
And how do you preserve the time you’ve held the ZEC in your wallet with that method? Or do I need to let people see all my future transactions, like with t-addrs?
The designer of the election decides by choosing the starting and ending blocks that count.
Outside of this, I can imagine a way this can be proved in the protocol using ZKP. A proof that you own coins since date A, and are also valid in the election block interval.
