Steem: Possible reward pool gaming by cycling delegations

[ravau]

1) It is easier to explain the bug by showing you my "mindstorm" drawing:

image

2) If you can't read what I've shown on image:

There is possibility to take advantage of reward pool almost by x2 of somebody's SP.

User A delegates to B
After delegations VPb should be averaged by VPa% and SP accordingly, because delegation can be undone immediately, and VP can be used down to 0 very fast before that.

If you use all your VP in few minutes or voting every day only 10 times 100% - it doesnt matter, the sum is the same.

Because of that You can:

• user A vote all power
• delegate to user B all the sp
• user B vote all power as fast as he can (!)
• undelegate to user B
• wait 7 days (in this timeline, VP recovers in 5 days also)
• repeat!

Outcome:
In about 8 days (simplifing: 7 days) two users USED 100% vp power so used 200% power of some amount of SP.

Taking math into consideration thye shouldn be allowed to do that in such time, it should take them 14 days.

Solutions:

not ideal (you can bomb small user with VP0% to mute ;) ):

• average the VP of user B in the moment of delegation with VP of A

not very handy:

• add 7 days lock period to undelegate function (actually Im not sure it changes anything, need to make math)

https://steemit.com/@rafalski

[TimCliff]

In the scenario you described, there is a short term burst of higher voting power, but then there is 7 days after that where the user cannot vote with the delegated SP at all.

[ravau]

What time period of 7 you mean? When delegation comes back? Yes I know - you can't vote during this, BUT look carefully, that's not the problem I'm addressing :)

Both times when users spend their votes they have full "rights" to do it

1. A because it is his sp before delegating
2. B because he just got delegation

Do you mean that after delegating A-B, user B has no VP from user A (who spent it on votes)?

[r351574nc3]

@ravau I think @TimCliff is referring to the 7-day period after undelegating where the SP is unusable. When a user undelegates, the delegated SP is not immediately returned. In this 7-day period, the SP is unavailable to the delegator and the delegatee. Therefore, the original delegator cannot abuse delegation because of the 7-day waiting period.

[ravau]

Ok, so this is not the problem i'm addressing. Please look carefully at the chart/timeline I have drawn - all the abuse take place in "legitimate" time when SP is available.

[r351574nc3]

The time when the SP is unavailable negates it is the point. No matter how much a person can make from sharing the SP, the 7-day period while this SP is unavailable makes it more loss than gain.

1. User A with 100,010 SP upvotes until VP is depleted
2. User A delegates 100,000 SP to User B
3. User B upvotes until VP is depleted
4. User A undelegates
5. User A and User B for the next 7 days have only 10 SP each. This is fine because it takes 5 days to recover SP; however, that's 2 days of content where users cannot vote. 2 days is equivalent to 40% voting power which is essentially lost. This lost VP devalues the scam such that it's not profitable to do.

[ravau]

Fully agree, but nr 5. is not my concern, look at your point 1. and point 3.

Two users are able to use 2x 100,000 SP in 7 + (time needed for voting lets say 1 day) = 8 days

(I mean voting anly happens 1 day or less (boting), very fast to get in <10 days (2x5) window with delegation freeze)

If they work alone, they manage only to vote this amount once per 5 days.

So basically they can in 7+some, lets say 8 days use votes designed for 10 days (2x5 days alone)!

[mvandeberg]

For simplicity, let's assume the initial voting period, delegation, and voting happens instantly.

You have 100,000 SP that just voted twice for a total effect of 200,000 SP.

The first account cancels the delegation, which will return in a week.

If the 100,000 SP was split evenly between the two accounts instead of delegated, they would have been able to each vote with 70,000 SP each (the 100% voting power plus the 40% regenerated) for a total of 140,000 SP. In fact, it doesn't matter how the SP is split, this is the result and this property is a good thing.

However, the delegation trick does let the accounts vote with 42.857% more SP than they would otherwise, which is still a significant gain.

The invariant that we need to preserve is the following: 2 * voting_regen_period == delegation_return_period. This is currently not preserved as 10 != 7. We need to tweak one or both of voting_regen_period and delegation_return_period.

I think the voting_regen_period of 5 days works well and would recommend increasing the delegation_return_period to 10 days.

[foragerDev]

you mean to say that A User A currently has steem Power that First uses 100% of Power and then Delegate that Power to the User B And He also Can use 100% of Power But the user A has already used that Power.

[r351574nc3]

@programmer0073 There's Steem Power (SP) and Voting Power (VP). The 100% being referred to is the VP and the power being delegated is the SP. SP doesn't get used up. The VP gets used up by voting. The idea is that if there are 2 users, one can use up all its VP, then delegate its SP to another user to use up its VP before undelegating. It takes 5 days to recover VP, but only 7 days to recover SP. This means that if a person has 2 accounts, they can effectively take advantage of SP twice by delegating between accounts.

I didn't believe it at first, but the math works. The trick is in the delegation period being < 2 x voting recovery period.

[lopugit]

Still being able to vote with 45% more power at any time than you have isn't a very good thing

[pibara]

I would like to propose this issue be reopened and the patch be reverted. https://github.com/steemit/steem/issues/2539 shows an other scenario resulting from the same vulnerability that isn't fixed by the current patch.

The solution needed to prevent double voting vulnerabilities would lie in the assurance that operations such as powering down and delegating have a neutral effect on the sum of products of SP and VS for involved parties. See also the blog post linked in the issue above.

I propose the current patch be reverted, this bug be reopened and this bug and https://github.com/steemit/steem/issues/2539 be merged as instances of violation essentially the same idiom.