On 51% Attacks

[bytemaster]

I am likely confused here, but the problem seems to occur when your vote distribution is lopsided it opens the process up to being exploited by a minority.  This could be mitigated by keeping the vote distribution as equal as possible.  To do this the client software should have some form of a ordered list of delegates to vote for.  So that the one favored guy doesn't get 30% of the votes. (for example)   The list will move your vote "down the line" so to speak.  This optimizes the power of each stake's vote and helps prevents situations where a minority is able to have undue influence due to the clumping of the votes towards the most popular delegates.

There is a maximum vote per delegate equal to 2x what they could receive if all delegates had an equal vote.  This means for 100 delegates, the max vote is 2%.

Does the client instantly kick the vote back so a person can make another decision?  Or is it decided by the network and thus the vote floats around in limbo ?  You also need to give delegates some sort of name or otherwise they are just #s to people which will not lead to effective voting choices.  Names introduce cognitive biases which aren't exactly good, but it is better than a pure #.  Is the name of a delegate a public key ?

Delegates are named (already implemented in the code).
Your wallet will not generate a transaction that votes for someone at the limit. 

[gamey]

I am likely confused here, but the problem seems to occur when your vote distribution is lopsided it opens the process up to being exploited by a minority.  This could be mitigated by keeping the vote distribution as equal as possible.  To do this the client software should have some form of a ordered list of delegates to vote for.  So that the one favored guy doesn't get 30% of the votes. (for example)   The list will move your vote "down the line" so to speak.  This optimizes the power of each stake's vote and helps prevents situations where a minority is able to have undue influence due to the clumping of the votes towards the most popular delegates.

There is a maximum vote per delegate equal to 2x what they could receive if all delegates had an equal vote.  This means for 100 delegates, the max vote is 2%.

Does the client instantly kick the vote back so a person can make another decision?  Or is it decided by the network and thus the vote floats around in limbo ?  You also need to give delegates some sort of name or otherwise they are just #s to people which will not lead to effective voting choices.  Names introduce cognitive biases which aren't exactly good, but it is better than a pure #.  Is the name of a delegate a public key ?

[bytemaster]

I am likely confused here, but the problem seems to occur when your vote distribution is lopsided it opens the process up to being exploited by a minority.  This could be mitigated by keeping the vote distribution as equal as possible.  To do this the client software should have some form of a ordered list of delegates to vote for.  So that the one favored guy doesn't get 30% of the votes. (for example)   The list will move your vote "down the line" so to speak.  This optimizes the power of each stake's vote and helps prevents situations where a minority is able to have undue influence due to the clumping of the votes towards the most popular delegates.

There is a maximum vote per delegate equal to 2x what they could receive if all delegates had an equal vote.  This means for 100 delegates, the max vote is 2%.

[gamey]

I am likely confused here, but the problem seems to occur when your vote distribution is lopsided it opens the process up to being exploited by a minority.  This could be mitigated by keeping the vote distribution as equal as possible.  To do this the client software should have some form of a ordered list of delegates to vote for.  So that the one favored guy doesn't get 30% of the votes. (for example)   The list will move your vote "down the line" so to speak.  This optimizes the power of each stake's vote and helps prevents situations where a minority is able to have undue influence due to the clumping of the votes towards the most popular delegates.

[toast]

Bytemaster, with all the examples you mentioned you talk about 51% being enough to gain the ability to produce 100% of the blocks. How is that possible if with Bitcoin the chance of finding a block is based on the probability relative to your hasing power? Wouldnt it be the case that 49% of the blocks would still be produced by the 49% minority? The same for NXT because it is also probabilistic. And for the deterministic DPOS wouldnt the non colluding 49% be able to produce blocks as they wish when it's their turn?

The block producers get to choose which blocks they build off of.  They can safely ignore blocks found by the 49%.... sure they 49% will still find blocks, they will just be orphaned.

And the 49% could ignore the blocks found by the 51%
So it just means that in the long run the 51% attacker has the longer chain?
This would be called a fork then?

Yes, and since the client treats the longer chain as the "correct" one the attacker has control of the network even if the 49% disagree. It doesn't matter what you think is the "right" chain if your client shows the balance from the "wrong" chain.

[atmos]

Bytemaster, with all the examples you mentioned you talk about 51% being enough to gain the ability to produce 100% of the blocks. How is that possible if with Bitcoin the chance of finding a block is based on the probability relative to your hasing power? Wouldnt it be the case that 49% of the blocks would still be produced by the 49% minority? The same for NXT because it is also probabilistic. And for the deterministic DPOS wouldnt the non colluding 49% be able to produce blocks as they wish when it's their turn?

The block producers get to choose which blocks they build off of.  They can safely ignore blocks found by the 49%.... sure they 49% will still find blocks, they will just be orphaned.

And the 49% could ignore the blocks found by the 51%
So it just means that in the long run the 51% attacker has the longer chain?
This would be called a fork then?

[bytemaster]

