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

Pre-Proposal for Tiered Dash Proposal Fee

Would you accept this proposal?

  • Yes

    Votes: 1 25.0%
  • No

    Votes: 3 75.0%

  • Total voters
    4

GrandMasterDash

Well-known member
Masternode Owner/Operator
As many of you know, there has been much discussion regarding the current 5 dash proposal fee. In fact, at this time of writing, there is an active proposal to reduce the proposal fee to 1 dash (approximately US$75). This debate has 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.

Clearly, none of us can be sure what impact a change in proposal fee will bring. However, if the 1 dash proposal passes, I am willing to at least give it a try. If, however, it becomes clear the 1 dash proposal is not working, I would consider making the following proposal ASAP.

I suggest the initial proposal fee is set to 1 dash for the first 10 proposals. Subsequent blocks of 10 proposals would multiply the price by 1.5x. Thus, the following schedule would apply:

Proposals 01 - 10 = 1.0 dash
Proposals 11 - 20 = 1.5 dash
Proposals 21 - 30 = 2.25 dash
Proposals 31 - 40 = 3.375 dash
Proposals 41 - 50 = 5.625 dash
Proposals 51 - 60 = 8.4375 dash
...and so on

As you can see, proposals 41 - 50 would approximate the current price. More importantly, the fee becomes significantly more expensive, thus keeping to the original intention of preventing spam.

Obviously, this would need the blessing of core. I'm not entirely sure about difficulty of implementation, except to say, it doesn't look terribly difficult, and I don't anticipate a fork.
 
Last edited:
Hold the phone...

This type of proposal, could change everything we currently know about the # of Dash available for future proposals...

should-the-core-team-start-saving-for-massive-market-campaign.14387 (@TanteStefana)

If I have the choice to fund the Core Team and Dash Foundation for Evolution (Evo) development and marketing or meetups in xxx country... I'm going with every dollar to the Core and Foundation... If the Core Team and Dash Foundation don't ask for all the Dash available, I will fund the grassroots proposals like the ones we see now... Evo needs to be the focus... Which is why, I have stopped voting for now... We have no proposals from the Core or Foundation yet.

----------------------
Currently :
Total Current Allocated Budget: 494.00 DASH ($37,548.94).
Total Available Budget: 6,651.85 DASH ($505,607.11).

----------------------

This isn't to take away from the excellent grassroots movement we see today, it's just saying all funds on deck for Evo. I feel, it wouldn't be un-reasonable to have a 2% marketcap budget for the Evo marketing launch alone... That's about 10.3M USD... We should start saving asap! The grassroots projects will come after the Evo launch, but the world of proposals might look totally different. A differentiating product like Evo will make the grassroots movement all the better... That's why I say... "Hold the phone" it's okay to be still and not act right now.

my2duffs
 
Hold the phone...

This type of proposal, could change everything we currently know about the # of Dash available for future proposals...

should-the-core-team-start-saving-for-massive-market-campaign.14387 (@TanteStefana)

If I have the choice to fund the Core Team and Dash Foundation for Evolution (Evo) development and marketing or meetups in xxx country... I'm going with every dollar to the Core and Foundation... If the Core Team and Dash Foundation don't ask for all the Dash available, I will fund the grassroots proposals like the ones we see now... Evo needs to be the focus... Which is why, I have stopped voting for now... We have no proposals from the Core or Foundation yet.

----------------------
Currently :
Total Current Allocated Budget: 494.00 DASH ($37,548.94).
Total Available Budget: 6,651.85 DASH ($505,607.11).

----------------------

This isn't to take away from the excellent grassroots movement we see today, it's just saying all funds on deck for Evo. I feel, it wouldn't be un-reasonable to have a 2% marketcap budget for the Evo marketing launch alone... That's about 10.3M USD... We should start saving asap! The grassroots projects will come after the Evo launch, but the world of proposals might look totally different. A differentiating product like Evo will make the grassroots movement all the better... That's why I say... "Hold the phone" it's okay to be still and not act right now.

my2duffs

Actually, I think you'll find the way it works is that winning proposals are sorted by success rate and paid off in that order until there's no more funds left. In which case, this proposal won't affect your wishes for a massive marketing campaign / core development.
 
