Why cool-down for undelegation should be ten days (not seven)
First let me start off with the disclaimer that my knowledge on this stems from other blog posts like this one by @gadrian that might just be parroting old info that might already have been fixed, so if the seven-day cool-down loophole has already been fixed, excuse my ignorance. If not, I hope the below post might be read by witnesses and/or developers so this loophole might get fixed.
When you delegate steem power to an other account, that steem power will add to the voting strength of the account being delegated to for the duration of the delegation. When, you no longer want to maintain the delegation, you undelegate the steem power. You won't imediately get your SP back when it is undelegated, there is a cool-down period of seven days in which neither you not the person you delegated to will get to use your voting strength to vote with.
This seven day period makes sense, but it seems instead of seven days, the proper cool down period should actually be ten days in order to prevent short-lived delegation being used as a voting amplifier.
Let's show what I mean. Let's say you are Bob1 and you have a little over 7000 SP at your disposal to vote with. You want to maximize the amount of voting strenght your 7000 SP gets you. So what do you do? You create eleven additional accounts, The accounts Bob2...Bob7 and the accounts Alice1...Alice5.
The Alice1...Alice5 accounts get a minimum amount of their own SP, but the Bob1...Bob7 accounts each end up with 1000 SP to their name. Now, every day on a 35 day rotation, we pair up a Bob account with an Alice account as follows:
- Bob1/Alice1
- Bob4/Alice4
- Bob7/Alice2
- Bob3/Alice5
- Bob6/Alice3
- Bob2/Alice1
- Bob5/Alice4
- Bob1/Alice2
- Bob4/Alice5
- Bob7/Alice3
- Bob3/Alice1
- Bob6/Alice4
- Bob2/Alice2
- Bob5/Alice5
- Bob1/Alice3
- Bob4/Alice1
- Bob7/Alice4
- Bob3/Alice2
- Bob6/Alice5
- Bob2/Alice3
- Bob5/Alice1
- Bob1/Alice4
- Bob4/Alice2
- Bob7/Alice5
- Bob3/Alice3
- Bob6/Alice1
- Bob2/Alice4
- Bob5/Alice2
- Bob1/Alice5*
- Bob4/Alice3
- Bob7/Alice1
- Bob3/Alice4
- Bob6/Alice2
- Bob2/Alice5
- Bob5/Alice3
Now what bob does on each such combination is the following:
- The BobX account exhausts all of his voting strength down to (almost) 0%
- The BobX account delegates 1000 SP to the AliceY account.
- The AliceY account exhausts al of her voting strength down to (almost) 0%
- The BobX account undelegates the 1000 SP, starting off the seven day cool-down period.
After this action the BobX account won't be able to do anything at all untill after the 7 day cool-down period when it has its SP returned. The AliceY account will need 5 days to have its voting stenght returned to 100%. So basically for both accounts this action will be the only voting they would ever do. So let us compare the total voting capacity for two scenarios:
- Bob1 as one 7000 SP account using up the optimum of 20% of his voting strength each day.
- The 12 account short-lived delegation strategy.
In the first scenario, 7000 times 20% would equate 1400. In contrast, in the second scenario, 1000 times 200% would add up to 2000. A 42% higher cumulative effective voting strength through the use of short-lived delegations. So how long should the cool-down period be to prevent this, arguably abusive, scenario? Well, the answer is verry simple. As it takes five days to restore voting strenght from fully depleted back to 100%, and given the fact that double voting from the same SP is what got us this problem, ten is the magic number. Change the cool-down period from seven days to ten days, and our Bob would have no reason left to try and game the system with the 12 account strategy described above.
I hope that if the cool-down period is still set to seven days today, that this post shows how a seven day cool-down should be considered a bug and a vulnerability that should get fixed. It appears that we need a cool-down on delegation of at least 10 days to avoid abuse.
Interesting study, but I'm not fully convinced by the numbers. Calculating in SP and % seems not fully correct to me.
A 100% vote at 100% VP with X SP makes Y rshares. The maximum a single account could "get out" per day would be 10x Y rshares. A 100% vote at 50% VP with X SP makes roughly Y/2 rshares. How many rshares can an account get out from exhausting the VP to (close to) 0? Taking this into consideration, is it really profitable to move the SP around with delegations/undelegations?
The fun thing is that a vote at 50% makes only 50% the rshares but at that point only reduces the remaining voting strength by 1%, not 2%. The rshares per delta voting strength is quite constant. It just takes increasingly more votes to get the remaining strength down further. 60 votes would be the 30% break even point between scenarios. 114 votes to get down to 10%, 228 votes to reach 1%.
Indeed, good point!
I did the rshare math for my own account:
A 100% vote at 100% VP for my account (~1100SP) makes ~46bn rshares per vote, 10 of those per day for 7 days make ~3187 bn rshares. Draining my VP from 100% to 1% once makes ~2254 bn rshares in total. If I'd delegate my SP to another account right after that I could give out another ~2.2 tn rshares with the second account, making ~4.5 tn rshares in total. That's roughly the +42% you got with your calculation as well. Sorry for my non-believing :)
But this even get's along with two accounts?! Why do you need the other 11 accounts in your model?
Damn, indeed, you are right! The two account, One Bob and one Alice, model is simpler. I came to seven Bobs and 5 Alices because Bob would be on cool-down for seven days (and won't be usable again before that), while Alice would be at full VS and ready for a new delegation in only five days. I now realize that Alice being idle for two days doesn't change anything.
Ah, now I get why you went for 12 accounts! But, yeah, reward wise it doesn't make a difference if it's 2 or 12.
Good point to also take into account the fact that voting power reduces less and less with each vote.
Yeah .that is a wonderful calculation. .me too think 10 days is optimum nothing more nothing less
There's a reason why voting power should not be depleted (and it's not because of the waiting period to get it to full power again). The reason is that the lower the VP is, the less your vote is worth.
The 7-day cooldown period is long enough to prevent double-voting.
That only changes the amount of votes needed to come close to zero. And yes, at a point, the rshares for a vote might drop to zero before voting strength is at zero, but for 7 days with the above scenario that would need to be round and about the 30% mark. Seven days seems very much insufficient and the higher the amount of SP involved is, the less sufficient it becomes.
I'm still not convinced by your calculations, but... let's assume they are almost correct.
Delegations are used by the large majority of steemians with enough SP to afford delegating.
If your scenario is correct (with a lower profit margin than you calculated for full voting power), we can assume very few might attempt to use it, if any.
Should Steem change a setting that would affect many to combat a few, at most? Since it's not a critical issue, there should be real evidence of such a scenario occurring and the amount of influence it exerts to the rewards pool, in my opinion.
A partially valid assertion I think. I think the recent history with bid bots run by powerful whales has shown us that it becomes pretty much impossible to 'change the rules mid-game' so to speak 'after' whales have adjusted their business model to the old rules. Now think of bid bot owners. Once bidbot owners discover the edge a strategy like this could give their money making machine, it will basically be to late to fix the problem. Once it has become part of their business model, the flaw becomes edged into the platform for eternity. Things like these should get fixed BEFORE they end up in Whale business models. Fixing them afterward is a nice thought, but we all know that it is unwise to provoke the wrath of the more capricious of whales.
Such changes on the blockchain are made in consensus. And solid reasons for them need to be provided to be accepted.
Added an issue on github. Hope they'll bring it up for a vote.
Did you see this?
https://steemit.com/steem/@steemitblog/blockchain-update-3-hardfork-20-and-release-19-4-appbase-statsd-and-rocksdb
Does it solve the issues you found?
Were any of your proposals implemented?
What was implemented was something adhering to the sum of products requirement identified here. And yes, it should fix both issues looking at it supperficcially.
I don't really feel like looking into it deeply. There are people, stake holders, who don't have the best interest of the platform in mind whispering in the ear of people like me and given my blog post I linked from my vulnerability report made less than 20 cents, I prefer not to put myself in a position where I might choose to do something against the platform's best interest. Looking more deeply into the solution might put me into such a position. Hope I'm making sense.
You got a 50.00% upvote from @luckyvotes courtesy of @stimialiti!
You got a 60.00% upvote from @sleeplesswhale courtesy of @stimialiti!
This comment has received a 83.33 % upvote from @steemdiffuser thanks to: @stimialiti.
Bids above 0.1 SBD may get additional upvotes from our trail members.
Get Upvotes, Join Our Trail, or Delegate Some SP
You got upvoted from @adriatik bot! Thank you to you for using our service. We really hope this will hope to promote your quality content!
You got a 61.54% upvote from @proffit courtesy of @stimialiti!
2-25% Return on investment. Check steembottracker.com for current status
Minimum 0.01 SBD/STEEM to get upvote , Minimum 1 SBD/STEEM to get upvote + resteem
That's a good step to take. I like that you don't leave things unfinished.