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

Pre-Proposal: Adaptive Proposal Fees

Would you accept this proposal?

  • Yes

    Votes: 5 41.7%
  • No

    Votes: 7 58.3%

  • Total voters
    12

GrandMasterDash

Well-known member
Masternode Owner/Operator
Currently:
  1. Community unable to agree on proposal fee, and
  2. Community agrees the USD value of dash is likely to change and therefore prefers a longer term solution
Solution:

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

gobject vote-many proposal-fee 5

This would also be relatively easy to incorporate into DashCentral et al, and I think it's a very simple procedure for an MNO to carry out.

As with the usual vote-many command option, MNOs would be free to change their vote within the usual constraints.

In the extreme case that a proposal fee is not voted, the fee would be set at 5 dash, in homage to how it all started. (but then again, no one voting on a proposal fee might be symptomatic of a much bigger problem)
 
Last edited:
Currently:
  1. Community unable to agree on proposal fee, and
  2. Community agrees the USD value of dash is likely to change and therefore prefers a longer term solution
Solution:

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

gobject vote-many proposal-fee 5
I agree but I have one objection.

The median average may lead to the followed flawed situation.
imagine 2000 masternodes to vote 1 dash, and another 2000 masternodes to vote 10 dash and a single masternode to vote 1.0001
The median average will give as result 1.0001 dash while a result close to 5 dash seems more rational.

I prefer the mode average, and more specificaly a mode average variation. In general the simple mode average selection process is applied, but If the mode average turns undefined and no result can be extracted by this selection process, you should cut from the votes as much decimals as they are required in order for a mode average selection process to be able to work.
 
Last edited:
The median average may lead to the followed flawed situation.
imagine 2000 masternodes to vote 1 dash, and another 2000 masternodes to vote 10 dash and a single masternode to vote 1.0001
The median average will give as result 1.0001 dash while a result close to 5 dash seems more rational.

I prefer the mode average.

I think a lot of people would be happy if 2000 MNs actually bothered to vote. But anyway, by the time you had 2000 votes, I doubt there would be any real difference between the mode and the median. Besides, you've calculated it wrong: http://www.mathsisfun.com/median.html
 
I agree but I have one objection.

The median average may lead to the followed flawed situation.
imagine 2000 masternodes to vote 1 dash, and another 2000 masternodes to vote 10 dash and a single masternode to vote 1.0001
The median average will give as result 1.0001 dash while a result close to 5 dash seems more rational.

I prefer the mode average, and more specificaly a mode average variation. If the mode average turns undefined and no result can be extracted by this selection process, to cut as much decimals as they are required in order for a mode average selection process to be able to work.

Realistically there is no way such a scenario would occur.. the Masternodes aren't going to vote completely 50/50 split with nothing in between
 
I think a lot of people would be happy if 2000 MNs actually bothered to vote. But anyway, by the time you had 2000 votes, I doubt there would be any real difference between the mode and the median. Besides, you've calculated it wrong: http://www.mathsisfun.com/median.html

No I didnt.
You have 2000 votes that voted 1, you have 2000 votes that voted 10, and you have the medium vote which is 1.0001
I think my calculations are correct.
 
Realistically there is no way such a scenario would occur.. the Masternodes aren't going to vote completely 50/50 split with nothing in between

The more close to 50/50 split they are, the more unfair the median average becomes.
Why choose a potentialy unfair selection process, when you can use my mode average variation which cannot be unfair in any case?
Or , can you show me a case where my mode average variation selection process turns unfair?
 
The more close to 50/50 split they are, the more unfair the median average becomes.
Why choose a potentialy unfair selection process, when you can use my mode average variation which cannot be unfair in any case?
Or , can you show me a case where my mode average variation selection process turns unfair?

Yes, suppose 4000 Masternodes vote between 1 and 2 dash, all with different exact values, and then 5 masternodes vote for 20 dash exactly. The mode would be 20 but it would be more reasonable for the number to be between 1 and 2.

Of course, such a situation would be unlikely, just like yours
 
@demo a better example

400 votes for 0.1 dash
550 votes for 0.5 dash
600 votes for 1 dash
500 votes for 1.5 dash
580 votes for 2 dash
601 votes for 5 dash

5 dash is the mode.
 
No, you've calculated it wrong. In my example 5 is the highest frequency, which belongs to the 20 dash votes. If the votes between 1 and 2 are all distinct values, as I said.

I didnt notice the distinct values. You are right.
In that case a more complicated selection process should be used. Α mode average variation version 2
A mode average should be applied, along with the cut of the decimals and some rounding to the votes in case the mode average gives a total different result that the result the mean average and the median average are giving.
Let me think about it I will come back.
 
Last edited:
I didnt notice the distinct values. You are right.
In that case a more complicated selection process should be used.
A mode average should be applied, along with the cut of the decimals and some rounding to the votes in case the mode average gives a total different result that the result the mean average and the median average are giving.
Let me think about it I will come back.

lol, you do that :-D

Honestly, if the kind of extremes and flukes you're talking about actually happened, I would be happy to settle on the median, no less than flipping a coin on the two contentious numbers. In any case, it's just not going to happen.
 
@demo a better example
400 votes for 0.1 dash
550 votes for 0.5 dash
600 votes for 1 dash
500 votes for 1.5 dash
580 votes for 2 dash
601 votes for 5 dash
5 dash is the mode.

Ok let me explain to you my mode average variation version 2.
  1. First we apply the mode average.
  2. The mode average is 5 dash.
  3. In order to check whether it is fair, we check the mean average.
  4. the mean average is 1.79666.
  5. The two selection processes have big difference, they can converge, so let them converge.
  6. I cut the decimals and do the roundings:

400 votes for 0 dash
550+600=1150 votes for 1 dash
500+580=1080 votes for 2 dash
601 votes for 5 dash.

The mode average is now 1 dash and it is much closer to the mean average.
So the final result is 1.

Instead of cutting all the decimals you may also start the rounding to another decimal. For example do the rounding to the third decimal (the 1.00Χ) then to the second, then to the first. Do some rounds, until the best converge is reached.

Do you understand now my mode average variation version 2?
 
Last edited:
Ok let me explain to you my variation version 2.
The mode average is 5 dash which is obviously unfair.
But the mean average is 1.79666 which seems more fair.

They two selection process have big difference, so let them converge.
I cut the decimal and do the roundings:

400 votes for 0 dash
550+600=1150 votes for 1 dash
500+580=1080 votes for 2 dash
601 votes for 5 dash.

The mode average is now 1 dash, and this is more fair.

Do you understand now my variation version 2?

The way we cut the decimals and do the rounding may be more granural.

Using rounding or cutting decimals to group them together seems arbitrary. Much more intuitive to simply take the median.
RIP this thread
 
Using rounding or cutting decimals to group them together seems arbitrary. Much more intuitive to simply take the median.
RIP this thread

All selection processes are arbitrary. Not only mine.
The median is also arbitrary. And it is not intuitive, I already told you why:

The more close to 50/50 split they are, the more unfair the median average becomes.
Why choose a potentialy unfair selection process, when you can use my mode average variation vesion 2 which cannot be unfair in any case?
 
You have to prove your quotes.
I gave you an example where the median average turns tottaly unfair.
Its your turn, please give me one example where my mode average variation 2 turns unfair.
Can you?

5. The two selection processes have big difference, so let them converge.
How do you tell whether they have a big difference? Define big difference. Is there a cutoff where anything above is a big difference, and anything below is not?

Example:
2000 votes for 0.1 dash
1900 votes for 1 dash
2001 votes for 5 dash

The mode in your average variation 2 is still 5 dash.
 
Back
Top