That's an interesting idea but I can see a flaw here.
TL;DR: fee must be flat inside one budget cycle or it's an attack vector otherwise.

The question is - how do you determine proposal number? Based on what? There are few possibilities: you can try to use Time which is a part of proposal or you can try to use block in which proposal collateral was mined. However, you need to keep in mind that before proposal is submitted network won't recognize your collateral as a collateral, it's just some random tx where funds are burned. It's very easy for an attacker to invalidate ALL proposals - he simply need to prepare proposals before anyone else (right after the previous cycle) but do not submit yet. He then just waits till the end of the cycle and once most proposers has their proposals submitted, he would finally submit his proposals and thus invalidate all the other. He won't get anything in return as no one would vote for his proposals but he just ruined the whole budget cycle for just 10 DASH (so probably can make a lot by shorting).
 
As many of you know, there has been much discussion regarding the current 5 dash proposal fee. In fact, at this time of writing, there is an active proposal to reduce the proposal fee to 1 dash (approximately US$75). This debate has 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.

Clearly, none of us can be sure what impact a change in proposal fee will bring. However, if the 1 dash proposal passes, I am willing to at least give it a try. If, however, it becomes clear the 1 dash proposal is not working, I would consider making the following proposal ASAP.

I suggest the initial proposal fee is set to 1 dash for the first 10 proposals. Subsequent blocks of 10 proposals would multiply the price by 1.5x. Thus, the following schedule would apply:

Proposals 01 - 10 = 1.0 dash
Proposals 11 - 20 = 1.5 dash
Proposals 21 - 30 = 2.25 dash
Proposals 31 - 40 = 3.375 dash
Proposals 41 - 50 = 5.625 dash
Proposals 51 - 60 = 8.4375 dash
...and so on

As you can see, proposals 41 - 50 would approximate the current price. More importantly, the fee becomes significantly more expensive, thus keeping to the original intention of preventing spam.

Obviously, this would need the blessing of core. I'm not entirely sure about difficulty of implementation, except to say, it doesn't look terribly difficult, and I don't anticipate a fork.

I can see a lot of magic numbers in your proposal. Why do you consider that 80 proposals are enough for the masternodes? Some masternodes may think that 40 are enough, some others may think that 160 are ok. Also the way the proposal fee increase is also a magic number. Why it should increase every 10 proposals? I mean why you chosed the specific funtion, and not another? Do you think everybody agree with this incremental function?

You have to explain the rationality of your magic numbers and the rationality of the magic numbers your incremental function contains. Otherwise if you cannot explain them then your proposal will not pass the test of time. This is a common mistake. The 5 dash proposal fee was a magic number, and now look how many problems and endless talks this caused. It is not wise to repeat the same mistake twice. It is wise to vote the numbers. Vote the numbers maintains the kiss principle. (Kiss=keep it simple, stupid)
 
Last edited:
And when Dash is 500$ or 1000$, then we start this debate again and again.
Fee needs to be variable and self adjustable, so this problem is no more.

Edit typo
 
Last edited:
I think this would make the proposal quality inconsistent. You don't need to put as much effort to make a proposal risking 1 Dash as you would a proposal needing 5.

For example, 20 shitty proposals @1-1.5 Dash could outprice a worthy proposal that would be made @1.5 but now must pay 2.25. At the same time, the first a couple of the first 10 proposals might have not been submitted if the fee was 1.5.

So you actually make the spam-filter work against the network. I would prefer that everybody would pay the same fee.
 
That's an interesting idea but I can see a flaw here.
TL;DR: fee must be flat inside one budget cycle or it's an attack vector otherwise.

The question is - how do you determine proposal number? Based on what? There are few possibilities: you can try to use Time which is a part of proposal or you can try to use block in which proposal collateral was mined. However, you need to keep in mind that before proposal is submitted network won't recognize your collateral as a collateral, it's just some random tx where funds are burned. It's very easy for an attacker to invalidate ALL proposals - he simply need to prepare proposals before anyone else (right after the previous cycle) but do not submit yet. He then just waits till the end of the cycle and once most proposers has their proposals submitted, he would finally submit his proposals and thus invalidate all the other. He won't get anything in return as no one would vote for his proposals but he just ruined the whole budget cycle for just 10 DASH (so probably can make a lot by shorting).

