• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Decision Proposal: Increase Proposal System Flexibility & Efficiency

All those votes show MNOs awarding themselves a bigger slice of the pie. It's a shame there can't be a miner only channel with the same vote. I'm back to thinking we need some other way of making decisions where reward splits are concerned because MNOs seem far too inclined to award themselves pay raises!

@stan.distortion This isn't about giving us master-nodes a bigger pay day. We're talking about a range of $90-150 per MN per month, if no treasury is allocated, which is not significant.

There are two more important issues:

1) the network stake-holders need to feel more incentive to more carefully deploy the treasury resources
2) the network stake-holders also want to be able to allocate more treasury funding to projects, for times when there are many strong projects

Paying network stake-holders out of the unused treasury provides much more incentive to carefully deploy treasury funds. It is an imperfect incentive structure, but it is significantly better than the existing lack of incentive structure. In rich times we've blown so much Dash on projects that have brought no value to the network; and in tight times we've been unable to fund some projects that would have added value to the network.

Network stake-holders don't actually need the money for anything, except to improve the funding incentives, but it is the best option anyone can think of so far. Network stake-holders are more likely than anyone else (who can easily be paid by block reward) to hodl the funding. It's a way to issue new coins without adding (much) sell pressure onto exchanges, which actually increases the Dash market cap number.

($ calculations used 5000 masternodes and $70 Dash)
 
Last edited:
Some other perspective.

The network currently pays miners approximately $1.6 million per month. These proposals will both reduce that payment to roughly $1.3 million per month.

It's a relatively minor reduction on an amount that is likely still over-paying for mining. We don't yet know how to determine what is the right amount to pay, but we want to eventually hone in on that value.

Traditional miners recognize the reality that their share of the pie will eventually trend to zero. And it needs to remain as uncomplicated as possible for the network to transition in this direction. (The network will always need to pay for security, but sources of security will eventually emerge that don't require selling Dash to exchanges, as is currently the case for traditional miners.)

The DCG proposal will pay miners an extra $60,000 per month, if 80% of the budget is used, and $150,000 per month, if only 50% of the budget is used.

This isn't a huge amount, in the grand scheme of things, but the major problem is that it just creates a more complicated relationship with miners, and for ZERO added benefit.

If $60-150K is necessary for miners to accept new software, then just add that amount to their fixed block reward so it is consistent.

It would be better to not issue the $60-150K at all, than to unpredictably give it to miners some months but not others.

It makes zero sense to me why the DCG proposal is leading, except that @Ryan Taylor set his model up this way, and he has the ear of some of the Dash whales. But his model is short-sighted in this regard.

Please let me know if I'm missing the benefit of paying unused treasury out to miners, that wouldn't be better served by giving it to network stake-holders to hold or just not issuing it at all.

($ calculations used $70 Dash, 2.8847 Dash per block, 16,616 blocks per month, plus 5,325.843 Dash for treasury, 45% and 36% miner share of block reward respectively. Let me know if I made a calculation error. Happy to share my spreadsheet with anyone who wants to see it.)
 
Last edited:
@stan.distortion, assuming the DCG proposal passed and got implemented, 6 months from now do you expect MNOs to vote for more than 10% proposal allocation or less?

Ooh, a prediction. I like these! :) Usually pretty good at them to, "tomorrow it will rain in Ireland and Peter Schiff will still be a dickhead". Bet you half a dollar that one's right ;)

6 months from now... less, somewhere around the 5% mark but that's a total shot in the dark because these changes will cause much more erratic budget allocations, some months we'll be below 5%, others above 15%. It will definitely weed out a lot of weaker proposals and encourage bigger and better proposals but that doesn't comes without a down side. I don't think it will do much to eliminate the kind of proposals that don't deliver, instead it will improve their quality, more effort put into glitzy presentations and business plans because they can get more Dash for it. Also, things like "get a million sub-Saharan Africans using Dash" wont add as much "value" as "get a single hedge fund to take a position in Dash". A million new users is obviously better for adoption but one hedge fund would do 10x more for price, today I'd guess votes on those would be about equal but I'm pretty much certain the latter would push out the former when there's more emphasis on personal gain.

That's short term, sorry to say it but I can't see long term being any better, just the opposite. I'm assuming voting has been in a steady state of decline for the last year or two? (@xkcd?). If so that will continue, more existing MNOs will just vote "no" as their interest declines but that's minor, new MNOs are much more dangerous. How many MNs does Binance have now, about 300? Once they realise they can get a higher percentage by voting "no" to everything they'll demand that vote and that higher percentage will attract more speculators who will also demand a "no" vote.

