New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Increase STEEMIT_UPVOTE_LOCKOUT at HF17 #900

Closed
abitmore opened this Issue Mar 4, 2017 · 19 comments

Comments

Projects
None yet
8 participants
@abitmore
Contributor

abitmore commented Mar 4, 2017

Because the payout time is fixed after HF17, it's possible that some people will upvote posts just before the payout time, which could be abusing. STEEMIT_UPVOTE_LOCKOUT is currently 1 minute, which means others have little chance to find that kind of abusing or downvote accordingly.

Here I propose we increase STEEMIT_UPVOTE_LOCKOUT to 1 day or so, during that period people can still upvote and downvote, but only downvotes take effect, let the upvotes be no-op.

@abitmore

This comment has been minimized.

Show comment
Hide comment
@abitmore

abitmore Mar 4, 2017

Contributor

During the lockout period, cancelling an upvote should be allowed, but cancelling a downvote or change it to a smaller weight should be disallowed.

Contributor

abitmore commented Mar 4, 2017

During the lockout period, cancelling an upvote should be allowed, but cancelling a downvote or change it to a smaller weight should be disallowed.

@TimCliff

This comment has been minimized.

Show comment
Hide comment
@TimCliff

TimCliff Mar 5, 2017

Contributor

It is not as likely, but people could abuse the downvote option in a similar way. If there are posts that are (subjectively) deserving of rewards and have a lot of upvotes, a whale could come in right at the end and take them away without giving other people in the community a chance to vote them back up.

Contributor

TimCliff commented Mar 5, 2017

It is not as likely, but people could abuse the downvote option in a similar way. If there are posts that are (subjectively) deserving of rewards and have a lot of upvotes, a whale could come in right at the end and take them away without giving other people in the community a chance to vote them back up.

@abitmore

This comment has been minimized.

Show comment
Hide comment
@abitmore

abitmore Mar 6, 2017

Contributor

@TimCliff that's exactly the philosophy behind the design of lockout period -- people can downvote but not upvote during the period. It's coded. Downvoting is less an issue than upvoting because it's not self-beneficial.

Contributor

abitmore commented Mar 6, 2017

@TimCliff that's exactly the philosophy behind the design of lockout period -- people can downvote but not upvote during the period. It's coded. Downvoting is less an issue than upvoting because it's not self-beneficial.

@mvandeberg

This comment has been minimized.

Show comment
Hide comment
@mvandeberg

mvandeberg Mar 6, 2017

Contributor

I would be in favor of changing this to 5 or 30 minutes? Somewhere in that range. The 7 day payout was chosen because 99%+ of votes on content happen in the first 7 days. There are a couple percentage points that happen between day 6 and 7. I don't want to cut into that time too much. This lockout time should be the minimal amount of time needed to moderate pending payouts. We had intended this to be just long enough for bots to moderate and then have the comment get paid. There is an API get_discussions_by_cashout that returns the order of payouts about to occur.

Contributor

mvandeberg commented Mar 6, 2017

I would be in favor of changing this to 5 or 30 minutes? Somewhere in that range. The 7 day payout was chosen because 99%+ of votes on content happen in the first 7 days. There are a couple percentage points that happen between day 6 and 7. I don't want to cut into that time too much. This lockout time should be the minimal amount of time needed to moderate pending payouts. We had intended this to be just long enough for bots to moderate and then have the comment get paid. There is an API get_discussions_by_cashout that returns the order of payouts about to occur.

@abitmore

This comment has been minimized.

Show comment
Hide comment
@abitmore

abitmore Mar 6, 2017

Contributor

A fact is currently there is no bot moderator nor public tool available nor high-SP account for moderation, but all manually. With pre HF17 It's not so easy to exploit, because payout time will extend so usually gives one more day to moderate.

Contributor

abitmore commented Mar 6, 2017

A fact is currently there is no bot moderator nor public tool available nor high-SP account for moderation, but all manually. With pre HF17 It's not so easy to exploit, because payout time will extend so usually gives one more day to moderate.

@roadscape

This comment has been minimized.

Show comment
Hide comment
@roadscape

roadscape Mar 10, 2017

Contributor

IMO the lockout period should be a linearly ramping restriction on rshares granted from a vote.. e.g. from 0% to 100% over the last 30mins on a post. It should affect downvotes and upvotes the same.

Contributor

roadscape commented Mar 10, 2017

IMO the lockout period should be a linearly ramping restriction on rshares granted from a vote.. e.g. from 0% to 100% over the last 30mins on a post. It should affect downvotes and upvotes the same.

@mvandeberg

This comment has been minimized.

Show comment
Hide comment
@mvandeberg

mvandeberg Mar 10, 2017

Contributor

This doesn't fully fix the problem. If I upvote my own post at 30 minutes, then you need exponentially (faster actually) increasing stake to counter my vote for every block that passes.

Contributor

mvandeberg commented Mar 10, 2017

