Dev fund proposal: fixed 20%, opt in/out measure, minimal disrupt

Community Collaborations protocol
1

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
2

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

3

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
4

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
5

I was hoping the ECC could provide some guidance about that or suggestion along with their assessment

1 Like
6

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
7

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
8

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
9

was just talking to him via pm. he is certainly active :slight_smile: 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
10

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
11

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
12

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

15

so far so good… I’m mining ‘odd’, you’re mining ‘even’…

1 Like
16

Ok, it’s timing out but I assume that will continue until the next block?

1 Like
17

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
18

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
19

ticking along nicely here, mine joins when yours leaves - need a few more players:-)

2 Likes
20

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
21

……:popcorn:…

2 Likes
22

Thats the way it works :slight_smile:

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