Proposal “Adaptive-Proposal-Fees“ (Closed)Back

Title:Adaptive Proposal Fees
Owner:GrandMasterDash
One-time payment: 5 DASH (155 USD)
Completed payments: no payments occurred yet (1 month remaining)
Payment start/end: 2017-05-20 / 2017-06-19 (added on 2017-05-08)
Final voting deadline: in passed
Votes: 458 Yes / 393 No / 74 Abstain

Proposal description

Introduction

As many of you know, there has been much discussion regarding the current 5 dash proposal fee. Although 1DPF (1 Dash Proposal Fees) was rejected, the debate clearly divided opinion.

The original 5 dash proposal fee was introduced as a mechanism to reduce spam. To date, this has worked relatively successfully. However, the current US dollar price of dash is leading some people to question if the high fee is stifling progress. OTOH, some MNOs believe the high fee acts as a filter; attracting larger and more professional projects.

Personally, although I favour a lower fee, I fully appreciate both sides of this argument. With this in mind, I am proposing what I believe to be a fair and sustainable solution.

Please keep in mind, over time, this proposal would produce some very valuable historic data regarding MNO sentiment and perhaps substantiate (or disprove) any correlation between proposals and their fees.

Note: To help those unfamiliar, this proposal also includes a brief explanation of how median averages work and why it’s well suited for this particular problem.

(This solution is using the median average, not the mean average! See explanation below)

Feasibility


As you know, we can not force core devs to enact this proposal, but your yes votes will send them a clear message. Official dash developer @UdjinM6 has indicated that this proposal looks, on the face of it, technically possible. In the short term this could be implemented as a traditional spork. However, a longer term solution might be to develop a “masternode spork”, which would be useful for many other applications / parameters.

Keep It Simple Stupid


Alternative solutions have been discussed, such as criteria based refunds and USD pegs. However, those discussions further fragmented opinion. By denominating in dash, we show no favour to one fiat currency over another. Each MNO understands the price of dash in their local currency, and they are free to adapt their vote accordingly. By denominating in
dash, we are all on the same page. This is the solution of least resistance.

MNOs are being paid to make decisions and this is a very simple procedure for an MNO to voluntarily carry out each month, with the potential to be even easier through a web interface such as Dash Central et al.

NOTE 1:
As pointed out in the comments below, this solution can be automated such that every time a user starts their core wallet, it sends their preference. No modification needed for this proposal, this is exactly the kind of thing I envision.

NOTE 2:
It has also been suggested that votes for the proposal fee can be set on the MN. This is perfectly acceptable as it does not change the underlying idea of every MN voting and the median being extracted. Equally, it has been suggested that the median could be set on a rolling basis without having it set at the Superblock. Again, this is acceptable because the underlying concept remains of each MN voting and the median extracted. If people still vote no then I expect them to vote no on all future proposals using a "masternode spork".

Solution

Once a month, MNOs can voluntarily submit their preferred proposal fee. At the time of the Superblock, the median average will be used for the new month. A console command would be linked to a spork and look something like this:

gobject vote-many proposal-fee 5

As a voting command, MNOs would be free to change their vote within the usual constraints.

As a safety measure, at least 2% of all masternodes would need to vote, thus ensuring a good pool of diversity (2% of 4400 MNs = 88 MNs). In the extreme case of not meeting this minimum, the fee would continue as the previous month. (no one voting on a proposal fee would be symptomatic of a much bigger problem)

How to calculate the median average


All votes are placed in ascending order. For example, here are 9 votes:

1 1 3 4 5 5 5 9 10

The middle of this set is the median average. In the above example, 5 is the median average. If there is an even set of numbers, the two middle numbers are averaged in the traditional way. That is to say, the two middle numbers are added together and divided by two. In the following example, 4 and 5 are the two middle numbers:

1 1 1 3 4 5 5 5 9 10

The average is therefore (4 + 5) / 2 = 4.5

For an alternative explanation, please see https://www.mathsisfun.com/median.html

The median average is especially good at filtering out extreme values. Let’s say, for example, there are 100 votes with 40 rogue values  (extremely high or low), yet those values would still not reach the middle of the set.

Show full description ...

Discussion: Should we fund this proposal?

Submit comment
 
0 points,7 years ago
Should we really be getting to the end of the month with 85% of the proposals passed, and still $14,000 being burned? Clearly some of us are getting this wrong. We need adaptive fees.
Reply
0 points,7 years ago
got my number wrong - $140,000. The number is not the point. We obviously need adaptive fees.
Reply
-8 points,7 years ago
Whoever is a PIVX masternode, he may vote in the https://forum.pivx.org/t/adaptive-proposalfee/1098

You can check how many votes the PIVX proposal received here:
http://178.254.23.111/~pub/DN/DN_masternode_payments_stats.html
Reply
-6 points,7 years ago
The PIVX proposal received in one day 400 No votes and it became invisible according to the following code.