As soon as that happens it's time to hit the killswitch. It might be tempting to adjust the criteria instead, it will probably need to be any aggregate positive with zero threshold (ie. 400 for, 399 against, pass. 400 for 401 against, fail) but the exchange MNs have been increasing steadily and the higher "earnings" will bring them in faster, the pass criteria will end up deep in the negative but by that stage it's already too late. Hit the killswitch as soon as the first blanket "no" vote comes in from the exchanges and (at a guess) 1/4 of those speculators will take a butthurt dump, probably around 100k Dash selloff. Let it run and it will be much worse, they'll be a lot more butthurt at having their extra "earnings" taken away and have a greater number of nodes, at a guess about a 2/3rds selloff, probably around 400k Dash.


Sorry if that's an extremely gloomy picture but I don't see much silver lining, the MNs on exchanges will almost certainly vote "no" on practically everything and they already account for the 10% threshold. The only positive I see there is speculators hardly ever understand what they're buying, a staking percentage or some internet shill shouting "buy buy buy" is usually about the limit of research so it may take them a few years to figure out they can boost "earnings" by voting against everything. That might give some time, a bit of breathing space but exchanges (and other "easy access" service) share of MNs will continue growing so when the hit comes it will be harder.
 
Ooh, a prediction. I like these!

Wow, that is a lot of rampant speculation right there! Firstly, yes Binance run 270 nodes, coinbase approx 40, apparently none for Kraken and the other exchanges. Also, yes, voting participation has been down, which by your own speculation you admit would increase given the MNO proposal were to go ahead. However, you underestimate the hopium and positivity of the average MNO, I talk to them each day and they are eager to spend money on projects to further advance DASH all the time. I am not of the opinion that MNOs who under the MNO plan would co fund just 1/5100 of the cost of a proposal would vote no on it on that basis. Any good proposal would certainly still get enough votes to get it over the line.

Right now the DAO is the same as the Fed, it creates new money to spend, often waste on random projects, we are trying to making MNOs more responsible with their spending by having them spend a tiny fraction of their income to better the ecosystem, which they surely will if the proposal is compelling enough.
 
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?
 
Wow, that is a lot of rampant speculation right there!
...
Hopefully a little insight too but yes, it's nothing more than speculation from where we are now. Thanks for confirming the voting decline, I had that impression but haven't been following closely enough and I know you're one of (if not "the") top experts on that stuff.

Can you see any error in the main assumption in there, that shareholders in MNs held by exchanges will put short term gains ahead of long term improvements, (ie. the majority will want a "no" vote to everything)? It's a big assumption and it's been a long time since I followed speculation discussion but even at the peak of my confidence in speculator decision making I'd be surprised by any "yes" vote from a majority.

Quality of votes is a whole 'nother thing, that's about voters giving a damn and it's something all voting systems suffer from, when things are going ok they don't see much reason to vote (there's a name for it but I can't remember it at the mo). I could write another few pages of gibberish on it but it wouldn't end up in anything solid, way more speculative than the above. Definitely something for discussion though, if Dash can come up with a solid solution to that problem it would be even bigger than instant tx's and chainlocks!
 
It's very simple...

We need to be able to deploy more than 10% of the block reward in extenuating circumstances and this allows us to do that. Also, we need to do away with the "use it or lose it" treasury so tungfa can stop posting, "Please vote. There is still some unspent treasury this cycle!" in the Discord.

This proposal does not solve ALL our problems and it's not designed to do that.
 
Last edited:
The DCG proposal will pay miners an extra $60,000 per month, if 80% of the budget is used, and $150,000 per month, if only 50% of the budget is used....Please let me know if I'm missing the benefit of paying unused treasury out to miners, that wouldn't be better served by giving it to network stake-holders to hold or just not issuing it at all.

@ghowdy, can you clarify these calculations? Both plans break even with 54% to masternodes and 36% to miners when MNOs allocate 10% to proposals, so I'm not sure what your reference point is when you say "extra".

This isn't a huge amount, in the grand scheme of things, but the major problem is that it just creates a more complicated relationship with miners, and for ZERO added benefit.

Yes. This is a key point.

Ooh, a prediction. I like these! :) Usually pretty good at them to, "tomorrow it will rain in Ireland and Peter Schiff will still be a dickhead". Bet you half a dollar that one's right ;) .... 6 months from now... less, somewhere around the 5% mark but that's a total shot in the dark because these changes will cause much more erratic budget allocations, some months we'll be below 5%, others above 15%.

I actually looked up whether it was raining in Dublin... nope, but it probably is somewhere in Ireland. :)
In all seriousness though, I asked because you linked to the MNO plan (alone) and then stated:

