Steem [HF19] Possible reward pool gaming by cycling delegations

Project Information

Project Name: Steem
Publisher: Steemit Inc.

My contribution concerns Steem vulnerability I found when analysing delegation mechanism, which allows to get even 43% more reward from the same Steem Power amount.

Expected behaviour

There should be no profit in additional reward (by upvotes) when cycling delegations to one or more users related to Voting Power fill from 0% to 100% (voting_regen_period).

Steem blockchain should preserve:
2 * voting_regen_period == delegation_return_period

Now, the voting_regen_period is 5 days and delegation_return_period is 7 days.

Actual Behaviour

User can gain more rewards in upvotes because equation mentioned before is not equal to:
2 * 5 != 7

User A can use all VP for his posts, then he delegates all the power to other user called B. Lets assume that voting happens instantly. User B at delegation arrival has 100% VP although user A used already all this power. User B votes for the posts to deploy all VP to 0%. Now User A undelegates the Steem Power. The SP will return in 7 days, VP will be already regenerated (5 days) nad user A can again deploy all VP and repeat.

Using this trick two accounts working together can gain up to 3days/7days = 0,43 more Steem Power than real SP locked in the account!

How to reproduce

It is possible to use this exploit with instructions written above on current running (Hard Fork 19) version of Steem. Actual SP gain will be lower than 43% because of time needed to perform actions by the users.

Proposed solutions

In the opened issue I proposed to average the VP of user we delegate to in the moment of delegation with VP of user making delegation. However, this solution may be problematic because we can imagine VP "bombing" when Big SP user with VP0% delegates to user with small SP and averages his/her SP almost to 0%

@vandeberg proposed simplier solution:
Let's change delegation_return_period to 10 days which is equal to 2 x voting_regen_period.

However another issue was referenced (2539 ) and final fix introduced by @steemitblog proposes mechanism called Voting Mana, which prevents this exploit and even reduces delegation_return_period to 5 days (simply if you have 50% Mana you can delegate 50% of your SP).

Proof of work

The issue was reported by me on Github and was acknowledged, resolved and planned to fix in Steem HF20.

It was mentioned by steemitblog @steemitblog ("Fix for Double Voting Exploits" - post)

My Github account , verified previously in my first @utopian-io contribution: link