At 3.125, a miner makes about $62 per block based on the recent price average. After halvening, that drops to $31 assuming the price stays the same. If a proposal to cut miner rewards from 80 down to 50 percent as an example were now to around $20 per block.
I get the idea of over paying for security, but it feels like we could risk underpaying for it and having miners bail on zcash.
The PoS holy grail doesn’t seem to be getting any closer. (And no I don’t think it’s a holy grail - just for illustrating my point)
@cryptomuncher@noamchom like many others i too have low confidence in POS to solve all problems
that’s why i advocated for 1 year grace period of ASIC miners and then moving to GPU/CPU mining then we can move to GPU/CPU Mining with Hybrid POS
and 80% miners with lockbox or 80% miners with ZCG + lockbox for 1 year makes most sense
now 85% miners with lockbox or 85% miners with ZCG + lockbox for 1 year can make sense if we consider price
I HAVE A BETTER CRAZY IDEA
How about 80% miners 5% CPU/GPU mining with either lockbox alone or ZCG + lockbox for 1 year where 1 year ASIC mining GRACE Period will Start
After 1 year Grace Period is over 85% CPU/GPU mining with Lockbox or 80% CPU/GPU mining with Lockbox
At that time Maya DEX Serai DEX will come out so we can remove t-address t-pool and get more price appreciation
zcash becomes orchard 2 orchard coin only == more value for zcash in market
What exactly do these percentages mean? Are they block reward distributions % or dev fund allocation %'s? Because It’s a bit misleading as block reward distribution != dev fund allocation.
These are all stated as percentages of the block subsidy. The diagrams show what proportion of the block subsidy goes to each recipient. It’s pretty illustrative of just how much more the miners are paid than is allocated to development!
The lockbox is the same thing as the dev fund. Hold rewards to ourselves and some high and mighty decides who to give it to.
Why is this the only project that is so intense not to give miners the rewards like in almost every other project?
People will say what is the incentive for people to code on zec then. The same it is in other projects. Money. Coin go up=thriving ecosystem because everyone wants a piece of the pie.
Dev fund or lock box = coin go down. No one gives a shit. And while the devs get money to code a thing that most people think is buggy no one else gives a shit and we are near all time lows.
Much more than just development, its everything the ecosystem does.
Awesome post @dismad
I’d only ask kindly that you run a 2nd, 3rd, 4th set of the numbers with ZEC at $50 and then $100 perhaps even $150.
Thats important because we ought to put into context exactly how much money the block subsidies would produce supposing a very bullish future ahead for ZEC.
At $23 per ZEC, all of the proposals appear to be just allocating peanuts to the direct recipients/ lockbox.
Several million dollars worth might seem like peanuts when funding traditional organizations; but, it could be quite an extraordinary incentive in a decentralized, ~retroactive, grants-only scheme. I bet it could keep a bunch of quality engineers on more-or-less full-time indefinitely…
Certainly correct on an individual level, I used “peanuts” as a comparison to ECC and ZF monthly operating expenses. At $23 per ZEC for another few years, the post-halving income for even the most generous proposals only provides those orgs with a couple months of operating expenses per year.
general question
Under a lockbox/ NDFM solution, what frequency will we anticipate individuals to be making work proposals?
Is there any means of reducing over administration on the 1 by 1 level?
Part of me is becoming skeptical of breaking the organizations down into individuals, because then the process of writing grant proposals gets pushed down each of the R&D engineers, the managers, the marketers, etc
another aside
What is clear consensus?
If a majority of voters support some variation of a lockbox +NDFM mandate proposal, does that mean there is consensus abstractly, but more work to be done about picking the ideal %s and durations?
If voting comes back and its ~evenly distributed among all proposals does that assume no-consensus and cause an end to the Dev Fund?
(This is my personal opinion, not speaking as a ZIP editor or ZF staff.)
It seems to me that a 63% to 61% split between two significantly different proposals is not clear consensus. That’s only 3 votes out of 137.
It’s a narrow win under the counting system used for this specific poll. But the requirement of “community consensus” seems a bit stronger than that.
A runoff poll of the top 3 options seems like a good way to find out if there is clear community consensus. Those 3 proposals reached majority in the same counting step, and they’re within 9% of each other (12 voters).
A runoff between 3 options introduces a significant risk of a spoiler effect if plurality voting is used, and under approval voting it likely won’t produce greater clarity. I think a runoff between the top two options that consistently received majority approval across all the different polls is a better option.
In today’s meeting, the ZIP editors (with additional input from Kris and Marek) discussed the results of the multiple polls regarding ZIPs to be activated in the next halving.
Considering that:
the polls that asked about support for a Non-Direct Funding Model (requiring a Lockbox) showed approval;
both candidates specify the use of a Lockbox as specified (as a modification to ZIP 207) in Draft nuttycom-lockbox-streams: Lockbox Funding Streams, and otherwise only make use of consensus functionality already implemented in zcashd and Zebra as part of ZIP 207;
the only difference between the two candidates is the specific parameters to be used with ZIP 207 / the Lockbox;
we concluded that there is clear consensus on the technical details necessary for NU6, and the zcashd and Zebra teams can start implementing the lockbox modification to ZIP 207 into the nodes. We also determined that there is still time to run runoff polls to decide the final candidate to be adopted if the community wishes to do so. The deadline for the results for such polls would be July 29th so that they can be evaluated in next ZIP meeting on July 30th. At that time, ZIP numbers will be assigned, the parameters of the chosen candidate will be used to prepare the final ZIP, and plugged in the zcashd and Zebra nodes, enabling audits to begin alongside with testnet activation.
