Add ability to Negate / Oppose another Voter #279
Comments
|
This is going to be abused and end badly. It's a nice try. But it's more likely the "dedicated villian" just leaves his list up and automatically renewing as long as whoever is paying him to do this keeps paying. Remember a villain is just a hero of the other side. They are playing a different game than you for different reasons and making their money outside the system. You need to stop thinking in terms of punishing bad behavior and start thinking in terms of rewarding good behavior. Punishment drives users away good and bad, reward pulls them in and makes them do whatever it is you want them to do in order to earn the reward. You don't even need all this complicated stuff, if instead you ditched posting and content rewards all together and force content to trend based on number of comments with upvotes that have commentary. Then just proportion the rewards out to the commentors based on number of upvotes received on their comments that also have comments. Tax the total rewards 25% and give it to the original poster. Everyone makes more money, the bots disappear and this will encourage legitimate discourse. |
Great statement! I'd like to add that I think that most of the suggestions that have been put forth by users is to only be able to downvote certain votes on any post. I haven't seen anyone clamoring for the ability of countering one person's entire voting power. I think it would be more prudent to consider smaller pieces of this proposal in incremental stages so that witnesses can vote on each concept individually. |
|
@willbanks Upvotes/comments doesn't work. If you do it by upvotes/comments alone, then anyone can make a bot army and get a post to the top instantly. It has to be done by vote weight (i.e. post worth), since it's much more difficult to create bots that also have weight on their votes. It's still fine if Steemit.com just hid the amount a post was earning, but ordering by votes/comments just opens the platform for bot abuse even more. |
|
@Someguy123 You're right of course, it should be based on number of followers and the combined rep of their followers. My other was too simplistic. Point was stop trying to punish bad behavior and just remove all incentive for things that are "bad" while incentivizing "good behavior". Adding an API to allow the SJW's to permanently censor the MRA's is going to end badly. |
|
@willbanks that might just work, but then we have people like "steemitmarket" with a metric ton of bot followers too, with possibly more to come. |
|
This is nothing but another method for Dan to control who he wants to see earn and who he doesn't. I expect we'll see him and his inner circle stifling whales they wish to see stop earning as soon as this is released. Just a reminder, this is being implemented because of the feelings of 1 person who will use his control over the witnesses to push through anything he wishes. Don't let it be disguised as fixing voting, he's trying to suppress accounts he doesn't agree with. |
|
No. No. No. The ability to censor a users vote power is going to create a cluster of users with the most power and the ability to control the distribution of rewards as they see fit, as they censor outliers. |
|
Thanks and my suggestion was just a different set of rules. Which was my point. |
|
This seems like a really bad idea. First, the motivation is far from clear to me. 2nd, can you cite some useful use-cases of how this will be employed. Get specific, like who would use it and who it would be used on. Just to be clear, I don't know of any "normal whales" who would use this, although one can step up if so and tell me otherwise. So far, this mostly sounds like it's useful to steemit itself, and only as a way to increase centralized control. |
|
@Any-X I could see this leading to vote power wars too...may be best to keep it limited to the reputation wars we will surely have already. Maintaining as much simplicity as possible == efficiency and reliability, just like any good machine / application. |
|
I'm going to throw my two cents in here for whatever it's worth. I'm not taking a side here. I feel like this is getting too heated and a collective "step back" needs to be taken by many here. I've read everything here, including the entirety of @bytemaster's OP here, and there are some decent fundamentals as to how this could work. But I also see a lot of holes and potential avenues for abuse, as well as a very complex solution to a problem I'm not even sure I see. I'd love to be enlightened if I'm not seeing the whole picture here. What's important though is that we need to consider it's impact to the community. Any change that involves any users ability to impact another user needs a fair amount of conversation. As far as I can tell, some code has been written for this idea, but it's not like a hardfork is live and already a ticking clock. So, what's the actual problem here to solve here? Is it vote spam? Here's the trends in voting over the past 45 days...
Is vote spam really the problem here? There are a lot of votes, I'd wager a good double digit percent are indeed spam, but it's not increasing right now. Wouldn't a simpler, less abusive strategy to simply be to improve the "voting power" system? Hell, even put a hard limit on votes per day as a stop-gap. I'd consider myself an active voter and I don't ever go over 30-50 votes a day. Put it at 100, or 200, whatever. Do we really want to rely on the weight/power of the 1% to moderate the 99%? I feel like you guys have better things to do than spend your time identifying and fighting spammers. |
|
I agree with @dnotestein that it it's hard to see what the actual benefit of this is, you need to make a better case of what this is actually useful for. Who would use this and why? It seems to me you're adding complexity to solve a theoretical problem that may or may not ever become an actual issue, and that you're taking your political ideas and projecting them onto STEEM. Even more complexity = Bad. |
|
Dan, all I will say is: Don't become a cunt that doesn't listen to the community, or the community will leave. You do this important choice by yourself with barely letting witnesses or people know, I know you are on the top and probably give 0 fucks right now, but regrets always come later. |
|
@andulolika Dan does what Ned says... and right now the "Company" is dictating what it wants to see happen, not the community. Which is why this comment will probably get deleted just like the rest of my comments. |
|
So the censorship resistant thing is basically bullshit? That would suck, if this proves itself to be true we shall (and I will) start a movement against this and make a big deal out of it. |
|
Go look at the posts the "Company" accounts have downvoted, ya not all are because they are spam, just because they don't like the content or author. The "Company" should stay out of the voting process all together, the community can down vote spam if we want. |
|
I believe they should upvote-downvote scammy/bad content that went up but not vote influenced by personal opinions yet sticking to quality content. |
|
I support entirely this change. What this commit implements can be emulated with a bot that follows every action of the user and downvote all the posts he upvotes and upvotes all the posts he downvotes. The main difference is that the bot version is more spammy and only available to advanced users including whales and bot spammers whereas this mechanism is clean and available to all equally. Negating voting also has a few great upsides: it allows to vote against a witness instead of upvoting every other competing witness. That's a powerful and explicit message to send to all the free-rider witnesses who are content to take the ~60k USD / month reward but don't even bother making weekly reports. Instead of "not seeing their support grow" (which they won't even notice), lazy witnesses will see their power be eaten up a little bit more every week and that they should notice, in particular if the GUI allows to display separately negative voting on witnesses. It also allows minnows to overthrow an evil whale. If enough minnows sacrifice their voting power, a whale can become powerless. That would make good food for thoughts for whales who think they are almighty and abuse their power. |
It's not the same. Dan explains how it is different. The present proposal gives the team, which has awesome centralized and coordinated power, the ability to censor anyone they want. |
The "team" already has all the power they need to censor anyone they want. Just look at @steemit SP balance. It's pointless to worry at this point in time about what Steemit could do if they become evil because regardless of whether this commit is included or not Steem would be dead either way. Let's discuss on the relative merits and short coming of this feature and not start chasing FUD. |
The team already censors people. The problem here is in defining good as being what the team wants and bad being anything that is opposed. I'm #15 on the witness list right now. Do you want to bet me I'll start dropping because of coordinated team votes for expressing my opinion? Will you say I am fudding if that happens? |
|
@talerecursion : He's not chasing FUD. We're talking about a technical feature that makes it very easy for the steemit account to essentially nullify every whale and do it very easily. As a practical matter, you're wrong, under the current voting/curation rules, they can't do it easily or quietly. |
|
Really interesting system, but I have to agree with others that I don't see immediate benefit from this. talerecursion has good points but I'm not sure if it's a good idea to oppose everything that somebody does. If a user acts abusively 1/10 of the time, it doesn't make any sense to oppose him because that negates many good votes also. So basically this would be used only against really badly acting bots? How big threat they are currently? Opposing witnesses is the best thing in this proposal. Whether or not the whole proposal will be accepted, at least it should be made possible to vote against a witness. |
|
Assume that you and your wife have different political opinions. She will vote for A or B, but you want to vote for nothing. You can counter vote only when she let you know who she voted for. It's not free. The proposed lazy counter-voting is too cheap, imo it will most likely be abused. Perhaps it's doable if we set some limitations, for example:
|
|
While people learns to differenciate bots and since greed the hate towards them is growing I wouldn't worry about them too much. |
@steemed: can you define what you call the "team". Is it Steemit, Bitshares witnesses, Steemit + Bitshares witnesses? If you are referring to anything that includes Steemit, they can already kick you out of the list by withdrawing their support. And if you are referring to other witnesses, then you can pay them back by having whoever upvoted you downvote them in retaliation. Because of that possibility, I don't think people will be messing with that thing unless they have a very strong reason. |
|
silversteem and nextgencrypto were two of the most active witnesses before they were purged by dan and then roadscape, and now more effectively by ben. clains list is a joke because of the efforts of the dev team. |
|
I am saving every iteration of this conversation. If posts get deleted they will be published elsewhere. |
|
Well, that's getting quite political. It's entirely possible that "the team" wants to dictate who makes the list, but they have the voting power to do so, and that can't be opposed. I know it sucks for people who were doing a lot of good work and lost their slot anyway. I hope they can keep enough voting power to have decent results as backup witnesses, and make it back to the list at a later point. |
|
My point: don't make it easier on them. |
|
Well I think this conversation will be cleaned up because it has really strayed off topic pretty badly. But anyway. Who is Ben actually? Never heard of a Ben before. |
|
This is all you need to know about ben: steemit vest 8,071 STEEM to ben Mar 31 That was when 1 STEEM = 1 VEST |
|
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. |
|
@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. |
|
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. |
|
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. |
|
What are the other issues? |
|
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. |
|
@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. |
|
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. |
|
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. |
|
Did some git housekeeping on the branch and force-pushed. |
|
So, can we do this now? That'd be great. |
|
pretty clear that this won't happen. issue is closed and has a label of 'wontfix'. |
|
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. |
|
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? |
|
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. |
|
I theory, what would happen if posts wont be hidden at all? |
and others
First Principles of Steem and Voting
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:
The impact of this operation is to temporarily reduce the number of VESTS both accounts can vote with by weight_vests 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.
The text was updated successfully, but these errors were encountered: