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:
- In order to maintain the sum of products rule, the VS value may be set to a negative value.
- 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.
What do you think about solving the premining issue by starting a platform almost identical to Steem, without an image (no duplication of history, start from nothing) where everyone starts from some equal to all initial value, and the rules (code) will be similar to Steem initially?
Don't have any thoughts on any such issue at the moment. But if you or anyone starts off with a clean genesis and STEEM based code, I hope you/they would consider implementing the above sum of the product of SP and VS before genesis block creation.
I am not good enough to start such things.
What do you mean by
?
A blockchain, as the name imples, is a chain of blocks. At the start of the chain the very first block is called the genesis block. If you take the codebase of an existing crypto coin and start of from scratch with your own brand new genesis block and a seperate group of miners, you have created a completely different ledger even though the code uses by the new ledger is 100% equal to that of the original coin.
How is it that you have not thought about the premining issue?
It is the source of almost every injustice here.
Trickle down oligarchy, based on discovering Steem first, in a fashion that is faster than exponential with time (premining beats whatever profits made from the reward pool, and it is the initial condition of the exponential growths.
Not only did preminers get the benefits of discovering STEEM early and starting their exponential growth earlier than others, they started from much more, and knock down others' growth at will.
Is it necessary for the code to be STEEM based?
Not that I oppose it as a choice of start.
You got a 80.00% upvote from @voteme courtesy of @stimialiti! For next round, send minimum 0.01 SBD to bid for upvote.
Do you know, you can also earn daily passive income simply by delegating your Steem Power to voteme by clicking following links: 10SP, 25SP, 50SP, 100SP, 250SP, 500SP, 1000SP, 5000SP.
You got a 10.01% upvote from @sleeplesswhale courtesy of @stimialiti!
You got a 59.40% upvote from @luckyvotes courtesy of @stimialiti!
@youtake pulls you up ! This vote was sent to you by @stimialiti!
You got a 35.29% upvote from @proffit courtesy of @stimialiti!
Send at least 0.01 SBD/STEEM to get upvote , Send 1 SBD/STEEM to get upvote + resteem
Hey @stimialiti, Congratulations! Bodzila just upvoted your post with 22.93% power. Keep up the good work!
Delegate your Steem Power to @Bodzila & Earn 80% Weekly returns based on your share. You can cancel delegation of your SP at anytime as the money & power remain in your hands only.
Any queries or required support can be discussed in person. Join our discord channel https://discord.me/SteemBulls
You got a 24.39% upvote from @sleeplesswhale courtesy of @stimialiti!
You got a 50.00% upvote from @luckyvotes courtesy of @stimialiti!
@youtake pulls you up ! This vote was sent to you by @stimialiti!
You got a 44.44% upvote from @voteme courtesy of @stimialiti! For next round, send minimum 0.01 SBD to bid for upvote.
Do you know, you can also earn daily passive income simply by delegating your Steem Power to voteme by clicking following links: 10SP, 25SP, 50SP, 100SP, 250SP, 500SP, 1000SP, 5000SP.
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 40.00% upvote from @voteme courtesy of @stimialiti! For next round, send minimum 0.01 SBD to bid for upvote.
Do you know, you can also earn daily passive income simply by delegating your Steem Power to voteme by clicking following links: 10SP, 25SP, 50SP, 100SP, 250SP, 500SP, 1000SP, 5000SP.
You got a 48.54% upvote from @luckyvotes courtesy of @stimialiti!
You got a 100.00% upvote from @voteme courtesy of @stimialiti! For next round, send minimum 0.01 SBD to bid for upvote.
Do you know, you can also earn daily passive income simply by delegating your Steem Power to voteme by clicking following links: 10SP, 25SP, 50SP, 100SP, 250SP, 500SP, 1000SP, 5000SP.
This post has received a 33.33 % upvote from @kath1 thanks to: @stimialiti.
Hey @stimialiti, Congratulations! Bodzila just upvoted your post with 20.00% power. Keep up the good work!
Delegate your Steem Power to @Bodzila & Earn 80% Weekly returns based on your share. You can cancel delegation of your SP at anytime as the money & power remain in your hands only.
Any queries or required support can be discussed in person. Join our discord channel https://discord.me/SteemBulls
@youtake pulls you up ! This vote was sent to you by @stimialiti!
You got a 26.60% upvote from @sleeplesswhale courtesy of @stimialiti!
You got a 34.63% upvote from @proffit courtesy of @stimialiti!
Send at least 0.01 SBD/STEEM to get upvote , Send 1 SBD/STEEM to get upvote + resteem
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!
Submitted the power down scenario as issue 2539on GitHub. Hope the Devs and witnesses will be wise enough to fix the unerlying problem in a way similar to described above, not by applying an other 'cool down period's style ducktape patch.
Good stuff!
Luckily Steemit seems quite robust from a phishing pov.
I just wrote this article, would you mind giving it a look?
https://steemit.com/security/@gaottantacinque/steemit-security-check-iframe-tricks#comments
Many thanks :)