Dev fund proposal: fixed 20% with opt in/out measure
Advocate: @Autotunafish (thx @ChileBob : )
A fixed 20% development fee to be allocated primarily although not limited to the Electric Coin Company and the Zcash Foundation, beginning at the next halving and continuing until the following halving or appx 4 years
While this is a fixed portion, the individual miner has the option to participate in the dev fee round or not at their own discretion
The recipients of these funds and percentages will be determined by a voting mechanism (not unlike the one used for the zcash foundation board of directors) to be (re) enacted every 3 months
All recipients of funds will be held to the Zcash Foundationâs requirements for accountability layed out in their stance and will be used to help determine if a recipient and % allocated would be properly suited
The motivation for this proposal is to provide as close to a guaranteed funding model as possible whilst being minimally disruptive to existing Community framework;
_It should be able to be supported by the Zcash Foundation
_It should not force the ECC to alter their business model
_It should not endanger the current 501c3 status of the Zcash foundation
Left for further specification / optimization
_The technicalities determining how this would work on a protocol / software level
_how the 20% of the blocks mined are distributed as the dev fee blocks
_ the technicalities regarding the review and voting processes
Argument:
_A minimally disruptive model saps less resources which would otherwise be allocated for development
_A fixed fee increases the likelihood that this proposal and the entire underlying meaning of continuing a development fee will succeed
_The opt-in opt-out measure is necessary to achieve the points laid out in the motivation, it only affects the hashrate during the dev fee rounds and not the total amount of Zec allocated (this is to satisfy both legal requirements and requirements laid out by the Zcash Foundations stance)
1 Like
The opt-out measures should constitute an energy (electric) savings to more clearly define the difference between what opting in and opting out is
To explain, a fixed development fee would coincide with the opt-in choice to mine Zcash (which its always been) whereas the choice to expend resources performing work in contribution is what is actionable
Iâve been rereading this post and the comments on the other thread and think I finally understand what youâre getting at with this proposal. Itâs tricky in part because this opt-in/opt-out mechanism is a pretty new idea. This comment from aristarchus finally got me on the right track.
I would summarize the idea like this, using an example of 20% dev fund target:
- Even numbered blocks:
3.75 ZEC goes to the miner
2.5 ZEC go to a dev fund
- Odd numbered blocks:
6.25 ZEC go to the miner and thatâs it.
Overall, the issuance is exactly the same and dev fund would be on average 20%, but itâs not evenly distributed block by block. This gives an âopt outâ choice because miners can choose just not to participate in the even numbered blocks. (Instead of mining an even number block, a mining pool could just automatically redirect to a competing equihash coin).
There are a few possibilities for how to handle the difficulty of each block.
Option 1. Same difficulty (expected number of hashes) for each block. If this were the case, then the reward per hash would be much less on the even number blocks. I think the outcome would be massive hashpower fluctuations each block, similar to what was observed with Bitcoin Cash. Basically odd-number blocks would be way more profitable, but even number blocks may be less profitable for all but a very few miners. As a result, odd blocks would arrive very quickly, but even number blocks could take much longer to wait for.
Option 2. Adjust the difficulty between the blocks, so the reward per hash is the same. In this scenario even blocks would have less difficulty so theyâd still arrive faster than odd blocks, but in a predictable proportion. Overall Iâd estimate this to have better stability / less disruption, although now itâs also not clear what the opt in effect is. The reward per hash would then be exactly the same as in any of the other mandatory 20% dev fund proposals.
4 Likes
Iâve been thinking more on the even/odd idea.
The diff algo looks at the last 20 (?) blocks & adjusts per block to keep the target time. The same method could use times of the previous 20 âeven-only-blocksâ to get the difficulty for the next âeven-blockâ & same approach for âodd-blocksâ - should smooth things out.
No clue what would happen in extreme cases or miners âplaying gamesâ, and with faster block times planned could be an issue - needs a better mind than mine to figure that out.
2 Likes
I was hoping the ECC could provide some guidance about that or suggestion along with their assessment
1 Like
Iâm sure they will, looking forward to that part - watching ideas move from âwhatâ to âhowâ is the most interesting part for me.
2 Likes
would seem pretty easy to model, no?
just run a pretend 4 year block generation with different levels of opting out.
You could do it in excel. You could also add what chiliebob suggested and calculate the averages over the last odd/even blocks. (this might work, but it might be different values at different hashrates.)
I have a feeling whilst it seems quick because you do it every other block, you are effectively halving the hashrate for 6 months of the year, one half could 51% the other half pretty easily. donât know if they would or not. (and it depends on how it is implemented)
2 Likes
This was not lost to me, while discussing with chilebob I raised the notion of some randomization of those blocks (something like âsome 20 of 100â perhaps and probably avoiding consecutives) to throw off attack timing, we both agreed further guidance about the optimal way is warranted
2 Likes
was just talking to him via pm. he is certainly active 
I think we can do actual modelling of the ideas via pool side stuff (that is his area tho)
has revived a bit of that community spirit just when I thought it was fading.
nice one.
2 Likes
Yup - hacking my Ycash pool code so itâll do this for Zcash, hereâs the plan :-
- playing âlets pretend its 2020 on testnetâ, the block reward is 6.25 Z (diverting the rest)
- miners connect with a password set to âoddâ, âevenâ or âbothâ
- even blocks have a devfee of 2.5 Z which goes to tmVUFbjmq8VrsMAd3XD89BhdicdVe2AbHBe
- odd blocks have no devfee & the miner gets the whole 6.25 Z
- miners on âoddâ blocks are disconnected while the pool is working on âevenâ blocks & vice versa
- miners with âbothâ dont get disconnected & work on everything
- youâll have to pretend ASICs dont exist, GPUs only as I havenât figured out how to get a z9 to work yet
Should have something working by tomorrow with a bit of luck.
3 Likes
OK folks, think its working.
To mine even blocks set your password to âevenâ, to mine odd set it to âoddâ, to mine every block set it to âbothâ
Connection details are (redacted), port 3333, use a valid testnet âtmâ address as your username.
Youâll need a GPU & the appropriate miner, EWBF v0.3.3b works for me so a good place to start - still struggling to get ASICs working but feel free to give it a try.
The pool will kick your miner off if its working on the wrong type of block unless youâve chosen âbothâ, most miners keep trying to auto-reconnect & itâll be allowed back to work on the following block.
Thinking this through a bit more, the âmulti-algo-coin-hopping-minersâ (ie: miningpoolhub) mostly use a script so when the pool disconnects them they switch to the next coin in their list.
In this scenario that would be a âbad thingâ, theyâd get kicked off ZEC after one block & would stay on the next coin⌠they wouldnât come back, which is a âbad thingâ. This test pool is just an ugly hack to play with an idea so maybe not relevant but its worth considering.
3 Likes
Ill use the taz faucet donation addy and try
tmP5cmDU66W2puHFoqfu8Zqe6M4mpsDk5fS
Claymore shows an error that nonse length cannot be more than 18 bytes, server specified 24
I read into it and see if thereâs a setting can be adjusted here
so far so good⌠Iâm mining âoddâ, youâre mining âevenââŚ
1 Like
Ok, itâs timing out but I assume that will continue until the next block?
1 Like
yup, thats exactly it, the pool isnât letting me work on âevenâ blocks.
(sneaks outside for a smoke)
You may have found the thing that was stopping ASICs from working on this pool.
Anybody got one handy? Nonce length is now correct on the pool.
1 Like
Okay I have to adjust the pool configure because itâs timing out to a failover hang on
Okay itâs looking better now not trying to connect to Nano pool!, itâs also going to retry every 3 seconds instead of 20
1 Like
ticking along nicely here, mine joins when yours leaves - need a few more players:-)
2 Likes
I was doing research and it seems like Claymore has a timeout issue that I donât think you have any control over from there
I would say I would try a different software but itâs the only one I could ever get to work with these old cards!
Iâm going to let it run because itâs finding shares every once in awhile but itâs immediately timing out, disconnecting and retrying after every one
But it appears to be working ( I have a z-9 mini, Iâll try to point it that way this evening, let you know)
1 Like
Thats the way it works
This is a solo mining pool so that single share IS the block solution, check the destination address to see if coins are turning up - they go out in the coinbase transaction so you should have âimmatureâ coins.
When you find a solution the pool starts on the next block, which for you is always going be an âoddâ one so the pool kicks your miner off⌠thats why it times out.
Edit: testnet is up to 141 sols now
1 Like
âŚ