I think what you're saying is, someone could just submit 50 dumb proposals and automatically price out further proposals. It's true, it wasn't such a great idea.
 
I think what you're saying is, someone could just submit 50 dumb proposals and automatically price out further proposals. It's true, it wasn't such a great idea.

It is not very clever, but it is much more clever than the hardcoded 5 dash proposal fee.

And if you design it in a way that all your magic numbers and incremental functions are votable, then whovever tries to submit 50 dumb proposals in order to automatically price out furhter proposals, he will discover that the 50 dump proposals are not enough, because the magic numbers (he counted on) have already changed by the vote of the masternodes (or by whoever is in charge to vote) . Vote the numbers makes the system adaptable. The more numbers are designed to be voted, the more adaptable the system becomes.

I suggest the initial proposal fee is set to 1 dash for the first 10 proposals. Subsequent blocks of 10 proposals would multiply the price by 1.5x. .

You could say:
I suggest the initial proposal fee is set to X dash for the first Y proposals. Subsequent blocks of Z proposals would multiply the price by Px.. You are allowed to vote X,Y,Z,P
 
Last edited:
I suggest the initial proposal fee is set to X dash for the first Y proposals. Subsequent blocks of Z proposals would multiply the price by Px.. You are allowed to vote X,Y,Z,P

This proposition is smart because it solves somehow the last minute proposal problem.
The people who propose the first day of the month, are incentivized.
The spies who propose the last minute just before the budget finilization, in order to get the money and run, are repelled.
 
This proposition is smart because it solves somehow the last minute proposal problem.
The people who propose the first day of the month, are incentivized.

Nope, as pointed out, it doesn't stop someone blindly submitting spam and forcing the price upwards. There's a new pre-proposal now...
 
Nope, as pointed out, it doesn't stop someone blindly submitting spam and forcing the price upwards. There's a new pre-proposal now...

Yet the attack is temporary. Whenever someone submits spam proposals, the X,Y,Z,P values will change accordingly upon vote in order to eliminate the bad spam view that appears to the (overly spam frustrarted) masternodes operators. Whenever the spammer is tired and financily exhausted, the X,Y,Z,P values will come back to the correct number. The worst thing he can do is to spam a single budget cycle, this no big deal!

Along with the proposal rate "yes/no/abstain" you could add a rate "spam", and filter the spam proposals from your view. Or even assing the task of filtering the spam to some moderators of your choice. The community may hire some moderators to do this job, tagging some proposals as spam and recommend the (overly spam frustrarted) masternodes to filter them. Spam is not a big deal, or something you should really care about. Dont spread FUD with the spam danger. It is something the dash community should not worry a lot. Let the spam first arrive , and then many measures can be taken in order to eliminate it, with the filtering being one of them.

Spam is just an ugly bad view, but nothing more. It is not something really dangerous.
 
Last edited:
I think what you're saying is, someone could just submit 50 dumb proposals and automatically price out further proposals. It's true, it wasn't such a great idea.
Not quite, what you just described is an economical weakness of the idea where after 50 DASH it's way too expensive to submit new proposals in current budget cycle. What I described is a lack of technological reliability in any possible implementations of such idea I can imagine which in its turn opens an attack vector where even 10 DASH is enough to make ALL new proposals in current budget cycle invalid. So yes, it's not the best one either way but it's ok :)
 
Not quite, what you just described is an economical weakness of the idea where after 50 DASH it's way too expensive to submit new proposals in current budget cycle. What I described is a lack of technological reliability in any possible implementations of such idea I can imagine which in its turn opens an attack vector where even 10 DASH is enough to make ALL new proposals in current budget cycle invalid. So yes, it's not the best one either way but it's ok :)

Yes, well, I have a second idea now https://www.dash.org/forum/threads/pre-proposal-for-proposal-fee-rebates.14502/
 
Actually, I think you'll find the way it works is that winning proposals are sorted by success rate and paid off in that order until there's no more funds left. In which case, this proposal won't affect your wishes for a massive marketing campaign / core development.

Understood, but to have 50-75 proposals to follow, review and vote on seems like spam, if only the top 5 receive funding, because their budgets are so big.... Just my opinion and it's healthy we have different ones... Cheers! :)
 
Back
Top