You are viewing a single comment's thread from:

RE: Fact: Steemit Sybil Attacked the Steem Blockchain

in #steem5 years ago (edited)

Steem is designed for an easy 1/3 + 1 attack.

That is very innacurate...1/3 +1 only gives the "attacker" the ability to block a hardfork but you cannot takeover consensus...for that you need 2/3 +1.

What is more, it's designed through the multivote rule to be 100% controlled by a very small number of top SP holders.

It designed for the majority stake to dictate consensus. The number of accounts holding the SP is irrelevant to the consensus logic. This favors centralization.

The real threat is voter apathy. Before this whole incident started only about 28% of the stake was voting (it might have been less so I might be wrong on the exact number). With that level of participation and combined with the 30 vote rule you only need 29% of the stake to take over the witness positions.

Mix in some colusion with exchanges and you have exposed the DPOS vulnerabilities.

The solution seems obvious...limit the number of seats that an account can vote on and incentivize voting (maybe direct a portion of the inflation for that). Although limiting the amount of positions introduces other risks (such as the blockchain forking if no one can control consensus).

Sort:  

"...for that you need 2/3 +1..."

No. All you need is 51% of stake voting. That is what determines how many witnesses control consensus.

Worse, the weight of stake is currently subject to vast multiplication via the 30 votes availed stakeholders. To wit:

User A has 1M Steem. Casting 30 witness votes worth 1M Steem each gives them 30M Steem influence on governance. User B has 100 Steem. Casting 30 witness votes gives them 3000 Steem influence on governance.

The difference between the stake held by these users is 999,900 Steem. The difference between their influence on governance is 29,997,000 Steem. This multiplication of stake weight dramatically centralizes influence on governance, which consensus witnesses have failed to previously resolve.

Clearly, this is a problem, and strongly lends support to accusations of corruption of Steem governance. It's long past time for this deception and centralization of Steem governance to end - possibly too late to save the Steem community from the Sybil attack it has promoted. Other limitations on stake influence on governance is necessary, but accurate weighting of stake influencing governance is absolutely a necessary component of securing Steem from Sybil attacks.

I am provided estimates of Tron's present stake of ~100M Steem. This theoretically enables Tron to deploy 3B Steem influence on governance. That is utterly untenable now, or ever.

That is correct with the current voting rules.

That is very innacurate...1/3 +1 only gives the "attacker" ...

https://steempeak.com/steemtron/@lauch3d/there-is-no-51-attack-in-steem

Good thing we can agree on reducing the number of witness candidates a vote can be cast on. Most importantly, should be 1SP = 1 vote. One can vote on 5 candidates, but each would get only 0.2SP worth of votes.
30 is too many, no average person can make an educated decision about so many candidates. See my post for the details.

The workaround against both options is to simply split the stake to different accounts. Both make it more difficult to overtake the chain with a minority stake but it's better than the alternative.

The current setup allows for a 51% attack instead of the theoretical 2/3 +1 that is needed today...that is very clear.

Limiting the number of blockproducers that a stakeholder can determine has other tradeoffs so it's a complex problem.

The workaround against both options is to simply split the stake to different accounts.

No, it's not. See A splitting stake to A1 and A2 in my article. He can maximize usage of his stake, but still unable to take all the seats.

Limiting the number of blockproducers that a stakeholder can determine has other tradeoffs so it's a complex problem.

If you can point out these tradeoffs. I can't see any. 1 SP = 1 vote simply allows for better decentralisation. JS made an educated decision about 20 candidates, but the average person would not :)

I can imagine a situation where 2 or 3 different versions of the code are running side by side that create different forks that do not agree on the last irreversible block. Each version being supported by different cartels with no clear way of breaking the tie.