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:

1. Bob1 as one 7000 SP account using up the optimum of 20% of his voting strength each day.
2. 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.