Recognizing this reality, we can embrace it fully and allow 51% of the delegates to fire any other delegate.   It wouldn't actually change the security model, it would simply make it slightly easier to coordinate among the delegates and the rest of the network. 

51% of delegates by stake?

The bottom 51% of delegates might have less than 51% of stake. I know the clients smooth things out automatically and there are hard caps... make the % cutoff based on those theoretical hard caps.

All delegates have equal power in the system as selection of the next delegate is not based upon their net votes.  This means a delegate has nothing to gain by having more than 1% and nothing to lose by having less than 1% unless they are not in the top 99.

Exactly, so by allowing 51 delegates to fire regardless of stake-vote you are making a 51% attack into a ~40% attack.

Perhaps... but delegate votes are 'net votes' which means that you can vote against a delegate as well as for a delegate.  What this means is that if 40% of the shares are held by the attacker, 40% of the shares can vote against the attacker and thus the attacker gets 0 delegates.   

So to the extent the network divides its votes among 'loosing delegates' it is like the inactive NXT or Peercoin users.   Ideally delegates get elected and 99% of the votes are for (or against) one of the active delegates.  The only time someone would vote for someone not on the current active list is if they think there is a problem that needs to be resolved to make things better.

 

[toast]

Recognizing this reality, we can embrace it fully and allow 51% of the delegates to fire any other delegate.   It wouldn't actually change the security model, it would simply make it slightly easier to coordinate among the delegates and the rest of the network. 

51% of delegates by stake?

The bottom 51% of delegates might have less than 51% of stake. I know the clients smooth things out automatically and there are hard caps... make the % cutoff based on those theoretical hard caps.

All delegates have equal power in the system as selection of the next delegate is not based upon their net votes.  This means a delegate has nothing to gain by having more than 1% and nothing to lose by having less than 1% unless they are not in the top 99.

Exactly, so by allowing 51 delegates to fire regardless of stake-vote you are making a 51% attack into a ~40% attack.

[bytemaster]

Recognizing this reality, we can embrace it fully and allow 51% of the delegates to fire any other delegate.   It wouldn't actually change the security model, it would simply make it slightly easier to coordinate among the delegates and the rest of the network. 

51% of delegates by stake?

The bottom 51% of delegates might have less than 51% of stake. I know the clients smooth things out automatically and there are hard caps... make the % cutoff based on those theoretical hard caps.

All delegates have equal power in the system as selection of the next delegate is not based upon their net votes.  This means a delegate has nothing to gain by having more than 1% and nothing to lose by having less than 1% unless they are not in the top 99. 

[toast]

Recognizing this reality, we can embrace it fully and allow 51% of the delegates to fire any other delegate.   It wouldn't actually change the security model, it would simply make it slightly easier to coordinate among the delegates and the rest of the network. 

51% of delegates by stake?

The bottom 51% of delegates might have less than 51% of stake. I know the clients smooth things out automatically and there are hard caps... make the % cutoff based on those theoretical hard caps.

[bytemaster]

Bytemaster, with all the examples you mentioned you talk about 51% being enough to gain the ability to produce 100% of the blocks. How is that possible if with Bitcoin the chance of finding a block is based on the probability relative to your hasing power? Wouldnt it be the case that 49% of the blocks would still be produced by the 49% minority? The same for NXT because it is also probabilistic. And for the deterministic DPOS wouldnt the non colluding 49% be able to produce blocks as they wish when it's their turn?

The block producers get to choose which blocks they build off of.  They can safely ignore blocks found by the 49%.... sure they 49% will still find blocks, they will just be orphaned.

[atmos]

Bytemaster, with all the examples you mentioned you talk about 51% being enough to gain the ability to produce 100% of the blocks. How is that possible if with Bitcoin the chance of finding a block is based on the probability relative to your hasing power? Wouldnt it be the case that 49% of the blocks would still be produced by the 49% minority? The same for NXT because it is also probabilistic. And for the deterministic DPOS wouldnt the non colluding 49% be able to produce blocks as they wish when it's their turn?

[bytemaster]

https://nxtforum.org/transparent-forging/is-this-true/msg26631/#msg26631

Ignorance is bliss? How on earth can the answer be "no"?

In fact for nxt wouldn't it be even worse since most stake is offline and not producing blocks most of the time?

Sent from my SCH-I535 using Tapatalk

This is exactly the point... I think someone should expound upon how they avoid this.

If I am a forger and I pretend I didn't see the blocks of others then the network must go on.  The network clearly doesn't hang until the block is produced.   Sure the network may FORK.   

If they have some magic solution to this problem then I WANT IT!   

[toast]

https://nxtforum.org/transparent-forging/is-this-true/msg26631/#msg26631

Ignorance is bliss? How on earth can the answer be "no"?

In fact for nxt wouldn't it be even worse since most stake is offline and not producing blocks most of the time?

Sent from my SCH-I535 using Tapatalk

[voldemort628]

https://nxtforum.org/transparent-forging/is-this-true/msg26631/#msg26631