This doesn't fully fix the problem. If I upvote my own post at 30 minutes, then you need exponentially (faster actually) increasing stake to counter my vote for every block that passes.

@roadscape

This comment has been minimized.

Show comment
Hide comment
@roadscape

roadscape Mar 10, 2017

Contributor

True... it would work much better without n^2.

Contributor

roadscape commented Mar 10, 2017

True... it would work much better without n^2.

@mvandeberg

This comment has been minimized.

Show comment
Hide comment
@mvandeberg

mvandeberg Mar 10, 2017

Contributor

It has nothing to do with the curve.

If I upvote with 100 M rshares and at 30 min left and you counter at 15 min left, you need 200 M rshares. At 7.5 min left you need 400 M rshares.

Contributor

mvandeberg commented Mar 10, 2017

It has nothing to do with the curve.

If I upvote with 100 M rshares and at 30 min left and you counter at 15 min left, you need 200 M rshares. At 7.5 min left you need 400 M rshares.

@mvandeberg

This comment has been minimized.

Show comment
Hide comment
@mvandeberg

mvandeberg Mar 10, 2017

Contributor

The number of rshares is independent of curve. The curve determines the impact of rshare concentration.

Contributor

mvandeberg commented Mar 10, 2017

The number of rshares is independent of curve. The curve determines the impact of rshare concentration.

@roadscape

This comment has been minimized.

Show comment
Hide comment
@roadscape

roadscape Mar 10, 2017

Contributor

If I upvote with 100 M rshares and at 30 min left and you counter at 15 min left, you need 200 M rshares. At 7.5 min left you need 400 M rshares.

That sounds linear to me, what did you mean by "you need exponentially (faster actually) increasing stake"?

If 30 mins produces too steep of a slope, then you could ramp it over, say, 5hrs. You would then have 1hr to counter a vote with less than 20% rshare loss.

Contributor

roadscape commented Mar 10, 2017

If I upvote with 100 M rshares and at 30 min left and you counter at 15 min left, you need 200 M rshares. At 7.5 min left you need 400 M rshares.

That sounds linear to me, what did you mean by "you need exponentially (faster actually) increasing stake"?

If 30 mins produces too steep of a slope, then you could ramp it over, say, 5hrs. You would then have 1hr to counter a vote with less than 20% rshare loss.

@abitmore

This comment has been minimized.

Show comment
Hide comment
@abitmore

abitmore Mar 10, 2017

Contributor

KISS

Contributor

abitmore commented Mar 10, 2017

KISS

@pfunks

This comment has been minimized.

Show comment
Hide comment
@pfunks

pfunks Mar 12, 2017

From the white paper:

Delayed Payouts

To further prevent abuse, all payouts are delayed a stake-weighted average of 24 hours from the time each vote was cast. This ensures that large stakeholders cannot snipe payouts by voting at the last second before other voters (aka crabs) have a chance to negate the potential abuse.

If the original logic is sound, 30 minutes vs. 1 minute is barely any change. I'm not sure if abit's proposal of a full day is too much or not, but somewhere in the range of 6-24 hours would make a whole lot more sense if vote sniping is a concern.

pfunks commented Mar 12, 2017

From the white paper:

Delayed Payouts

To further prevent abuse, all payouts are delayed a stake-weighted average of 24 hours from the time each vote was cast. This ensures that large stakeholders cannot snipe payouts by voting at the last second before other voters (aka crabs) have a chance to negate the potential abuse.

If the original logic is sound, 30 minutes vs. 1 minute is barely any change. I'm not sure if abit's proposal of a full day is too much or not, but somewhere in the range of 6-24 hours would make a whole lot more sense if vote sniping is a concern.

@TimCliff

This comment has been minimized.

Show comment
Hide comment
@TimCliff

TimCliff Mar 17, 2017

Contributor

One alternative to consider would be to have a fixed 7 day payout window, but on the last day - reduce the amount of rshares that can be added to the post, until it reaches 0 at the end of the day. Basically prevent any major movement at the end of the last day.

Contributor

TimCliff commented Mar 17, 2017

One alternative to consider would be to have a fixed 7 day payout window, but on the last day - reduce the amount of rshares that can be added to the post, until it reaches 0 at the end of the day. Basically prevent any major movement at the end of the last day.

@iamsmooth

This comment has been minimized.

Show comment
Hide comment
@iamsmooth

iamsmooth Mar 17, 2017

@mvandeberg "Somewhere in that range. The 7 day payout was chosen because 99%+ of votes on content happen in the first 7 days. There are a couple percentage points that happen between day 6 and 7. "

I'm sorry but this reasoning is nonsense, especially when you start to get into a precision of a couple of percentage points. People adapt to the rules and there is no way whatsoever that behavior is going to be anywhere remotely the same between a single 7 day payout period and 6 days into a 30 day payout period (with no virtually no visibility on the posts in the 30-day window) that follows a 24 hours period. It is completely different.

