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

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