A simple voting strategy for MNOs

[jimbursch]

The premise of this voting strategy is that an MNO cannot thoroughly evaluate every proposal and should not waste time/effort trying to do so. An MNO should only evaluate proposals where he/she has specific domain expertise. For the rest, use this strategy. This strategy will facilitate emergence of "wisdom of the crowd."

First, a couple of definitions:

Above-the-line: this refers to proposals that are on track for approval; they have the 10% margin needed to pass.
Below-the-line: these are proposals that are not currently on track for approval; they need additional yes votes to pass.

See the line at https://dashvotetracker.com/

The strategy:

1. By default, vote YES on ALL proposals unless you have a good reason to vote NO. Make this a simple default policy. When in doubt, vote YES. Don't worry about the rest.

2. Enter your YES vote for ALL proposals some time in the middle of the month. Don't wait until the last minute. Last minute voting encourages proposal owners to wait until the last minute to submit proposals. This is not good. Dash Core is guilty of this. Bad Core. Sit. Stay.

3. Sometime before the close of voting -- at least a few days, preferably a week -- take a look at the list of proposals and note those that are Below-the-line. If there is a proposal you LIKE that is Below-the-line, then choose a proposal (that you don't care about) that is Above-the-line and change its vote to NO. The idea is to push down mediocre proposals.

It is better for an MNO to use this strategy than to not vote at all, and it is better for an MNO to use this strategy rather than waste time/effort trying to evaluate proposals without domain expertise.

We will get better results if more MNOs vote using this simple strategy, and it will be more effective if more MNOs use it instead of not voting at all.

 

[martinf]

I think we need a clear statement regarding the unused budget. Historically it's referred to as "burned", but there has been comments that there is a possibility to bring those burned coins back in the future. This would required massive MNO support, but still.

It makes a huge difference if the alternative is to save unused budget for future projects, rather than just default to voting YES for everything.

 

[jimbursch]

referred to as "burned"

Nothing is burned. Burned implies some sort of loss. Nothing is lost. It is Dash that is simply not created.

This simple voting strategy can improve the outcome of the budget process right now if it is adopted.

 

[tungfa]

hmmmm
double work involved in this
“vote all yes - do 2nd round and decide what u really wanna vote in ...”

i try to stay on track with “fresh” proposals when i am involved in the pre discussions
and vote right there and then
i general try to be on track with all my votes by mid month so have enough time to engage with owners if needed

 

[martinf]

Nothing is burned. Burned implies some sort of loss. Nothing is lost. It is Dash that is simply not created.

This simple voting strategy can improve the outcome of the budget process right now if it is adopted.

I agree. The quotation marks meant to indicate that it's a rather unfortunate name. Still, it's what has been used in the passed so I thought I'd stick to it.

Anyway, the issue I'm trying to highlight is covered in this thread: https://www.dash.org/forum/threads/stop-dash-from-getting-burned.14296/

My point is that the whether or not "never-created-treasury-funds" (better?) can be created at a later point in time, or not, makes a huge difference in how to vote. The strategy you mention above would likely create a situation where most proposals get more than the required 10% net positive votes and that the above/under-the-line limit is determined by the priorities and total fund size. We will use the entire budget each time.
Now. I oppose such strategy IF there is an expressed intention to bring back "never-created-treasury-funds" later in time, e.g. when the treasury budget is insufficient to cover very important proposals (could be due to very expensive proposal, low dash value due to critical bug, low budget in the far future etc).
In such scenario I much rather keep funds by only voting YES on proposals I really think should pass, rather than defaulting to YES on all.

Clarifying the policy around "never-created-treasury-funds" asap also makes sense to prevent backlash and scam accusations if/when the funds are brought back in the future.

 

[demo]

Wow. So much for reasoned discourse and sober discussion based on knowable facts.
"A simple voting strategy for MNOs" is simply a false statement in the form of a headline. One need go no further.

Please change the false statement to a true statement. Change the title to "A simple voting strategy for stupid MNOs"

 

[demo]

1. By default, vote YES on ALL proposals unless you have a good reason to vote NO. Make this a simple default policy. When in doubt, vote YES. Don't worry about the rest.

Is there a reason for a stupid masternode to vote all "yes" by default? Why not voting all "no" by default?
I think the stupid masternode should vote half yes, half no, in a random way.
The reason?
"In everything the middle road is best." -- Cleobulus.

 

[TheSingleton]

This will unfortunately only work if everybody starts doing it which is quite unlikely.

Something I think should be improved is that you can only submit proposals for the current budget cycle a week before the voting deadline or earlier.

 

[qwizzie]

I wonder if we get any changes to the budget system, there was a lot of talk in the past about implementing contracts in our budget system.
Those contracts would have a higher treshold (20%?), that would secure funding over a specific time period. The last i heard is that our current
budget proposal system would be giving some time to operate, before Dash Core team would open up discussions with the community on
how to proceed with this.

I'm mentioning it in here because we are talking about the budget system and voting behaviour and introducing contracts could impact that.

 

[joemoraca]

@jimbursch I don't get the logic of how that voting pattern helps anything. Blindly voting yes / no / abstain seems all the same to me. May as well not vote.

 

[TroyDASH]

I like this strategy better:

If you feel strongly about a proposal and you think that there might be a significant opposing vote, then vote early and comment.

If you think that a proposal is an obvious yes and is likely to be funded, vote yes at whenever is convenient for you.

If you think that a proposal is an obvious no and already has a negative net vote, don't bother to vote. Vote no if it pops above 0%.

If you do not feel strongly about a proposal or if you don't know enough to make a decision, wait until the last week to vote and evaluate it considering the feedback of other MNOs.


For me, anyway. Do whatever you think is best

 

[jimbursch]

Blindly voting yes / no / abstain seems all the same to me.

These are not blind votes -- this is a strategy to help the "wisdom of the crowd" emerge.

@martinf gets it:

The strategy you mention above would likely create a situation where most proposals get more than the required 10% net positive votes and that the above/under-the-line limit is determined by the priorities and total fund size.

 

[RGXDK]

1. By default, vote YES on ALL proposals unless you have a good reason to vote NO. Make this a simple default policy. When in doubt, vote YES. Don't worry about the rest.

@jimbursch

I strongly disagree with this idea and I do exactly the opposite. I vote NO on ALL proposals unless I have a good reason to vote yes.

My reasons for it are:

1. I respect everyone else's money and am of the opinion that everyone should be extremely responsible with the budget.
2. At least 50% of the proposals are just a waste of time and/or offer zero or very little ROI for the network. Another 25% of what's left have ROI that is very difficult to measure and should be voted NO unless there's a really good reason not to.
3. Everyone benefit when we don't dilute the currency supply by creating money.
4. By voting NO you discourage the unprepared and unprofessional proposers from wasting everyone's time.
5. By expecting a NO only those proposers who are confident they can bring value to the network will submit a proposal, and that's what we want.

Having said that, I would agree with @jimbursch and be willing to be more flexible IF:

- all the proposals had escrow,
- if there was a reputation system in place
- if there was a team evaluating and giving the network status on the proposals
- if we had strong reporting on what happened with the other proposals we voted for
- if the ROI was easy to measure or very well defined

If anyone disagrees, please elaborate on the reasons.

 

[demo]

Having said that, I would agree with @jimbursch and be willing to be more flexible IF:

- all the proposals had escrow,
- if there was a reputation system in place
- if there was a team evaluating and giving the network status on the proposals
- if we had strong reporting on what happened with the other proposals we voted for
- if the ROI was easy to measure or very well defined

If anyone disagrees, please elaborate on the reasons.

I disagree...because more reasons are needed....

I would agree with @jimbursch and be willing to be more flexible to vote a default "yes" IF:

1. The votes were kept in blockchain and there is a vote history.
2. Could post a proposal, then wait for a "yes", a "no", a "other", but also below the "other" poll option anyone can add as a poll option his alternative proposal.
3. All the actors could vote, just for statistical reasons while their vote does not count.
4. the masternodes have privkey for voting separated from the one used for network identification
5. if there is no delivarable from a project, the Masternodes who voted for it to pay the loss.
6. The masternodes were able to cast votes using numbers and extract the results as an average
7. The masternodes were able to vote how much DASH they give for a budget proposal
8. this proof of individuality is implemented in Dash
9. In case a voted proposal exceeds the deadline then anyone should be able to do it and get the reward
10. the proposals were classified.

Of course those 10 prerequisites are science fiction, because I am not a masternode owner.

 

[TroyDASH]

These are not blind votes -- this is a strategy to help the "wisdom of the crowd" emerge.

@martinf gets it:

With what you are proposing, the same thing could be achieved by lowering the passing threshold to 0% or removing the threshold altogether.

 

[camosoul]

I have a much simpler strategy: STOP BEING A BUNCH OF FUCKIN' RETARDS!

There is no "wisdom of the crowd," as is evidenced by the past year or so... There's no value balance. No consequences. No granular control.

One can proffer that the MNOs are too stupid anyway, so why fix the budget system? I point out that a car with no brake pedal, no tires, and the ability to only turn left, is a car no one will bother to learn how to drive.

MNOs would be less stupid if the car they were driving wasn't a completely fucked up car.

But, then, we have to remember that a fucked up backwards budget system was chosen deliberately because it's fucked up and backwards... Better options were available. Pretty much anything is better... This was implemented with full knowledge and intent to abuse it's failings.

Would you bother driving a car with no brake pedal, no tires, and can only turn left? Does that make the people who would rather walk, stupid? Or does the car lack necessary features, which, if added, smart people might be interested in the car? The closest thing to "wisdom of the crowd" that can be seen in the budget, is the huge volume of people who don't bother to participate in such a stupidly poor design. The MNOs look like idiots because the smart people simply opt out because they know how dumb it is, and only the morons are participating. Which is, unfortunately, by design and exactly what Evan was going for when he did it...

Cue @demo and his half-measure "vote the numbers" crap... There's a grain of truth in, but, only a grain...

If you judge a fish by it's ability to climb a tree; it is not the fish which has failed. It's a fish, you dumbass. It's not supposed to climb trees.

 

[TroyDASH]

I have a much simpler strategy: STOP BEING A BUNCH OF FUCKIN' RETARDS!

Noted.

But, then, we have to remember that a fucked up backwards budget system was chosen deliberately because it's fucked up and backwards...

This was implemented with full knowledge and intent to abuse it's failings.

only the morons are participating. Which is, unfortunately, by design and exactly what Evan was going for when he did it...

We also have to remember that an unsubstantiated claim repeated over and over doesn't make it any more credible.

 

[camosoul]

We also have to remember that an unsubstantiated claim repeated over and over doesn't make it any more credible.

Do we continue denying that air exists even as we see the trees bend in the wind?

I have no need to substantiate my claim when the results of it's actuality are plainly visible.

You may refute many things, but not what is plainly observable.

Your inability, or unwillingness, to observe a thing does not make it go away. The results of "it" are still there, so "it" must exist.

If you judge a tree by how many fish have climbed it... We see the problem when we realize that most MNO fish do not bother trying to climb the budget tree. They're fish and they know it.

 

[TroyDASH]

Do we continue denying that air exists even as we see the trees bend in the wind?

I have no need to substantiate my claim when the results of it's actuality are plainly visible.

You may refute many things, but not what is plainly observable.

Your inability, or unwillingness, to observe a thing does not make it go away. The results of "it" are still there, so "it" must exist.

In order to establish "it", you need to establish (1) what the result *is* and that the result has in fact happened, and (2) why "it" can reasonably be expected to be a necessary condition for that result.
If you care at all about having your message heard, then you are going to need to explain yourself. No one can read your mind. If you don't care about that then why are you here?

 

[camosoul]

My point is that it doesn't matter if you believe the wind is caused by Demon belches or Angel farts.

The wind does indeed blow. This proves air exists.

If I can prove the air is 60% Nitrogen and manufactured in a secret Siberian lab where Hitler escaped to with the Holy Grail... Or not... Doesn't matter.

A busted budget system was chosen, and the defects abused exactly as the alternatives would have prevented. You can call it a coincidence if you like...

You can believe that it is caused by Demon belches, I'll believe it's caused by Angel farts.

Neither belief changes the fact that it is so, with or without substantiation. The result cannot be questioned. The causation discussion can lead to nothing more than a distinction without a difference, because the result is already known.

I outlined exactly how this budget could and would be abused, it was chosen anyway, and immediately abused exactly as I described, by exactly the people I said would do it, and by the precise mode of failure I predicted. I am not magic, I have experience and have seen it before.

That's a lot of coincidences, but if Cinderella is an octopus, whatevs.

How can one count on "the wisdom of the mob" when only 5 out of 5000 have any experience or clue what's going on? There is a reason why a select few make major decisions in an organization, and it's not handed down to the peons.