Allow Removal of up vote.

[bytemaster]

If someone makes a mistake while voting or their posting key is compromised, this operation will allow that vote to be removed resulting in the pending payout "as if it never happened".

When a vote is removed, the rshares earned by the vote are removed from the post and the voter loses any share of the voting rewards due them. They cannot vote again or change their vote.

[arhag]

This proposal may possibly be relevant to this enhancement.

I have a few questions about how this would be implemented.

Would used voting power be returned to the voter that removed their vote (even partially if not fully)?

How does removing one's vote affect the comment_object's cashout_time field?

Why do you write "removal of up vote" only? Why not allow removing down votes on comments as well? Someone could just as easily accidentally hit the downvote button instead of the upvote button.

Why can the voter not vote again after they have removed their vote? Is it because you are worried about people exploiting that feature for financial gain? If so, what sort of attacks? Their voting weight in the sense of the code

cv.weight  = static_cast<uint64_t>( ( ( rshare256 * rshare256 ) / total256 ) * rshare256 );

would still be much smaller if they removed their vote, then a lot of other people upvoted the comment, and then they decided to go back and join the crowd by upvoting again. Also, if you are returning used_power back to the voter when they remove their vote and are worried about potential exploits made possible by returning used_power, you could just return a fraction of the used_power they used when voting,

[mvandeberg]

We are still working on some of the specifics on what the exact specifics of this change will entail. I can speak to a few points however.

Talking internally yesterday, I think we are going to allow removal of down votes and up votes, but only by setting their weight to 0. (Effectively nullifying the vote)

In regards to allowing a user to vote again after the removal of their vote, we run into issues of how to deal with cash out time. Cash out time is currently a vote weighted average. Each vote "votes" for the cash out time to be 24 hours after the time of the vote, weighted by the absolute value of the vote (Steem Power * Current Voting Power). If we remove the weight from the cash out time we could cause a post to immediately cash out. This is undesirable as the cash out time is in effect a contract with other users that their voice will be heard at least up until the current cash out time, if not longer. It is important to have this buffer time to allow content to be accurately and thoroughly curated. The other side of the spectrum is the desire to get payouts quickly to creators. If we allow a user to vote again (with the assumption that we do not negate their cash out time ), they could prevent payout long after when it should be paid. I have not done the math, but it could be infinite depending on how it is implemented. This is also undesirable. The easiest solution, both in implementation and to limit side effects is to not change cash out time from a removed vote and to not let the user vote again. Keep in mind, this is only for the current round of voting. After the content is cashed out, everyone can vote again. I expect this to happen for particularly important and well written content.

Refunding voting power has not been discussed at length internally. It is something we are looking into when working on this change. For something so simple conceptually, there are a lot of moving parts we need to consider to do it correctly.

[arhag]

In regards to allowing a user to vote again after the removal of their vote, we run into issues of how to deal with cash out time. Cash out time is currently a vote weighted average. Each vote "votes" for the cash out time to be 24 hours after the time of the vote, weighted by the absolute value of the vote (Steem Power * Current Voting Power). If we remove the weight from the cash out time we could cause a post to immediately cash out. This is undesirable as the cash out time is in effect a contract with other users that their voice will be heard at least up until the current cash out time, if not longer. It is important to have this buffer time to allow content to be accurately and thoroughly curated. The other side of the spectrum is the desire to get payouts quickly to creators. If we allow a user to vote again (with the assumption that we do not negate their cash out time ), they could prevent payout long after when it should be paid. I have not done the math, but it could be infinite depending on how it is implemented. This is also undesirable. The easiest solution, both in implementation and to limit side effects is to not change cash out time from a removed vote and to not let the user vote again. Keep in mind, this is only for the current round of voting. After the content is cashed out, everyone can vote again. I expect this to happen for particularly important and well written content.

Understood. My suggestion in the part of this proposal regarding voting is to distinguish between a creating a new vote (new_vote_operation) and updating the vote (vote_update_operation). Unlike the new_vote_operation, the vote_update_operation would not modify cashout_time at all. A new_vote_operation is the only one that modifies cashout_time using the same algorithm that exists currently, and also a new_vote_operation is not allowed on a comment that already has a comment_vote_object by the same voter (just like current behavior).

I believe that addresses the undesirable behavior you discussed on both ends of the spectrum. It does not lead to the exact same state/outcome that would have occurred had the voter voted the way they meant to from the beginning, but I think that is acceptable behavior.

[mvandeberg]

The problem with this is that the strength of the vote determines how it effects the cash out time.

Let's say a user sees a post is going to be paid 100.00 Steem Dollars. The user thinks it is a good value for what they read and moves on. On the other hand, if it were going to be paid 200.00, the same user might have voted it down because it was going to get too much. Now, if that payout had a low valued vote, then right before the cash out time, the voter could change their vote and change the payout significantly without allowing others to have a say in the final payout.