All those [yes] votes show MNOs awarding themselves a bigger slice of the pie. It's a shame there can't be a miner only channel with the same vote. I'm back to thinking we need some other way of making decisions where reward splits are concerned because MNOs seem far too inclined to award themselves pay raises!

First, there's no way to know why MNOs vote one way or the other, so it's a bit of a sketchy claim to begin with.
Second, MNOs voted to "award themselves a bigger slice of the pie" in the last proposal. These proposals deal with something different.
Third, as stated above to @ghowdy, the DCG and MNO plans break even at 54/36/10, so to be consistent you'd have to berate DCG plan voters as well, if not more so, because at >10% proposal allocation MNOs get more under the DCG plan than the MNO plan. Further, this state is more likely under the DCG plan, because it does less to curb spending on wasteful proposals.
Fourth, trying to increase your yield is morally neutral, in and of itself. Both plans (or at least the MNO plan) aim to increase the purchasing power of the Dash MNOs hold.
Finally, the size of the pie is more important than the size of the slice. The MNO plan yields a bigger pie for our real users (Dash holders, not necessarily miners, but also for them as well depending on how you look at it).

I don't think it will do much to eliminate the kind of proposals that don't deliver, instead it will improve their quality, more effort put into glitzy presentations and business plans because they can get more Dash for it.

I foresee a future where MNOs figure out ways to pay on completion of work, rather than upfront. That's a separate subject, but one where I share your sentiments.

Once they [exchanges] realise they can get a higher percentage by voting "no" to everything they'll demand that vote and that higher percentage will attract more speculators who will also demand a "no" vote.... it may take them a few years to figure out they can boost "earnings" by voting against everything. That might give some time, a bit of breathing space but exchanges (and other "easy access" service) share of MNs will continue growing so when the hit comes it will be harder.

This is a valid concern. Here's what I don't think it's likely a problem, though:
First, like you said, it will take exchanges a while to figure this out and implement voting (if they ever do).
Second, I don't think they will actually throw the "NO" vote switch, even when they discover it. Why? Because some users will object to it knowing that it would risk defunding DCG (and other valuable projects), which could drastically lower the value of their holdings. This is too controversial for exchange operators to want to bother with. I think they'll just abstain from voting.

It might be tempting to adjust the criteria instead, it will probably need to be any aggregate positive with zero threshold (ie. 400 for, 399 against, pass. 400 for 401 against, fail) but the exchange MNs have been increasing steadily and the higher "earnings" will bring them in faster

Yes, this is exactly what can be done if we find that we need to. The passing criteria really is a separate matter, and if the only concern is that too many really valuable projects are not getting funded, that's exactly what we should change (the passing criteria), not the source of proposal funding, which should logically come from MNOs alone if not just through pure inflation as it is today.
 
Last edited:
6ea6c5d01caf11ebba90ab1fd22b902c.png
8c7451e01caf11ebba90ab1fd22b902c.png


I meant these votes, in the first MNs chose the option that gave them the biggest share and same in the second, it's 3 sets of 2 questions depending on the first answers and in each case MNs voted for the option that gave them the largest share. "The largest share" probably isn't quite right, MNs can still get less than they do now with some options when the 20% budget is full but in each case they chose to pay themselves the maximum possible.

When there's "free" money on the table (tax dollars for example) folks can't be trusted to decide how much to pay themselves. We'll probably muddle through this one ok but this won't be the last time rewards need to be adjusted and I don't think MNs can be trusted to make those decisions. Something like a way of putting that kind of decision to the wider community might work, maybe a committee that understands the issue and has no vested interest, maybe a randomly selected jury, idk,

Thanks for the responses. On the last point, can you see how ridiculous that would be if it needed to be adjusted to allow negative votes as a "pass"? If it gets to that point maybe something like a handicap, an automatic 200 "yes" votes could patch it up but I hope we'd have reverted back to the current governance configuration long before it reached that stage.
 
I meant these votes, in the first MNs chose the option that gave them the biggest share and same in the second, it's 3 sets of 2 questions depending on the first answers and in each case MNs voted for the option that gave them the largest share. "The largest share" probably isn't quite right, MNs can still get less than they do now with some options when the 20% budget is full but in each case they chose to pay themselves the maximum possible.
That poll is old news at this point. It was included as background, motivation, and as an explanation of why our proposal is called the MNO plan. If you're concerned about MNOs voting themselves a higher allocation you might want to choose the MNO plan. It's only plan where there's actually the possibility to get less allocation than the status quo. If anyone's plan is a pure money grab by MNOs it's DCG's, where MNOs are guaranteed a higher allocation.

