What's new

Archived Pre-Proposal:”Adaptive-ProposalFee“


May '17

This is a fork from http://www.dash.org/forum/threads/proposal-adaptive-proposal-fees.14803/ 6
As many of you know, there has been discussion regarding the current 50 PIV proposal fee.
The original 50 PIV proposal fee was introduced as a mechanism to reduce spam. To date, this has worked relatively successfully. However, the current US dollar price of PIV 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 may suit for this particular problem. Alternatively some other selection processes in order to extract the average can be decided.
As you know, we can not force core devs to enact this proposal, but your yes votes will send them a clear message. 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 PIV, we show no favour to one fiat currency over another. Each MNO understands the price of PIV in their local currency, and they are free to adapt their vote accordingly. By denominating in PIV, 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.
NOTE 1: This solution can be automated such that every time a user starts their core wallet, it sends their preference.
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”.
Once a month or on a rolling basis, MNOs can voluntarily submit their preferred proposal fee. At the time of the Superblock (or on a rolling basis), the median average will be used for the new month. A console command would be linked to a spork and look something like this:
pivx-cli mnbudget vote-many proposal-fee 50
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. In the extreme case of not meeting this minimum (and in case there is not a rolling base implementation, as long as with a rolling base implementation we will certainly reach more than 2% after a period of time) then 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:
10 10 30 40 50 50 50 90 100
The middle of this set is the median average. In the above example, 50 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, 40 and 50 are the two middle numbers:
10 10 10 30 40 50 50 50 90 100
The average is therefore (40 + 50) / 2 = 45
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.
Alternative selection process: the mean average, the mode average e.t.c.
The median average is not a prerequisite.
The MNOs should be able to switch among several prefered selection processes if they desire, and vote on a rolling basis with a yes/no their prefered selection process. The winner selection process will be the one having more yes, and the one which respects itself (means that it can be selected if we apply this very selection process to the yes/no votes)