Project Information
Repository: https://github.com/steemit/steem
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.
https://github.com/steemit/steem/issues/2428
It was mentioned by steemitblog @steemitblog ("Fix for Double Voting Exploits" - post)
My Github account
https://github.com/ravau , verified previously in my first @utopian-io contribution: link
Thank you for contributing to Utopian!
This is an outstanding post. A highly details report, covering the bug from detection, through possible solutions and it was implemented in HF20. In my opinions, exploits are the 1st priority bugs for any product. This is obviously even more critical in projects such as steem, which are essentially banks. It's fun reading the report, and a real joy to review it. But even as an overjoyed spectator, I couldn't help but notice this:
Please refrain from such language in the future. Reading issues in github shouldn't trigger anyone. With that said, I'll be counting the seconds till your next contribution. What a ride this report was. Awesome sauce dude.
Your contribution has been evaluated according to Utopian policies and guidelines, as well as a predefined set of questions pertaining to the category.
To view those questions and the relevant answers related to your post, click here.
Need help? Write a ticket on https://support.utopian.io/.
Chat with us on Discord.
[utopian-moderator]
Thank you for kind words.
The title in the github issue.. I'm not sure if I remember clearly what word I've used, but I can imagine which it was. Sorry for that. Because english is not my first language I forgot that this word is kind of disturbing.
I'm very interested in math so if I find more issues I will report them for sure :)
Hi @achiron,
may I know the reason why this was approved? As you said the bug is already fixed. This implied the developers already knew about it. So am I allowed to report bugs which are already fixed?
Kind regards
The Secret Service
@secret.service, if you read the github issue and the HF20 post you will see that they fixed it because he reported it. He made it happen.
Hi @archion,
Ok. I see. But the issue was created in May and closed in June. Can I report bugs even if they are older than 14 days and already fixed?
Kind regards
The Secret Service
Well, I didn't report the issue faster to utopian because I thought it is dangerous to tell publicly about this exploit. But then I saw steemitblog already published the info so I decided I can do it to.
Hi,
I fully understand your point but this does not answer my question from above. Can I report bugs which were closed months before?
Kind regards,
The Secret Service
Pretty sure the 14 day rule doesn't apply to bug fixes. As long as the application is on the latest version then it is acceptable. I went and reviewed the guidelines because I also was confused on this point. Though that raises the question of whether or not someone can just report a bug from an application that hasn't been updated in months.
Hey @achiron
Here's a tip for your valuable feedback! @Utopian-io loves and incentivises informative comments.
Contributing on Utopian
Learn how to contribute on our website.
Want to chat? Join us on Discord https://discord.gg/h52nFrV.
Vote for Utopian Witness!
Hey @rafalski
Thanks for contributing on Utopian.
Congratulations! Your contribution was Staff Picked to receive a maximum vote for the bug-hunting category on Utopian for being of significant value to the project and the open source community.
We’re already looking forward to your next contribution!
Want to chat? Join us on Discord https://discord.gg/h52nFrV.
Vote for Utopian Witness!
Thanks so much for you work