I understand and appreciate your point of view on this. One angle of looking at it is that the MNOs could enrich themselves with "personal gain" by rejecting good proposals, just as you said. Another angle is that by introducing an incentive to not spend, MNOs are less likely to fully spend a treasury that they may not think of as having a real cost. Both risks exist. To make the best decision, one needs to consider both behaviors are potentially real.
Where did that aspect of the proposals come from, incentivising voting? The more I consider it, the more surprised I am that it's been put forward as it's long been held amongst the community that incentivising voting is extremely difficult (if not impossible). Now it seems almost like it's taken for granted that aspect will be implemented and that's worrying.
Here's a post from the 2015 discussion before governance was implemented, it's pretty much where the serious discussion in the thread begins:
I see where you are coming from, the reason why I don't like this idea is because it provides an incentive to masternode operators to not fund projects, abstain or simply vote no. I feel that would be a weakness of the system, the amount of money we would have to work with as things stand today is not even the budget of a small business. There does not need to be any waste as we could keep a reserve, about having too much funds in the future, well that would only be the result of the success of the initiative, the ecosystem growing, more features, more adoption. In that theoretical situation, we can always make adjustments is a good problem to have. The alternative of being underfunded and people voting no because they have an incentive to keep the rewards would just leave us where we already are. Operators should vote no, because they don't like a proposal, not because they get to keep the money. A system like that would not work in practice, IMHO.
The first point brought up in the thread was distribution percentages, the 45/45/10 we have was pretty much chosen as a ballpark figure that seemed about right. At a later stage Evan suggested dynamic adjustments for those kind of constants, being able to (iirc) adjust things like reward splits, transaction fees, etc. on the fly.
Given the MNOs must have 1,000 Dash collateral, I believe it is unlikely they would starve good projects for a short-term gain. Killing off the projects supporting Dash would clearly jeopardize the value of their collateral. The DCG plan limits the size of the "reward" or "approval penalty" (depending on your point of view) resulting from the approval of a proposal to protect against MNOs becoming stingy to the point that they damage the network's future. We want enough incentives to cause MNOs to think before hitting the "yes" button (especially if the proposal system expands), but not so much that the ecosystem surrounding Dash is killed. Hope that clarifies.
To be clear, there is nothing about this proposed change that would prevent other ideas like the one you raise from being implemented. We do plan to continue having a small share of development devoted to governance improvements. Our governance works fairly well, but it is far from perfect.
I agree with you that some kind of built-in escrow or staging of payments would be a great feature to add. This could potentially be done using P2SH in combination with masternode quorums and a payment release voting mechanism. It would require a major effort in terms of the share of a major release it would require.
We have something like this on our own backlog of potential improvements. I do think this would be relatively highly ranked for work after the current set of improvements we have already slated for the next couple of major releases.
The 50% up front, 50% on completion was only suggested as an example, somewhere here there's at least one long thread on ways to ensure proposals deliver. One of those suggestions was enforceable contracts, early on that wasn't viable but now Dash has a legal standing it's a possible option. Not one I'd favour personally, I'd rather see a simple solution built in code than relying on a multitude of legal systems worldwide but that's still head and shoulders above trying to incentivise voting imo.
I don't believe incentivised voting can work (I'm certain it can't work in the manner suggested) and even if it can it would need very careful testing and at minimum a spork to disable it. If it could be made to work it's potentially a world changing tech, there have been several attempts in the past and none of them are pretty.
EDIT: Things seem to be aiming at a solid figure for total coin emission. So far there's always been some room for variation, it used to vary with hashrate but that's been removed (admittedly it was very confusing) and after this the entire superbock reward would be allocated, total emission would be a fixed figure.
Imo that's giving up a potential major advantage. Should we ever need to adjust total emission we'd be changing a hard and fast figure rather than a ballpark figure with an absolute maximium and I'm pretty much certain we'll need to do just that to be a serious currency.
Printing to infinity has caused major problems, fixed quantity seems like an obvious solution but it isn't, it caused a lot of problems. The ability to print money as needed was a result of those problems, an evolution of money. We know the bad side of that story but we forget the good, that printing at will offered genuine solutions to genuine problems with fixed quantity standards.
If we want to make economic decisions then we need an economic policy as a basis for those decisions. So far no cryptocurrency has that, "there's only 21 million" isn't an economic policy, it's a criteria, something to be built on but if we want to be a serious currency and not just hanging of the coat tails of fiat or a mixed bag of values then we need to plan for it and a fixed quantity may turn out to be a serious hindrance.
