You are viewing a single comment's thread from:
RE: Steem blockchain multivote security vulnerability
Resteem
but Steem has no 51%-Attack vector (it is not Bitcoin), you need to fine tune your system to prevent a >1/3 (33%)- attack vector. This is not dPOS but dPOS+BFT which is based on a 2/3+1 safety assumption! So the main premise must be that no one can economically form a 1/3+ "majority". Maybe you already know? Consensus in Blockchain is not the same as in human terms like "majority decision" or "popular opinion". It is a technical term. Bitcoin other than the rest is not a node based consensus scheme.
30/1 voting rule exactly makes this attack vector easier.
But, in the meantime, I've found
you haveproposed very similar solution!, i.e. 1SP = 1 vote!Dividing vote power would have the same effect as reducing the number of possible witnesses to be voted by one account to 1, but still allows to cast votes from one account to more than one candidate (smaller votes, though). So a more flexible solution. 30 candidates are too many, 10 much better, I would go for an even smaller number, 3 or 5.
Steemits 51%-attack is having 51% of the top 20 witnesses. That is 11 witnesses with combining 51% of the voted steem power.
Ok, but the honest consensus is not made by >1/2 majority. Consensus in permissioned systems is made by at least 2/3! In Steems dPOS-BFT it is the longest chain rule, where the last irreversible block (LIP) is the block where >2/3< of the Witnesses have jumped on. With up to 1/3 byzantine Nodes you can "only" create a minority fork. In a round-robin scheduling like Steem where a block is added every 3 seconds (which is dertermined by network delay/speed of light) a malicious 1/3 minority can only add blocks every 9 seconds to their "wrong" chain, while the 2/3 honest majority adds blocks still every 6 seconds. When you get more than 1/3 it becomes undecidable. This is why the security assumption of permitted chains is
[(n-1)/3]or in other terms forffaulty nodes you need3 f + 1aka >2/3+1< honest nodes.So there is no 51% attack vector when you can violate the correctness with only >33%. When 51% of the stake can vote more than 1/3, then this is a dumb design decision and not a 51%-attack. The 51%-attack vector in open=asynchronous systems like Bitcoin is due to the laws of physics (Fisher-Lynch-Peterson Impossibility Theorem). When you want a synchronized system which is not subject to the FLP-problem you need a fixed direct or indirect quorum like Steem or Eos but then you have no >1/2 anonymous majority election.
Thanks for the explanations. That was quite enlightening and I learned something new. 👍
However, I'm more worried about the ability to make hard and soft forks and therefore change the rules. Including the rules you just explained.
The very real attack which we just had — twice. First the old witnesses locking @justinsunsteemit's funds. That was a bit hasty.
And then Justin by retaliating by taking over the whole chain with sock puppet witnesses. Which is even worse. And makes me wonder if I should retract me delegations and prepare for power down. Because if Justin gets his way and becomes “benevolent blockchain dictator for 6 weeks” I don't think I don't want to stay.
We all know how those “benevolent dictatorships” end each and every time.
yeah true the community has to react anyways. We are not here for centralisation. 👍