With the weight voted cash out time, it guarantees no large changes to payout can happen at the end of voting without extending the voting by a meaningful amount of time.

Voting for content is much more than a 'like' button. You are assigning monetary value to user generated content. We need to be as open and as fair as possible to everyone involved.

[bytemaster]

I think it is important to understand why we want the ability to change votes:

1. because my posting key was compromised and someone voted with it and I want to correct it
2. because I changed my mind, this content should not receive a payout
3. because I changed my mind, this content deserves a payout
4. because I accidentally clicked the wrong button

The solution I have proposed is to all the "rshares" to be reverted and the curation reward to be zeroed. This has the impact of allowing mistakes to be corrected and payouts to be reverted to a "neutral" level.

Voting power is still consumed, cashout date is unchanged by the retraction,

[arhag]

Let's say a user sees a post is going to be paid 100.00 Steem Dollars. The user thinks it is a good value for what they read and moves on. On the other hand, if it were going to be paid 200.00, the same user might have voted it down because it was going to get too much. Now, if that payout had a low valued vote, then right before the cash out time, the voter could change their vote and change the payout significantly without allowing others to have a say in the final payout.

With the weight voted cash out time, it guarantees no large changes to payout can happen at the end of voting without extending the voting by a meaningful amount of time.

Okay, I get the concern now. I will have to spend some time to think about this and see if there is a nicer solution that allows revoting.

[mvandeberg]

Changes milestone as hardfork 3 became a bug fix hardfork. Moving this back to the next non bug fix hardfork.

[mvandeberg]

After much discussion internally and with some members of the community we have decided to allow users to change their votes! There are a few caveats to this to prevent attacks and to minimize potential abuse of this change, but we strongly believe this change will allow for a higher level of curation and reduce cognitive barriers for content curation. Below is a summary of how we are changing voting:

• Behavior for new votes remains unchanged.
• As a general rule of thumb, you can change your vote. The only restriction to this is that you cannot change your vote within the last two hours of a payout if the change would increase the comment payout. This is prevent ninja buffing of a comment at the last second. More on this restriction later...
• If you change your vote you become ineligible for curation rewards, even on a revote. The idea behind curation rewards is to create incentive for user powered content discovery. Changing votes later does very little to push this agenda, thus those users will be ineligible for curation rewards.
• Changing your vote still costs voting power. You do not get a refund for lowering your vote, do not pass go, do not collect $200. The user will need to be mindful of this fact because changing a vote that had a lot of voting power with one that is low voting power, even if the weight is higher, might result in fewer rshares awarded to the comment.
• When a vote is removed, the cashout time of the comment is unchanged. The cashout time is a contract between the blockchain and the users that a comment will not be paid before a certain time. This behavior is necessary to enforce this contract.
• This should be trivially assumed, but net rshares for a comment are modified as though the previous vote never occurred.
• Absolute rshares are not changed prior to applying a new vote. This has the effect that vote changing does extend cashout time, but not as significantly as the first vote. We believe this is important to allow new and current voters to accurately curate content as the pending payout fluctuates.
• In the last two hours before a payout, changing your vote in a way that increases the net rshares of a comment is prohibited. New votes are still allowed as normal. This stipulation prevents a comment from being pumped in a short amount of time without extending the cashout time significantly. This is acceptable for normal voting because a large vote causes a large extension to the cashout time. However, since we do not remove absolute rshares, the extension will be smaller and smaller over time, to the point where users could pump a comment right before the cashout time without having an appreciable effect on the cashout time, effectively creating a review period of 0 seconds. We understand that this change could create an effective review period of 2 hours, but we believe it will be enough of a deterrent to prevent this sort of gaming. Keep in mind that changing a vote that causes a loss in net rshares is still allowed, so there are two hours where votes could be removed or changed to a 100% downvote entirely when the users wishing to game the system could do nothing.

[mvandeberg]

Feature merged into develop and ready for review.

[bytemaster]

We need to limit the number of times a vote can change to prevent abuse of curation rewards via pumping the abs_rshares value via rapid changing of votes.

[mvandeberg]

I almost think we should add a third field. With the addition of vote changing, the abs_rshares field now has an entirely different meaning than it used to and is thus having a negative impact on an algorithm that relied upon it. It is really the stake weighted average time algorithm for payout time that has changed, so maybe it should have another field for it. I propose something like...

• net_rshares: Same as current design. The net rshares currently given to the comment.
• current_abs_rshares: A renaming of what was originally called abs_rshares. These are the absolute rshares currently on the comment from votes. It also adds an invariant check we can do for a comment. The sum of the rshares for all comment vote objects associated with the object must add to current_abs_rshares. Since we also have the vote weight, we can do signed math to also check against net_shares. (Note: The second check can be added now, regardless of future changes)
• total_abs_rshares: What is currently implemented, but is not the original design for absolute rshares. These are the total absolute rshares given to a post for this cashout period.