https://github.com/PIVX-Project/PIVX/blob/master/src/masternode-budget.cpp#L1361

It needs at least 200 votes to become visible again, and it needs 600 votes to pass
Reply
-4 points,7 years ago
Now it needs 200 vote to pass

--vote history--
Proposal 12: Adaptive-ProposalFee Yes: 12 / No: 20
Command: pivx-cli mnbudget vote ed56d683274c95a75a3ab169332d799310305388bf44888adec799058f2fdfa3 yes | no
--/vote history--
Reply
-3 points,7 years ago
--vote history--
Proposal 12: Adaptive-ProposalFee Yes: 35 / No: 28
Command: pivx-cli mnbudget vote ed56d683274c95a75a3ab169332d799310305388bf44888adec799058f2fdfa3 yes | no
--/vote history--
Reply
4 points,7 years ago
Can you please stop posting PIVX stuff this is dashcentral not pivxcentral.
Reply
0 points,7 years ago
Please keep in mind, this is only to make a decision about proposal costs. It will not take any time away from the core team for any current projects. Actual coding can be done at any time based on priorities, so it may not get done until late this year, early next year... or even later. The timing of it will be strictly up to the core team based on their schedule, projects, priorities, etc.
Reply
3 points,7 years ago
173 no. Can someone please tell me why they are voting no. Because I cannot hear a single reason why this would not be a wonderful solution.

Can someone please say: "I voted no, and I did it because..."
Reply
2 points,7 years ago
For all the no votes, is there any reason other than these bad ones, why you voted no?

