This part of the proposal concerns me. This would mean that the FPF is the sole key-holder for lockbox disbursement. I think that this is excessively centralized; corruption within the FPF could result in the entirety of the lockbox funds being stolen, and at very least this makes those individuals within the FPF who hold keys a target of attacks.
4 Likes
How would you mitigate the risk?
1 Like
I disagree.
3 Likes
That’s an interesting observation. I just assumed that such a model creates incentives to be a developer with some supply of coins for voting. Although obviously there could be whales that could take over. But I don’t see that as a threat in terms of decentralization. If there is a whale who wants to participate in decisions about grant distribution over $500,000, ok, let him. He has somehow acquired these coins, which means he has already made a huge contribution to Zcash and has the right to express an opinion with his full weight in proportion to the total contribution. After all, it is unlikely that his judgment will be aimed at hurting our cause, right? I’m generally in favor of holders having more rights than grantees. That’s what distinguishes this proposal from zBlock. And I may be mistaken in thinking that grantees will have incentives to accumulate coins, but at least the opportunity is there.
2 Likes
If we know anything about past Coin Votes, YES. they’re dominated by one whale with 300,000 coins and who either is Zooko, or is a direct contact of Zooko’s… Is a coin governance really worth it if its actually just a technically convoluted way of getting the opinion of one person???
1000% agree here… because of the Founders rewards and the rolling other forms of Dev Taxes, there is a massive chunk of ZEC supply given to entities that can easily dominate coin voting… and oh by the way, they already have dominated governance in the past few cycles.
lets also not forget how centralized ZEC supply is to ASIC miners. these are big corporate scale operations minting tons of ZEC… there voting is basically just an opinion from another dozen people. Mining by individuals has never really been feasible in this project. Coin distribution just doesnt look fair enough to give coin voting much weight. I love the theory of coin voting but in the practice of it with ZEC theres just too many unique tarnishes.
don’t even get me started on hashrate and the massive over-priced cost of Zcash security
all coins should be able to vote not just shielded coins 
1 Like
Where did you see that? I just gave an example of a twin algorithm that works as if with a slight advance, but without a development fund.
It is necessary to make up your mind on this. Do miners save up money to manage the direction of development, or do they immediately sell to cover the costs? For your information, mining today is economically more expensive than the current price of ZEC. All miners at the current price are operating at a loss.
And btw, if Zooko has 300k coins according to you, he is mega bullish on ZEC don’t you think? Doesn’t he have to be the most interested person in the world for the price to go up? Can’t we just trust him with all the important decisions?
But he doesn’t really have that coins, simply because it was public information about founders rewards. Check the first articles in ECC blog.
2 Likes
This is where I think the zBloc proposal is superior, in that it explicitly distributes keys among a number of different entities. That being said, I think that the zBloc approach should absolutely include a “coinholder veto” mechanism.
There’s an essential question about a balance of power between who is able to advance proposals, who is able to implement proposals, and who is able to vote on proposals. If some large coinholder advances a proposal that they then are able to force through via their coin holdings, that is no guarantee that the proposal ever ends up activated on the network - they might just take the grant and never implement what they proposed!
If payouts are strictly retroactive, then that mitigates this risk; to guarantee that payouts are strictly retroactive, the keys required to make those payouts should not all be held by a single entity.
Another possible mitigation is that there be a cap placed (in consensus) on the rate at which the funds in the lockbox may be disbursed. If only some given percentage of the lockbox can be disbursed per week, for example, and there is an “emergency stop” mechanism by which all disbursements from the lockbox can be halted without a hard-fork (which might still involve coordination with miners to activate), then that reduces the risk to the chain.
5 Likes
@nuttycom got me thinking about the scenarios that could happen if we have a whale that wants to harm Zcash. Here’s such a weird whale, but let’s say he decides to propose an extremely expensive grant and has the ability to vote to approve it. This is an obvious problem.
So we probably need to take the best of this proposal and the best of the previous zBlock proposal.
Let’s say that a proposal above $500k should be voted on by some structure of representatives of all community stakeholders, similar to what was in zBlock, and then the final approval or rejection is decided by a vote of the holders of the proposal.
Same with key distribution. An approved grant proposal should be paid for with a multi-signature zBlock scheme.
1 Like
We wrote it in parallel. Let’s combine them.
2 Likes
What do you think of this proposal?
2 Likes
You could also keep the decision making with the coin holders and just split the keys across trusted orgs for ratification and to release the funds.
3 Likes
What this then amounts to in practice is kind of the reverse: it’s coinholder governance with a potential key-holder veto. I’d be fine with that proposal.
The essential thing is that the implications of the model are spelled out in terms of the capabilities that exist. If a de-facto keyholder veto exists (which it will), then that shouldn’t be left unspecified. If a de-facto centralization / corruption / theft exists, then that should also be made an explicit part of the proposal.
One way to think about this is the same way we do about cryptographic engineering: write down the threats, and then explain why we do or do not think that they’re a problem.
EDIT:
The more I think about it, the more I think that a “coinholder approval, keyholder veto” model makes sense. Coinholders may not have sufficient context/expertise to judge a proposal; a keyholder veto means that requests for changes that are likely to be dangerous can be defended against. At the same time, the fact that coinholders are primarily in charge of approving a proposal aligns incentives better than grantees being able to approve their own disbursements.
Add to that a consensus-level rate-limiting/e-stop feature, and I think you have a pretty robust system.
10 Likes
100% merging the two organizations can eliminate a huge amount of double work & double management & administration…
but if we’re being realistic here we all know that the powers at Bootstrap and the ZF board don’t like each other and certainly dont want their cushy C-level seats to be vacated… Many King’s of Many Small ponds is how we like it around here 
2 Likes
Rough idea/brainstorm
If “X” occurs the FPF will conduct an additional voting process where “Y” organisations will vote on the proposal. The results of the initial coin holder voting will count as “Z” votes. The initial set of voters and weight on voting is “A”. The voters can vote at any time to add or remove a voting right which can be added or removed from an existing vote holder or added to a new one. The threshold approval for grants is “B” votes, the threshold for governance changes (e.g. changing voting powers) is “C”.
Terms and wording would need to be improved of course and we would need to discuss what those variables are. Roughly speaking though it makes sense to me that if a high threshold is set for minimum voters, which without additional knowledge it might already be considered high, and if that threshold isn’t met, which could be caused by many different factors, the organisations can vote. I think the zbloc voting allocations seem fair.
Also the other amazing thing about that would be it highly incentivises coin holders and the community to self organise if they want their voices to be more powerful by meeting that threshold. Maybe this incentive would encourage an existing or a newy formed group assist (either volunteers or funded) in disseminating factual information, encouraging voting, and hosting discussions when beneficial etc etc.
Another consideration is that the threshold might not need to be a static number, it could simply be that the voting power of the coin holders within that voting block is determined by the weight of the coins on an exponential (or S) curve where in practice if a threshold of coin participation is met their voting rights alone pass the threshold of voting to approve a grant. If it’s an “S” curve that might be awesome since it might allow for a weighting that allows coin holder to cast a deciding vote on grants but not a deciding vote on governance changes. Some of those could include incorporating more zbloc things or moving to keys.
@nuttycom I agree with many your concerns but incremental steps might be enough and I think some of the incremental steps proposed by Josh are a net benefit. If we can make a path to voting on when to move to n-keys viable within this voting model that might be beneficial?
1 Like
Yes. If we go towards coin voting, a defense mechanism is required.
1 Like
I disagree. Shielded coins allow people to vote privately. Also then custodial exchanges could vote as well. Yes and I mean exchanges because nobody that sees a balance on an exchange website or app actually owns those funds. The exchange owns them, since they have the keys, they have the coins.
3 Likes
How do you disagree? What does this statement have to do with your answer?
Everyone should simply be allowed to vote. If someone wants to vote transparent, they should do so. If someone needs the benefit of privacy, they should choose shielded. If this is not possible for whatever reason then it is a design flaw but not a justification or reason.
1 Like
That is 100% correct.
2 Likes
We can disagree that’s fine. .
2 Likes
@joshs - I support this proposal. Zcash has significant governance needs without great forms of legitimate governance baked in. There is still so much work to do; indecision and ossification are not viable options. Balanced with the MGC, coin holder voting with appropriate controls appears to be the least bad option. I understand people’s concerns about plutocracy. In this instance, coin holder voting is not the end all be all for the protocol, just for the lockbox funds, which they effectively fund anyway.
Zcash’s other forms of governance are extremely noisy right now - it is very difficult to tell who has skin in the game and who just has a lot of time on their hands. Holders are putting their money where their mouth is and frankly holding a sometimes tough to love asset (at this point I assume it’s because they believe in something bigger than price). It is the single strongest signal of alignment with the project - it should be treated as such in the governance of the protocol.
From the perspective of “Voice or Exit”, holders have not had much of a strong formal voice in governance to date. Besides some signaling polls and creative messages, the only form of communication has been the price of ZEC (let’s call this “Exit”). It’s possible that if we give coin holders a stronger form of “Voice”, they may chose that over “Exit”, which could make it more attractive to hold ZEC. This could improve the money attributes of ZEC while also improving sustainability for the ecosystem and everyone that depends on ZEC funding. It’s probably less the fact that they have a voice and more what they do with it that would lead to this outcome.
10 Likes