Add ability to Negate / Oppose another Voter

[bytemaster]

First Principles of Steem and Voting

• Every proposed change, payout, should be subject to a virtual YES / NO vote
• If one user is able to vote YES, then another user should be able to counter it with a NO
• In a perfectly expressive voting system two users with equal stake and perfectly opposite opinions could actively cancel each other's opinion (resulting in a tie). Whenever there is a tie, the decision is left to the remaining voters.

  Avoid a Voting War

Rather than making everything subject to a YES / NO vote and starting a voting war which could be won by whoever has the most aggressive bot with the "last say", we can automate the process. Automating the process saves the network bandwidth, solves the "last vote wins" issue, and also solves problems caused by people being unable to perfectly counter someone else through limits in the normal voting pattern.

Countering Upvotes

It is currently impossible to counter the profits someone earns by upvoting without causing unwanted side effects.

Witnesses Voting

In an ideal world there would be no limit to the number of witnesses someone could approve. This is the nature of approval voting. Due to resource constraints each account is limited to approving 30 witnesses. This limit makes it impossible to express an opinion of approving "everyone but X" which would normally be expressed by upvoting everyone but X.

It is currently impossible to counter someone voting for collusive and/or abusive witnesses while remaining neutral toward the remaining witnesses.

Countering Vote Spam

Vote spammers flood the network with low value practically meaningless votes. These users are limited by bandwidth but still cause a net negative impact on the platform. There is currently no way to prevent this spam short of censorship.

Implementation Details

Every account shall have the power to "oppose" another account with a certain number of VESTS via a new operation:

oppose_account  account opposing_account weight_vests 

The impact of this operation is to temporarily reduce the number of VESTS both accounts can vote with by _weightvests for one week. It can be renewed at any time to extend the period by 7 days from the time of transaction.

An account must have a positive number of votable VESTS in order to oppose another user. This means that a user who abuses negative voting would be unable to renew their negative positions against other users while they have a negative votable VESTS balance.

Limits on Number of accounts Opposed

Due to resource constraints and to prevent a single whale from actively negating thousands of normal users, the weight_vests must be greater than the min account creation fee. It must also be greater than 1/256 of the initiators VESTS.

In practice this means that a whale can oppose at most 256 people and that a minnow can only oppose a single minnow. The number of people you can oppose grows linearly from 1 to 256 until your VESTS equal 256 times the account creation fee.

Rationale for 1 week period

By having a 1 week period it becomes possible to negate someone's negative vote against someone else. In other words, you can force them to negate you rather than the person they are currently negating.

Without this maximum time, then applying a negative vote against someone else could not be countered or would require an unbounded amount of potentially ambiguous computation to recursively remove negative votes.

It is undesirable for people to be locked in opposition "for ever". People should be given a chance to redeem themselves unless there is active intervention. It would take a dedicated villain to run a bot to automatically start abusing again after expiration or to automatically renew opposition against someone for no reason.

Additional Side Effects

With this feature it is possible for whales to "agree not to vote" and let the dolphins (who are greater in number) curate.

Economic Analysis

There is a real opportunity cost associated with negative voting. Any whale engaged in such a practice is giving up the curation rewards they could be earning. They would also be giving up their own positive influence. This means that there must be clear economic reasons to engage in negative voting which should minimize its abuse.

[steemed]

This is all you need to know about ben: https://steemd.com/tx/9d83a22907ea6a58c887ac4e15173e6363ee9d7b

steemit vest 8,071 STEEM to ben Mar 31

That was when 1 STEEM = 1 VEST

[bytemaster]

Hello everyone. We have been debating this issue and I have concluded that a better approach is needed. More details on why and what alternatives exist will be forthcoming.

[lukestokes]

@bytemaster Thank you. I've been following this issue closely and my biggest concern was how you would respond to the community. My trust in this platform's long term success, currently, is in whether or not those with the most to lose will continue to act rationally for the long term benefit of everyone involved.

[talerecursion]

One way to restructure that change would be to separate the witness downvoting (just need to change the "approve" parameter of vote_for_witness into a -1/0/1 enum) and the voting power cancellation (oppose_account) and ship only the features on which there is sufficient consensus.

[bytemaster]

witness downvoting has other issues and was removed from bitshares for a reason. You need to downvote the voter, not the witness for that to work.

[talerecursion]

What are the other issues?

[bytemaster]

Wack-a-mole. A coordinated attacking group can move their upvotes to a new account faster than the uncoordinated masses can negate it. In effect, you can move the target of the downvote. By downvoting VESTS you avoid wack a mole.

[samupaha]

Wack-a-mole. A coordinated attacking group can move their upvotes to a new account faster than the uncoordinated masses can negate it. In effect, you can move the target of the downvote. By downvoting VESTS you avoid wack a mole.

This applies only to a situation where an attacker is trying to get a witness elected who shouldn't be elected. How realistic threat this is?

I'd guess that more common situation is that a witness who has behaved well so far will start to act in a way that he loses some support. Because voting happens so slowly, some users might want to speed the process by downvoting the witness.

In this case downvoting VESTS would be problematic. People are opposing only one particular witness upvote, not all the votes that somebody has casted.

By getting some downvotes the witness himself could also get valuable feedback that he is doing something that the community doesn't like.

[talerecursion]

@bytemaster: I see. You can prevent that by making it necessary to have a minimum of x MV to be eligible as a permanent witness. Witnesses should have some seniority in the community and some skin in the game so that doesn't sound like a too harsh requirement I think.

[talerecursion]

The problem of downvoting voters is that it's anything but fair. Regardless of what one think of the witness, everyone is entitled to vote as they see fit and they shouldn't be punished because they voted for someone other people didn't approve of.

[Alifton]

It's obvious this change has been tabled for further discussion at this time. Could we please move on towards more constructive solutions and away from people threatening retribution like a mob with torches and pitchforks?

We all saw what happened to the Ethereum Foundation when they alienated their user base and how well that turned out for them. Could we please let that serve as a cautionary tale regarding these types of issues. As a united group we can learn from their mistakes and hopefully not follow down that same path with Steemit.

The Ethereum Foundation's solution only served to harm the Ethereum platform as a whole in the end by forcing users to choose sides when instead everyone could have been a part of the same team while moving forward for the sake of progress.

[theoreticalbts]

Did some git housekeeping on the branch and force-pushed.

[inertia186]

So, can we do this now? That'd be great.

[matthewniemerg]

pretty clear that this won't happen. issue is closed and has a label of 'wontfix'.

[bytemaster]

I still think that the first principles are right on this concept. Unfortunately, having logical first principles and appealing to the masses are two entirely different things.

[matthewniemerg]

I'm not sure what this accomplishes. A user who has had his vote negated (due to whatever reason) by other users can power down and transfer vests to a new account within a 3 month period with no linkability (other than through exchange partners, who may provide people with that data -- but probably not).

This proposal still appears to be censorship, and censorship-resistance is a major selling point for the STEEM blockchain.

What's to stop a malicious actor (oppressive nation-state or corporation) from buying lots of steem, powering up, and then silencing critics?

[TimCliff]

Could this be implemented with a bot that just did the opposite of what a user did, or is there more to it than this?

[abitmore]

Could this be implemented with a bot that just did the opposite of what a user did, or is there more to it than this?

After HF17, for the comments (with no curation reward), yes. Otherwise, the up-voter will still earn some if the final payout is positive.

[Serkan-devel]

I theory, what would happen if posts wont be hidden at all? Downvoted content could still be downranked