- Don't want MNs to have to vote every month on a proposal fee (They won't have to, because the votes can persist just like their current multi-month proposal votes don't have to be re-cast)
- It might slow down evolution development (I don't think this is the case, but if it turns out to be a problem then the core team can still prioritize however they see fit because this proposal can not force anybody to do anything)
- Want a stamp of approval from the core team (It would be nice to have some more input about feasibility, but again this is not a mandate)
- Didn't like the 0.1 dash and 1 dash proposals, and think that this will cause the fee to be lowered (Apparently the 0.1 dash / 1 dash votes are a minority anyway, and is it really so scary to trust in the consensus position of stakeholders which is re-calculated every month, and could even turn out to go higher than 5 dash if we needed to?)
- Tired of talking about this subject or they don't like the proposal creator (bad reason to vote against)

Did I miss anything?
Reply
-1 point,7 years ago
The 1 dash proposal fee is not a minority, they are the majority. 800 votes in favor of 1 dash proposal fee, and 732 against.

So the majority wants to reduce the proposal fee, but the current selection process is against the simple majority (50%+1).

This would be legitimate, as long as the current selection process (10% net votes) can be selected if added as a proposal here. Because the 10% net votes selection process has never been voted, it was imposed by the core team.

So I think the next step is to add a proposal asking whether the MNOs like the 10% net votes selection process. If this proposal passes, then this means that the selection process respects itself, and everything is legitimate and rational here. Otherwise if it fails, it will show us that the MNOs are irrational, and in that case better for everyone to go away from this nest of fools.
Reply
1 point,7 years ago
Hi Demo.
Voting system are not consistent. If not every voting would elect a Condorcet winner. After all a voting that does not elect a Condorcet winner means that the majority prefers A to B, B to C, and C to A.
If you have 35% of the people that prefer A to B to C,
30% of the people that prefers B to C to A, and
35% of the people that prefer C to A to B.
Then you have 65% of the people that prefer A to B; You have 65% of the people that prefer B to C, and 65% of the people that prefer C to A. And yet every single voter is completely rational.
See this also for an example of an inconsistency: https://www.patreon.com/posts/weird-result-not-8765193

So no, don't take consistency of result as a requirement for rationality. The reason to use the median is because it selects the Condorcet winner each time. And there exists a Condorcet winner as long as we are dealing with a decision on a 1D space (a line), with a single peak (each person having one preferred value, and their preference going down as you move away). This is a very particular case, and in this case, and only in this case, you can use the median. Which is why this solution is so good.

Pietro
Reply
0 points,7 years ago
I asnwered here
https://www.dash.org/forum/threads/proposal-adaptive-proposal-fees.14803/page-5#post-127132
Reply
1 point,7 years ago
If this is not too difficult to implement, then I'm not sure why anyone would vote no on this one. What would be the drawbacks?
Reply
1 point,7 years ago
i agree, and yet we are voting no. How can we make sense of a no vote on this proposal? Its briulliant.
Reply
0 points,7 years ago
if we only knew who is voting no, it would be easier to understand.
Reply
2 points,7 years ago
This just allows us to adjust the proposal fee easier in the future. Which doesn't seem like a bad thing in any way. I mean looking that the past proposal that wanted to adjust the fee if we did implement an adaptive fee it likely wouldn't change much at all.
Reply
1 point,7 years ago
Voting yes
Reply
2 points,7 years ago
Come on guys. Dash would be a lot safer in the future if this went through.
Reply
3 points,7 years ago
REALLY GOOD PROPOSAL. The media is the Condorcet Winner among all the votes. It means that it is what the majority would want respect to all the other values. Simple to compute, simple to vote, it is not subject to strategic voting. This is really what should be done. I hope once this passes then we use this method to chose other vales as well. But this is a wonderful place to start.
Reply
2 points,7 years ago
This could also be made simpler with people just setting up their vote on automatic, and changing it when they want it. There is no need to vote once per month, every time you want you change your vote and the median is calculated on the fly. The median is actually extremely stable (it is not an average, you cannot change the median by voting crazy numbers up or down) and very little change would happen as a single person changes their vote.
Reply
2 points,7 years ago
Exactly, every time they fire up their core wallet, it could just send their preference. No modification needed for this proposal, this is exactly the kind of thing I envision.
Reply
4 points,7 years ago
Ugh no! This is not a problem! How many times must I say this there's no one saying "I wish I could make a proposal but it's to expensive"

If someone doesn't have a mere $500 to their name and can't provide value for themselves obviously if they are that broke, then how can we expect them to provide value for us?

Simply put don't fix something that isn't broke. This is so repetitive...
Reply
1 point,7 years ago
They don't say that... They just don't make the proposal and move on. There is no way to measure how much opportunity cost we're losing, so the best thing to do is keep proposals at a reasonable rate that's adaptive to change.
Reply
4 points,7 years ago
I think it is likely that there is no one fee amount that would earn a majority vote. We did not pass the 0.1 dash or 1 dash fee, but we didn't have a proposal for 5 dash and I think it is likely that would have also failed, considering how many yes votes the 1 dash proposal got.

I don't think we should vote like this for everything, but this seems like an appropriate usage. Plus, if the median turns out to be *higher* than 5 dash then that would be possible too, if we needed to go higher because of -reasons-. It goes both ways, and allows the consensus masternode position to prevail.
Reply
4 points,7 years ago
very good point. This is based on the basic asymmetry between a proposal and all the other possible proposals. No single proposals wins the majority, because all the others each has a percentage. In this situation keeping 5 feels as unfair as keeping any other number. The median is really the solution because as the Condorcet winner it is the winner of all pairwise comparison. In other words every time you compare two different values (5 dash vs 1 dash, 1 dash vs 0.1, 5 vs 0.1, 0.1 vs 0.2, ...) the Condorcet winner is the number that has the majority respect to all the others. So it is really the ONLY fair thing to do.
Reply
2 points,7 years ago
I have no doubt you would vote for 5 dash and that's okay with me. Someone else might have a different perspective and that too is okay with me. If the majority of people agree with you then the price will remain and nothing is broke.
Reply
-3 points,7 years ago
I agree!
Reply
3 points,7 years ago
I like this solution. Voting once a month is really not a problem, its only a few seconds, and this solution works in the long term. It doesn't matter what happens to the price of dash, we can adapt the fee to the price and the number of proposals to create a balance and adapt it over time. I vote Yes.
Reply
3 points,7 years ago
Yes, I think this is a great solution! Will be very interesting to see where the fee ends up after all masternode voting.
Reply
3 points,7 years ago
Having to vote every single month on an appropriate fee amount seems a bit cumbersome. I rather wait for a longterm solution to present itself.
Reply
2 points,7 years ago
maybe you could set up your masternode to always keep the same vote, and then you could change your vote when you want.
Reply
2 points,7 years ago
Yes. The essential part to this proposal is that every MN votes the proposal fee and the median is extracted. I don't care whether that's in the client or the server, the end result is exactly the same.
Reply
3 points,7 years ago
Voting every month is what MNOs should be doing anyway. In fact, this solution could almost certainly be added to the core wallet so that it's literally just one click. The same holds true for users of Dash Central.

MNOs unwilling to make one click a month should probably not be MNOs. But in any case, this is voluntary.
Reply
0 points,7 years ago
So what happens if we decided on a fee amount and the next day (after the superblock), the Dash price takes a nose dive ? We would be stuck with that specific fee amount for 4 weeks. It could even form a vector of attack for certain pump and dump groups.
Reply
2 points,7 years ago
a better soultion would be that each masternode decides the value they want and can change it anytime. And in any moment the median of all those values is what counts. If you get too many proposal you rise, if too less you lower it. And you can do it anytime. NO ELECTION TIME.
Reply
2 points,7 years ago
Then we would fix it the next month. As it is now, we are already "stuck" with if fee amount, so I'm having a hard time following your point.
Reply
1 point,7 years ago
The price of dash is just one variable. What if the majority of MNOs are conservative and voting 5 dash regardless? What if MNOs voted 2 dash and there was little or no spam? All these possibilities. We can continue without exploring these ideas or we can trust wisdom of the crowd and get some hard data to work with.
Reply
1 point,7 years ago
Can we please not have proposal about proposal price every month ? Let's focus on the bigger thinks at hand first.
This not something we as masternodes should decide on our own. We need the input of the DASH developers but they are working very hard on evolution.

We don't need to force their hands and come up with a hot fix, which is no long term solution. Once done we can have disucision about this with them. Maybe even live disicucision/meeting with the whole dev team, and proper interviewer
Reply
4 points,7 years ago
This is exactly what MNOs should be deciding on, not developers. This is _our_ business for us to maintain in a decentralised way.

MNOs have two basic functions; to keep good uptime / performance on their servers, and to provide votes for finance and governance. It is a little concerning to see that some MNOs consider this frivolous.

This "hot fix" will provide hard data that is simply non-existent right now. In one year you would do a grand total of 12 clicks in your wallet. In return we would have hard data about what MNOs really think and we might be able to deduce what is or is not working. If you don't want to decide such things, just vote 5 dash and be done.
Reply
-1 point,7 years ago
his is exactly what MNOs should be deciding on, not developers. This is _our_ business for us to maintain in a decentralised way.

I totally agree with that, but realistically speaking MNOs have lot less knowgle than the core developers, and that is why I would like their advice first.

For instance the dynamic fee's now used in bitcoin work quit well, that whole not more advanced that the solution your proposing. That the level of quality I would like the masternode voting process to be on.

In fact I would like the masternode voting process to become similiar to how decred voting proces works.

Even Evan talking about giving Masternodes sporking voting power, voting for what size the proposol fee will be, can be including in that coding process.

I would personally like to see a masternode client which keeps track of voting, and has anonymous chat and works allot like dashcentral does now.But such a project cost lots of time to build.

Just to be clear, I do not like hard code fee's for anything including, instant sent, private sent and proposal fee's, and I would like see some sort of dynamic fee mechanism instead.

But simple demanding Dash core to build it in now while they are very busy on building evolution on time has much higher priority. And I don't want Dash it's code to turn into spaghetti
Reply
1 point,7 years ago
The upgrade from 12.0 to 12.1 significantly changed how the governance system works. In particular, it made modifications like this significantly easier to implement. 12.1 is now a much more flexible solution.

Since making this proposal, I have been corrected / reminded on something... Adaptive Proposal Fees are basically an extension of the current voting system. An MNO casts a vote and it persists month-to-month for the duration of funding, and the vote can be changed any time.

We cant make core implement this and, as pointed out, no one is going to de-fund core if they don't do it. This would be a relatively simple upgrade.

As for dynamic fees in bitcoin, we will have to agree to disagree. MNOs have already agreed to raise the blocksize to 2MB if the situation ever arises, as dynamic fees go against the ethos of dash - digital cash - cheap for every day use.

In any case, proposal fees are a business decision, no less than when an MNO makes a decision to fund a project / proposal. This solution would arm us - and biz core - with hard data and allow us as an organisation to understand and decide which fees are the best. How can we gather such data if we blindly stay with a fixed value regardless?
Reply
1 point,7 years ago
This is not a demand for the core team to do it, it's a recommendation and for the purpose of informing them what the MNs want. They can prioritize however they see fit and I doubt many masternodes are going to try to punish them for that. Additionally based on the limited feedback we have gotten it does not appear that a possible short term implementation would be a major deal to code to the point of slowing other things down.
Reply
1 point,7 years ago
If the Core team ever thinks there is a need to change the fee they can always publish a recommendation. Many masternodes would be influenced by this and the median vote would still be working as designed.
Reply
4 points,7 years ago
Don't hold your breath. Dev's have been giving their input on each of these proposals so until they come up with one on their own, this is what we've got. This is the purpose of governance, to think and act for ourselves... We don't need our hands held by anyone, including dev's to make decisions. Like GrandMasterDash has said, we can't force their hand, but this will definitely tell them what direction we are interested in going. This is the fairest that I've seen because input is taken from all masternodes who are interested in voting each month. If you don't want to keep having proposals about price every month, then vote on one. It is obviously an issue, as it keeps coming up.
Reply
1 point,7 years ago
If you don't want to keep having proposals about price every month, then vote on one. It is obviously an issue, as it keeps coming up.

I believe if the first proposol was not 0,1 but 1 dash instead ( would have voted yes intitially, but do to thinking about it allot my mind has changed), it would have already been voted in. But because this is the 3th proposol in a short time.
Reply
1 point,7 years ago
inb4 description
Reply