Earlier I wrote about a 42% double voting vulnerability in STEEM, and suggested a solution: Upping the cool down period for udelegation from seven to ten days.
But now, after figuring out a second, smaller, double voting vulnerability, I've come to the conclusion that, not only is the 10 day cool down period not addressing the underlying issue that happens to be shared between vulnerabilities, but we could go as far as to say that fixing the underlying problem should take away the need to have any cool down period for undelegation at all.
Before though we look at the underlying problem and how it could potentially be solved, we need to discuss the power down double voting vulnerability.
Double voting vulnerability in power down and transfer
Imagine the following scenario:
- Alice has 13,000 STEEM power, Bob has none.
- Alice does a full power down
- Just before the weekly power down, Alice does a few hundred votes so at the moment of power down her voting strength is down below 1%. *On day 1..5 Alice lets her voting strength recover, after that she votes whenever her voting strength reaches 100%
- Bob only ever votes at 100% of VS
So what happens here. Every week there is an amount of 1,000 SP that gets transformed from having 1% effective voting strength in Alice her possession, to having 100% effective voting strength once transferred to Bob. Or looking at it differently, 1,000 SP weekly gets a five day boost in voting strength recovery. This last way of looking at it is usefull as it allows us to calculate the size of the double voting problem for this scenario.
One 13th of the total SP involved gets 5 days worth of spurious recovery one 7th of all days. So we get roughly 1005/(137) is about 5.5% worth of double voting if we were able to go all the way to 0%. 5% though would probably be more realistic.
This double voting vulnerability is far removed from the 42% gaping hole double voting vulnerability that we talked about last time, but the underlying problem is the same. Something we shall discuss next.
Sum of products for SP and VS
A core property of both vulnerabilities seems be the fact that somehow the sum of products for SP and VS is able to go up, either in one transaction (delegation) or in two/three (power down plus transfer plus power up).
I believe looking at operations and events in terms of the sum of products of SP and VS holds the key to both identifying and solving double voting vulnerabilities. I want to propose the following rule should apply to any attomic event, be it a power down event, a delegation transaction or any other attomic event for that matter:
NO attomic event or collection of attomic events between one ore more accounts MUST be allowed to increase the sum of products for SP and VS for those accounts
If we look at both the delegation scenario from my previous post and at the power down, we see that somewhere this rule is broken. So how can we fix things into not allowing this rule to be broken.
One thing we want to avoid is having to look at consecutive operations that together break the rule. I propose one axiom and two practical solutions to reach a situation where no collection of operation could ever break the rule.
Axiom: STEEM equates SP at 100% SP
If we equate STEEM to SP at 100% SP, we can apply the sum of products rule to a power down event. This however might stop a power down event, especially those at the end of a power down series, from being possible. A property that is likely undesirable. Not however if we take a pragmatic approach to ensuring the sum of products rule is never violated. I propose the following pragmatic solution components:
1) In order to maintain the sum of products rule, the VS value may be set to a negative value. 2) In order to maintain the sum of products rule, a token amount of SP can be kept in power up.
The sum of products for SP and VS SHOULD be constant for before mentioned operations
If we want the system to not only prevent vulnerabilities, but to be fair as well, we should attempt to make it two directional. That is, next to saying the sum of product MUST not increase, we also say the sum of products SHOULD not decrease.
Back to power down, first power down
Let us look at our power down scenario. What would be needed to make the first power down follow the above rules and solutions? Well, the core problem here is the power down operation. We want the sum of products to be constant. There is only one account involved in this operation, and as we have declared STEEM equal to SP at 100%, we start off with the following equation:
12,000 x VS2 + 1,000 x 100 = 13,000 x 1
This can be rewritten as:
VS2 = (13,000 - 100,000)/12,000
Resulting in a negative VS of -7.25. For voting purposes, of cause this should effectively equate zero, but that goes without saying.
Here, the negative VS is enough to fix the problem.
The final power down
At the final power down is where a token SP value needs to come in. We can't allow the SP to drop all the way to zero. We could however allow it to drop to just one STEEM.
1 * VS2 + 1,000 * 100 = 1,000 * 1
Results in:
** VS = - 99,000 **
Delegation
In the delegation scenario, we have more degrees of freedom, but the fundamentals are the same. Let's illustrate with an example.
- Alice has 10,000 SP. When her VS is at 20% she decides to delegate 5,000 SP to Bob who at that time has 2,000 SP and has 80% VS.
This means that:
5,000 VSa + 7,000 VSb = 10,000 * 20 + 2,000 * 80
Or
VSa = 72 - 7 VSb / 5
There are a lot of possible strategies to choose the best value for VSb and VSa and make this fit. The important point however is, it should be possible to make it fit, and as long as the equation above is honoured, the result might not be fair to Bob or Alice, it will be fair to the rest of STEEM.
Undelegation cool down
Now for the shocker. Where we started out advocating the undelegation cool down period should be moved up from seven days to ten days, when we apply the sum of products rule and introduce the solutions needed to make equity possible, the whole need for a cool down period disappears all together. That is, fixing the sum of products problem not only removes all double voting vulnerabilities from the STEEM ecosystem, it also obsoletes the concept of an undelegation cool down.
I truly hope the above analysis of the foundational issues underlying double voting vulnerabilities in the STEEM ecosystem can contribute to fixes that combine into a more ideomatic solution, rather than the duct tape solutions that I now believe the ten day cool down to be.