Thank you Ryan and Rion for explaining the situation and clarifying each of your positions. I'll give you my current thoughts and opinions about what we should do, but I'm completely open-minded to new ideas and I hope we find the solution that's best for the future of Dash.
Our monetary structure needs to be as efficient as possible because this directly affects market pressures in a competitive trading environment, as well as the quality of treasury proposals that get approved. So it's critical that we carefully and permanently reconfigure the block reward allocation structure in the optimal way for Dash to succeed; this is an important moment.
Instead of choosing between the two plans offered, I'd like to suggest finding the truly optimal block reward plan objectively within the constraints we face:
1. We must be certain that miners will willingly switch to it without delay.
2. There must be a safe buffer of continuous mining security to keep Dash always impervious to 51% attack during any price swings.
3. Miner rewards must then be kept at the minimum necessary to guarantee that conditions 1 and 2 are certainly met.
4. Treasury spending must be capped at a range the network determines to be safe and most beneficial. (20% seems to be agreed upon, and I think that's a good limit.)
5. Masternodes must always receive at least a substantial minimum amount of the block reward, so that they are always adequately incentivized to keep running the network and locking up supply.
6. (In my opinion) Additional unspent Treasury funds should be partially paid to masternodes precisely according to a formula such that the cost of approving proposals is set to a calculated portion of the 20% treasury that is proportional to the value of (expected) benefits gained by the network from funding those proposals. (Further explained below, and subject to debate.)
7. (In my opinion) The extra Dash, left over from unspent Treasury funds not paid to masternodes, should not be created. (Subject to debate.)
This is a multivariable math problem, and I think there is a correct optimal solution.
The first thing to do is decide how much we need to pay miners, now that Chain Locks has changed our network's security needs.
Keep in mind, this is all subjective and many questions like "how much mining capacity is safe" cannot be nailed down to a specific number.
We do need to try to nail it down: the minimum amount necessary, not only to be completely safe from attack, but also to be completely confident that miners will definitely update without delay.
A MN-force-miners-to-comply approach would be really messy.
Ok. Clearly we need to offer a large enough miner reward to satisfy mining pools. We need to be certain they will willingly cooperate and update without delay.
Exactly how much block reward will mining pools require in order to agree to cooperate and update without delay? And do their requirements differ depending on whether it's a fixed or fluctuating miner reward? Realize that their rewards are only gradually going to be reduced over the coming years, so they have ample time to prepare by making hardware investment decisions based on profit expectations that are clearly predictable. So the market forces will likely lead to less future competition to mine Dash as a result of lower mining rewards, meaning eventually there's not much overall change in profitability for miners anyway.
Can DCG please try to discuss and analyze this question with whoever in the community has the best sense of what miners' needs or likely requirements are? Can this be predicted confidently? Is there danger of uncertainty? Can we try to quantify this danger, and arrive at a safe reward level (either fixed or fluctuating) that we are confident will succeed without delay? It would be helpful if DCG could please try to provide this information to the network before we make our final vote on this.
After the optimal miner reward (fixed or fluctuating) is decided, the next question to decide is how to structure the marginal cost to a masternode of approving proposals. I argue that it is optimal to align voting incentives exactly in proportion to the ratio of total masternode collateral compared to total supply. That ensures that +ev proposals will most likely pass and -ev proposals fail, in terms of ev to the whole network.
Our proposal aligns incentives better from the individual MNO's perspective, rather than using aggregates.
I disagree. The block reward should be structured to create maximum network-wide value, not just maximum value to masternodes. As DCG's proposal correctly points out, the misaligned incentives in your proposal would theoretically result in some marginally +ev proposals being unfunded because individual masternode interests would cause them to not want to pay a cost that slightly outweighs their smaller fraction of share in the proposal's expected benefit gained by the whole network:
DCG Proposal said:
Requiring each masternode to assume approximately one 5,000th of the proposal cost (since there are ~5,000 masternodes) creates misaligned incentives, considering each masternode receives only about one 10,000th of the benefits.
I think this is a logical optimization problem with a solution that is objectively correct, once properly understood. We should not decide based on personal preference; it should be set exactly to the optimum mathematically. (Of course I'm open to changing my mind, so please prove me wrong.)
I think Ryan has suggested the optimal ratio:
[You could have] the ratio of unspent treasury paid to MNOs vary based on the exact ratio of MN collateral to total supply at the time of the superblock (i.e., the ratio of their benefit), rather than a fixed [3/5ths] ratio.
Yes, that sounds to me like the ideal way to correctly optimize voting cost incentives to best benefit the network. Approved proposals should have a proportional cost from masternodes' reward range by the ratio of MN collateral to total supply. It probably wouldn't be too difficult to code it that way, would it?
I agree with Ryan's concern:
[There are] benefits in being able to say a definitive future supply.
Yes, I think it is a strong benefit in terms of explaining to newcomers and regulators; and particularly if we were to make it exactly 19 million I think that would improve Dash's reputation as being hard money. But right now I personally think having optimal monetary issuance structure is a higher priority. Despite the resulting uncertainty in future supply, in my opinion it is still a more important advantage to Dash if the extra portion of unspent treasury never gets created.
I personally think it's too complex. The market favors simplicity.
It would be incredibly difficult to explain to newcomers.
I know. Simplicity is an important concern, but is it a reason for us not to do what is optimal?
Here is my attempt to explain it simply:
onetime said:
DASH BLOCK REWARD CHANGES
Since Chain Locks fundamentally changed the needs of our network, Dash will gradually transition to a new and permanent block reward payout structure over the next several years:
Mining rewards will be reduced from 45% down to [fixed/fluctuating, i.e. 32%] of the block reward, which still completely guarantees robust security at all times.
Dash's Treasury budget will increase to a maximum 20% of the monthly block reward. Proposals are put to the network each month requesting funding for projects, and the masternode operators vote on which proposals are approved to receive block reward funds from the treasury.
Masternodes are required to keep a significant stake of 1000 Dash locked up, and they must keep their nodes continuously running to provide essential services to the network. For these services, masternodes earn regular rewards in approximately 9-day intervals. The amount of Dash's monthly block reward that goes to masternode payments will depend on how much of the treasury masternode operators choose to spend. After a voting round is complete, Dash's code automatically calculates how much is paid to masternodes. This amount is set to vary within a calculated range, at a ratio equal to masternodes' share of the network's total supply. The amount can range as low as a minimum [48%] if the entire monthly treasury budget is spent, and as high (theoretically) as a maximum amount that is conditional on network factors, likely to be somewhere around [60%], if the month's treasury spending were 0 (which is unlikely).
These changes incentivize voting to be in the best interests of the overall network, and they ensure that miners and masternodes are always compensated for keeping their machines up running the network continuously.
It's complicated to explain, but I think newcomers who care to learn about Dash's reward structure will hopefully understand and accept this.
If simplicity is a major concern, then the 3/5ths ratio seems simpler than a calculated ratio. Do people prefer that?