When there's "free" money on the table (tax dollars for example) folks can't be trusted to decide how much to pay themselves. We'll probably muddle through this one ok but this won't be the last time rewards need to be adjusted and I don't think MNs can be trusted to make those decisions. Something like a way of putting that kind of decision to the wider community might work, maybe a committee that understands the issue and has no vested interest, maybe a randomly selected jury, idk,
Well, it's not really "free". If MNOs fund POs who just place market sell orders and provide no value, then the price of Dash declines as a result. That's a real cost (it's not free). But that scenario is exactly what the MNO plan is trying to minimize, by making these costs more personal, immediate, and higher.

Thanks for the responses. On the last point, can you see how ridiculous that would be if it needed to be adjusted to allow negative votes as a "pass"? If it gets to that point maybe something like a handicap, an automatic 200 "yes" votes could patch it up but I hope we'd have reverted back to the current governance configuration long before it reached that stage.
Yes, that would be ridiculous. If we got to that point we'd know we took a wrong turn somewhere, and I would not support that.
 
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:
Your DASH BLOCK REWARD CHANGES make sense to me. I think it would be good to propose to the network. The question is, when, and how? The two-plan proposals are already up, and it's not likely either team will want to (or be allowed by the alternate team in good faith) to change the proposal midstream. Your best bet might be to choose which plan you think is most compatible with your proposed changes, from which your proposed changes could be based off of. Personally I think that is the MNO plan. Obviously next cycle you could simply lobby against the option that wins this round in order to keep the status quo for now, and then build off of that, but you'd still want to choose the most compatible proposal now as a fail safe.

After responding to your other pointsI think my reasoning that the MNO plan is best will make sense.

2. There must be a safe buffer of continuous mining security to keep Dash always impervious to 51% attack during any price swings...
...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?
The mining allocation we need for 51% attack resistance is lower than either of our plans aims for; we both offer them something more in order to 'bribe' them into a timely and smooth adoption.
  • The DCG plan bribes them with a variable mining reward (somehow Ryan convinced the ones he talked to that variable, and uncontrollable-by-them rewards is in their interest).
  • The MNO plan bribes them with a fixed (as it's always been) reward that is higher than the DCG plan's minimum.
MNOs (not miners) need to decide which is best, for three reasons:
  1. MNOs have the most at stake, so we are more likely to make a better decision.
  2. It is impossible for us to know which plan miners prefer.
  3. Economic and security concerns affect MNOs more than miners.
Let's talk about fixed vs. variable allocations:

Ask yourself, for any assumed mining allocation serving the purpose of security alone, is there any reason the allocation should vary from month to month based on a completely tangential matter, i.e. proposal funding?

If yes, what is that purpose? If no, why would we offer miners a variable allocation?

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.
I suppose this was specifically directed at DCG, but if I may be so bold as to say, we don't need DCG to tell us that. A starting place might be to estimate what is required to have some healthy safety margin above the rest of X11 hashing combined, which you can get a rough idea of by looking at the coins listed on Coingecko filtered by X11 hashing algorithm. That's not the whole story though. You might want more to protect against some government putting together a bunch of hashrate that's not on market yet, or you might want less if you're comfortable living in a Bitcoin Cash world where you have someone looking down on you with orders or magnitude more hashing on the same algorithm, and you're still fine with that (I'm not, but some are). That's the kind of thing you'd look for, and DCG can help us with that, but it's ultimately up to each MNO to decide what is best.

Either way, if the security needs are not inversely proportional to proposal funding (which they aren't), then there's no reason to design for that. Fixed, proposal-funding-independent allocation is best, regardless of the chosen level (e.g. 36%).

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...
...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.)
First, does +ev mean "positive economic value", or something like that? I understand your reasoning. I don't agree with it, but it's rational. The reason I don't agree with it is because "value" is both subjective and individual, there's no such thing as an objective aggregate value (according to Austrian economics, or as I like to say, economics).

I know. Simplicity is an important concern, but is it a reason for us not to do what is optimal?
Is there a balance between simple and optimal? I'd say optimal encompasses simplicity. Either way, it's best to start simple, and add complexity where it's needed. If we go for the MNO proposal now we won't have to take variable mining rewards back away from miners (as if they'd like it) when we want to further optimize it. It would be relatively straightforward for us to add the incremental changes you described, altering the MNO pay structure if we find it's not working in the MNO plan. It's easier for MNOs to undo a change that affects only them than it is to ask miners to give up something we just gave them, and it would look bad.
 
Going OT, hope that's ok, it's kind of related. Just had a look at the bounties on the Dev Discord, Trello. Hadn't seem that before, really impressed. Has something along those lines been considered? With something like that it looks like governance would be queue maintenance, @Solarminer was suggesting something along those lines in the DGBB thread.

Something I was looking at a while back with a distributed renewables grid, each generating node makes an income, a percentage goes to expansion, another part goes to the land owner and is theirs to spend and the last part also goes to the land owner but can only be spent on their choice of a list of projects. Never got as far as how those projects get on the ist but the spending part was fairly simple with multisig. Different take on making it "their" money to spend, they get to spend it but it's never really theirs versus giving it to them if they choose not to approve spending it.
 
If anyone's plan is a pure money grab by MNOs it's DCG's, where MNOs are guaranteed a higher allocation.
This is not a true statement. Just one example... with 8% approved for proposals the MNO allocation under the "DCG Plan" would be 55.2%. With the same 8% approved for proposals, the MNO allocation under the "MNO Plan" would be 56%. The maximum MNO allocation under the "DCG Plan" is 60%. The maximum allocation under the "MNO Plan" is 64%. MNOs are clearly NOT guaranteed a higher allocation with DCG's plan.
 
This is not a true statement. Just one example... with 8% approved for proposals the MNO allocation under the "DCG Plan" would be 55.2%. With the same 8% approved for proposals, the MNO allocation under the "MNO Plan" would be 56%. The maximum MNO allocation under the "DCG Plan" is 60%. The maximum allocation under the "MNO Plan" is 64%. MNOs are clearly NOT guaranteed a higher allocation with DCG's plan.

Re-read the quote in context, Ryan. It's very clear from the previous sentence that I was comparing the MNO allocations of our respective plans to the status quo (i.e. 45%). The MNO plan yields 44% for MNOs if we allocate 20% to proposals. The lowest that the DCG plan yields is 48%, which is higher than the status quo, so MNOs are guaranteed to be increasing their yield under your plan.
 
Your DASH BLOCK REWARD CHANGES make sense to me. I think it would be good to propose to the network. ... Next cycle you could simply lobby against the option that wins this round in order to keep the status quo for now, and then build off of that, but you'd still want to choose the most compatible proposal now as a fail safe.

Yes, that's what I'll probably do.

If the security needs are not inversely proportional to proposal funding (which they aren't), then there's no reason to design for that.
Ask yourself, for any assumed mining allocation serving the purpose of security alone, is there any reason the allocation should vary from month to month based on a completely tangential matter, i.e. proposal funding?

Yes, but no, not for security alone. Paying 32+% of block reward is more than enough for security alone since we have Chain Locks. The design reasoning for varying miner rewards based on treasury spending is to distribute an overcompensation (a gift) to miners in a larger degree when price is high and we can afford to overpay, but pay them less when the price is low and additional selling pressure would hurt the price the most.

DCG's plan is not the optimal way to structure our block reward, since it is wastefully overpaying miners in times of abundance; but it still is the healthier of the two choices for the network's economics during price swings. DCG's plan dampens both lows and highs more than your plan does. (However, an optimal plan would dampen lows but maximize highs. An optimal plan is the only correct answer.)

Rion, our security is not in the same jeopardy as BCH's blockchain because of Chain Locks. Dash's relevant constraint on how much should be paid to miners is to pay at least enough to guarantee willing miner support without delay.

I need to be given a good estimate of what minimum required amount, fixed or varying, of miner reward will ensure this certainty in order to know what the optimal plan is. We need clarification if we're going to vote on this fundamental change to Dash.

I understand your reasoning. I don't agree with it, but it's rational. The reason I don't agree with it is because "value" is both subjective and individual, there's no such thing as an objective aggregate value.
No, in this case value can be discretely calculated and modeled precisely. We assume people are rational and will decide in the interests of maximizing their value (a function of the present and expected future value of what they own). That's the correct way to predict economic behavior.

It would be relatively straightforward for us to add the incremental changes you described, altering the MNO pay structure if we find it's not working in the MNO plan.
We should not pick a plan that is kinda okay and maybe change it again later. We need to calculate the optimal plan now and implement it permanently.
 
Rion, our security is not in the same jeopardy as BCH's blockchain because of Chain Locks. Dash's relevant constraint on how much should be paid to miners is to pay at least enough to guarantee willing miner support without delay.

I love Chain Locks but it doesn't always work. I'd rather overpay miners and be sure than have random swings every month uncorrelated to hashrate.
 
We should not pick a plan that is kinda okay and maybe change it again later. We need to calculate the optimal plan now and implement it permanently.
Well, I think I've done about as much as I can do to help you make an informed decision. I appreciate that you want to optimize the system.
 
Back
Top