Increase STEEMIT_UPVOTE_LOCKOUT at HF17

[abitmore]

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]

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]

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]

@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]

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]

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]

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 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]

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

[mvandeberg]

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]

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

[roadscape]

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]

KISS

[pfunks]

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]

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]

@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]

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 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]

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]

Usurped by #983