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.
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
No comments so far?
Be the first to start the discussion! |
You can check how many votes the PIVX proposal received here:
http://178.254.23.111/~pub/DN/DN_masternode_payments_stats.html
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
--vote history--
Proposal 12: Adaptive-ProposalFee Yes: 12 / No: 20
Command: pivx-cli mnbudget vote ed56d683274c95a75a3ab169332d799310305388bf44888adec799058f2fdfa3 yes | no
--/vote history--
Proposal 12: Adaptive-ProposalFee Yes: 35 / No: 28
Command: pivx-cli mnbudget vote ed56d683274c95a75a3ab169332d799310305388bf44888adec799058f2fdfa3 yes | no
--/vote history--
Can someone please say: "I voted no, and I did it because..."
- 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?
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.
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
https://www.dash.org/forum/threads/proposal-adaptive-proposal-fees.14803/page-5#post-127132
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...
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.
MNOs unwilling to make one click a month should probably not be MNOs. But in any case, this is voluntary.
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
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.
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
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?
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.