As I said, I think people will adapt to whatever reasonable rules are applied. I think a one-day review period of only allowing down votes or of gradually locking influence in both directions (more stake weight required to apply a given rshares, up or down, to the comment) would be fine.

I think it would also be fine to keep the keep the current logic on extending the payout given new activity (as quoted above from the white paper), unless there is some really good reason that causes significant problems in the implementation (not sure why that would be, and it has never been explained).

iamsmooth commented Mar 17, 2017

@mvandeberg "Somewhere in that range. The 7 day payout was chosen because 99%+ of votes on content happen in the first 7 days. There are a couple percentage points that happen between day 6 and 7. "

I'm sorry but this reasoning is nonsense, especially when you start to get into a precision of a couple of percentage points. People adapt to the rules and there is no way whatsoever that behavior is going to be anywhere remotely the same between a single 7 day payout period and 6 days into a 30 day payout period (with no virtually no visibility on the posts in the 30-day window) that follows a 24 hours period. It is completely different.

As I said, I think people will adapt to whatever reasonable rules are applied. I think a one-day review period of only allowing down votes or of gradually locking influence in both directions (more stake weight required to apply a given rshares, up or down, to the comment) would be fine.

I think it would also be fine to keep the keep the current logic on extending the payout given new activity (as quoted above from the white paper), unless there is some really good reason that causes significant problems in the implementation (not sure why that would be, and it has never been explained).

@inertia186

This comment has been minimized.

Show comment
Hide comment
@inertia186

inertia186 Mar 17, 2017

Currently, we have upvotes coming in during the 30-day (second-payout) that can go unnoticed.

What we don't know is if the 7-day upvote will be worse than what we currently have.

inertia186 commented Mar 17, 2017

Currently, we have upvotes coming in during the 30-day (second-payout) that can go unnoticed.

What we don't know is if the 7-day upvote will be worse than what we currently have.

@mvandeberg

This comment has been minimized.

Show comment
Hide comment
@mvandeberg

mvandeberg Mar 17, 2017

Contributor

This is primarily because of how that content was displayed and the fact that it isn't at all right now. I have only ever checked trending30 out of curiosity about what was being voted on, not because I was looking for anything to read. We are going to add a display to view content by pending payout, so it will be much easier to moderate payouts.

Contributor

mvandeberg commented Mar 17, 2017

This is primarily because of how that content was displayed and the fact that it isn't at all right now. I have only ever checked trending30 out of curiosity about what was being voted on, not because I was looking for anything to read. We are going to add a display to view content by pending payout, so it will be much easier to moderate payouts.

@tibonova

This comment has been minimized.

Show comment
Hide comment
@tibonova

tibonova Mar 17, 2017

I agree with the weekly payouts, but Steem needs wider protection than the proposed one.

@abitmore has written that the lock-up period is a downvote only period. If that's the case, I support @pfunks version, we should let the users decide if something is unworthy for them. For this, we need at least 6-8 hours, but I would better like half day. Don't forget that we need to provide an option to everyone to make a vote comfortably. Steem isn't only about whales, investors, but users with 40SP. If you close them out from things, because it's the 'whales' game', then the whole platform will be their game one day. Purely.

@mvandeberg has written about upvotes and downwotes, too. In this case, I'd support @TimCliff's version, where the last day the effective voting weight would slowly decrease. This one would make the 'exponentially increasing voting stakes required' problem less a problem, because there aren't 15 minutes between the doubled voting stakes requirements, but, assuming that the first user has voted in the first seconds, 12 hours difference.
As an extra, this option would also reduce the volatility in the last hours giving the users better experience (many users feel cheated because of huge last minute drops in payout.)

tibonova commented Mar 17, 2017

I agree with the weekly payouts, but Steem needs wider protection than the proposed one.

@abitmore has written that the lock-up period is a downvote only period. If that's the case, I support @pfunks version, we should let the users decide if something is unworthy for them. For this, we need at least 6-8 hours, but I would better like half day. Don't forget that we need to provide an option to everyone to make a vote comfortably. Steem isn't only about whales, investors, but users with 40SP. If you close them out from things, because it's the 'whales' game', then the whole platform will be their game one day. Purely.

@mvandeberg has written about upvotes and downwotes, too. In this case, I'd support @TimCliff's version, where the last day the effective voting weight would slowly decrease. This one would make the 'exponentially increasing voting stakes required' problem less a problem, because there aren't 15 minutes between the doubled voting stakes requirements, but, assuming that the first user has voted in the first seconds, 12 hours difference.
As an extra, this option would also reduce the volatility in the last hours giving the users better experience (many users feel cheated because of huge last minute drops in payout.)

@mvandeberg

This comment has been minimized.

Show comment
Hide comment
@mvandeberg

mvandeberg Mar 28, 2017

Contributor

Usurped by #983

Contributor

mvandeberg commented Mar 28, 2017

Usurped by #983

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment