BitShares Forum
Main => General Discussion => Topic started by: bytemaster on May 22, 2014, 02:00:37 pm
-
The nature of the 51% attack is often obscured so I would like to expound upon it generally (for all systems).
If someone has 51% of the bitcoin hashing power they can exclude blocks produced by the other 49% and thus end up producing 100% of the blocks actually included in the blockchain. Difficulty will adjust down by 49% and block rate will return to 10 minutes (after being 20 minutes). The other miners (in the 49%) would have to get on the bandwagon and ratify the blocks produced by the attacker (and not produce blocks that violate the attackers rules).
So someone with 51% of the blocks has the power to enforce a STRICTER set of transaction rules. This allows accounts to be frozen, etc.
Likewise with Nxt, if 51% of the active forgers (which is less than 51% of the shareholders) decide to collude they can exclude the 49% of the active forgers, those 49% will be 'punished' for not producing a block and the 51% will eventually control 100% of the active forging. Once again they gain the ability to enforce a STRICTER set of transaction rules and this allows frozen accounts.
Likewise with Ripple, if 51% of the original UNL decide to exclude someone from their UNL then their opinion is ignored.
Likewise with DPOS if 51% of the delegates collude, they can ignore blocks produced by the 49%.
The principle here is that consensus always has a tipping point when the 'majority' goes with it. You cannot enforce a consensus of 90% without the potential of deadlock. These systems must allow people to abstain to be robust against failure because if you require everyone to reach 90% agreement then if 11% of the network goes down you have no consensus.
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.
All networks are only as secure as the trust you place in the 51%.
-
https://nxtforum.org/transparent-forging/is-this-true/msg26631/#msg26631
-
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
-
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!
-
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, 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.
-
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.
-
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.
-
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.
-
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.
-
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, 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.
-
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.
-
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%.
-
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 ?
-
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.
-
Seems like you'd still want to provide some backup selection in the GUI? Or a way to order a precedence of your vote. Oh well, I guess it can all be done in alternative clients.
It is kinda creepy. I could release a wallet that has all the votes hardcoded or heavily suggested. If I talked even a small portion to download my wallet, I wonder what the implications could be ?
Say I have a legit wallet and go rogue after I gain a large % of the user base ?
Anyway.. just thoughts
It really makes sense to put this 2% threshold adjustable in the client, but I suppose these things will be tweaked as a more rigorous mathematical examination is done... Or a "I vote for the lowest voted delegate out of this list of A,B,C,D" .. That alone could help avoid your edge cases where you might be exploited.
-
Imagine if a lot of people use their votes to vote against delegates and a lot of people also vote for candidate delegates that have less than the minimum needed support to be chosen as a delegate (such as always voting for yourself or a friend to be a delegate).
I would think the people that actually end up being delegates might have a very small percentage of the stake supporting them.
Example: 20% of stake votes for delegates controlled by some controversial figure(s) and 20% of stake votes against that person's delegates. Then 30% of people vote for candidates that don't have enough support to matter.
That leaves only 30% of the stake that are supporting actual delegates. You might be able to get 51% of the delegates with much less than 50% of the stake?
Especially because factions can get together and plan to vote for a bunch of delegates all at once before anyone has time to think to vote against them.
-
Imagine if a lot of people use their votes to vote against delegates and a lot of people also vote for candidate delegates that have less than the minimum needed support to be chosen as a delegate (such as always voting for yourself or a friend to be a delegate).
I would think the people that actually end up being delegates might have a very small percentage of the stake supporting them.
Example: 20% of stake votes for delegates controlled by some controversial figure(s) and 20% of stake votes against that person's delegates. Then 30% of people vote for candidates that don't have enough support to matter.
That leaves only 30% of the stake that are supporting actual delegates. You might be able to get 51% of the delegates with much less than 50% of the stake?
Especially because factions can get together and plan to vote for a bunch of delegates all at once before anyone has time to think to vote against them.
One thing to remember in all of this is that the only thing you can do once 'in power' is censor transactions and that power is easily taken from you with a hard fork as it will be clear that you are misbehaving.
It would harm everyone involved. There is nothing to gain for large numbers of shareholders to team up to kill the network.
-
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
CfB is the main developer, so I doubt he is ignorant about Nxt
More:
https://nxtforum.org/transparent-forging/is-this-true/msg27132/#msg27132
-
main developer? then I do not understand his comment,
"Hehe, sorry toast, sometimes I'm not in mood to explain things that can be figured out by using own brain. In this case I was wrong, I can't find where it was explained in details how Transparent Forging works. My bad."
-
Alice, Charlie, Alice, Bob, Bob, Charlie, Bob, Charlie, Alice, ...
First u receive a block (A) from Alice.
Then u receive a block (B) from Charlie.
Then u receive a block from Alice, but she wants to eject Charlie from the queue and references block A as the previous block. Ur soft will ignore her block and will wait for the next forger. If the next one is Bob and he references block A too then ur soft will ignore this block too. After a while there will be a turn of Charlie.
As we can see bad guys can't "punish" good ones. The effect is exactly the opposite.
So their technical answer is something we had considered and rejected on the following principle (though there is still some debate with Dan N.)
1) What if Alice is acting properly and Charlie was just 'late' producing his block. The network will split because half the nodes will receive a block from Charlie before Alice's second block and half will not.
2) What if you are a new node and you first connect to the network. You see two chains, how do you decide which chain is the 'best' chain?
3) Since everyone is receiving blocks directly from certain nodes and knows when they should be receiving them, then DOS is a huge vulnerability.
So given these issue their consensus algorithm depends upon the majority of nodes maintaining 100% uptime and in the event of a network split has no legitimate way of identifying the best chain without manual intervention.
Now clearly they are probably suffering some of the same challenges we are with explaining things like DPOS. So I am going to give them the benefit of the doubt and hope someone will cross-post this so they can answer it. If they have solutions to 1, 2 and 3 that are viable I am very interested.
-
2) What if you are a new node and you first connect to the network. You see two chains, how do you decide which chain is the 'best' chain?
Is this related?
https://nxtforum.org/news-and-announcements/economic-clustering/
-
and more
https://nxtforum.org/general-discussion/on-economic-clusters-and-the-longest-chain/
-
I agree with the principle that ultimately economic laws will resolve all forks.
As other users pointed out, rules that prevent forks in the first place help make things better.
So to attack the network I just have to cause Walmart, Bestbuy, Bitstamp, etc to see different blocks at the same time. Now these big players have a challenge, 'who wins'.
If the attacker produces 10 different blocks and randomly gives them to different peers. The peers have to choose to ignore the block all together.
But a more subtle attack is to only produce the block for 50% of your peers and not give it to the other 50% *AND* to do it at the last possible moment such that some peers include it and others don't.
-
But a more subtle attack is to only produce the block for 50% of your peers and not give it to the other 50% *AND* to do it at the last possible moment such that some peers include it and others don't.
I am not expert, but I remember BTT thread about how Nxt works:
Let's say I have 25% of NXT coins. And I want to mount an attack. I need to do the following.
1. Wait until I am selected as a forger.
2. Create 2 blocks, one for the network and one I hold back.
3. Continually add more blocks to the block I hold back. This is my chain I will introduce later as my attack.
The problem is step 3. To add another block to my held back block I need to be selected as the forger for that block too. However forger selection is based on the hash of the previous block and my account address.
Neither of these I can change quickly enough to be sure I generate the next block. So my probability of being selected to build the next block is 25% for each block.
-
But a more subtle attack is to only produce the block for 50% of your peers and not give it to the other 50% *AND* to do it at the last possible moment such that some peers include it and others don't.
I am not expert, but I remember BTT thread about how Nxt works:
Let's say I have 25% of NXT coins. And I want to mount an attack. I need to do the following.
1. Wait until I am selected as a forger.
2. Create 2 blocks, one for the network and one I hold back.
3. Continually add more blocks to the block I hold back. This is my chain I will introduce later as my attack.
The problem is step 3. To add another block to my held back block I need to be selected as the forger for that block too. However forger selection is based on the hash of the previous block and my account address.
Neither of these I can change quickly enough to be sure I generate the next block. So my probability of being selected to build the next block is 25% for each block.
Yes, but if you don't produce the next block... every minute you have an opportunity to produce a block so on average once every 4 minutes you could extend your secret chain. Obviously you will never have the longest chain and this is how DPOS works... we use the longest chain metric.
In other words, if the next block producer doesn't produce a block, then someone else will produce their block on time.
If the attacker has 51% then their hidden chain will be longer than the public chain.
But Nxt doesn't look at length, it looks at blocks you have seen recently.
-
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.
Hi bytemaster
attaker have 51"% hash power ,and he does not want chain fork ,but he only have 51% chance to find lucky No. to produce block , others also have 49% hash power ,and have 49% chance find lucky No. to produce block .
so the attacker have 0.51^6=0.0175 chance produce 6 continual blocks , others have 0.49^6=0.0138 chance to produce 6 continual blocks, and there are 0.968=96.8% chance of attaker and others producing blocks in 6 blocks
if the attacker produce blocks and does not announce it until he produce 6 continual block, this will make chain fork.
-
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.
Hi bytemaster
attaker have 51"% hash power ,and he does not want chain fork ,but he only have 51% chance to find lucky No. to produce block , others also have 49% hash power ,and have 49% chance find lucky No. to produce block .
so the attacker have 0.51^6=0.0175 chance produce 6 continual blocks , others have 0.49^6=0.0138 chance to produce 6 continual blocks, and there are 0.968=96.8% chance of attaker and others producing blocks in 6 blocks
if the attacker produce blocks and does not announce it until he produce 6 continual block, this will make chain fork.
I think I follow you. After 100 blocks the attacker will have produced 51 and the main network would have produced 49... as time progresses the attacker's blockchain will pull further and further into the lead. Any blocks produced by the 49% are orphaned and useless.
-
If the attacker has 51% then their hidden chain will be longer than the public chain.
The attacker have to reveal this hidden chain before the legit chain goes 10* blocks ahead of the fork. Otherwise online nodes won't accept his chain. So after 10 confirmations transactions will be set in stone.
---
* - actual number depends on statistics, it's set to 720 now.
-
Welcome to the forum CfB! Thanks for posting! I love to see tech discussion with NXT devs
-
Welcome to the forum CfB! Thanks for posting! I love to see tech discussion with NXT devs
+5%
welcome!
-
Welcome to the forum CfB! Thanks for posting! I love to see tech discussion with NXT devs
+5%
welcome .. its a pleasure
-
Welcome to the forum CfB! Thanks for posting! I love to see tech discussion with NXT devs
+5%
welcome!
+5%
-
Thank u. Bitshares looks similar to Nxt, I hope u don't mind if I borrow good ideas. :)
-
Thank u. Bitshares looks similar to Nxt, I hope u don't mind if I borrow good ideas. :)
I borrow Stans quote : ;)
"You and Dan will drive more awareness to each other than you will take away from each other. It's the same reason competing car dealers and hardware stores tend to cluster on the same street. Get the traffic to come to your neighborhood and then compete!"
-
If the attacker has 51% then their hidden chain will be longer than the public chain.
The attacker have to reveal this hidden chain before the legit chain goes 10* blocks ahead of the fork. Otherwise online nodes won't accept his chain. So after 10 confirmations transactions will be set in stone.
---
* - actual number depends on statistics, it's set to 720 now.
So right now it takes 720 confirmations to be 'set in stone'. It sounds to me like we are both using the same model here.
I think I can sum up DPOS as automated POS mining pools with an eye toward rapid confirmation and filtering of good/bad pool operators.
I would love to know which ideas you have found worth borrowing.
I think that at the end of the day the primary difference between transparent forging and DPOS is only how the block producers are selected. In one case you do it based upon balance, we do it by vote.
-
I think that at the end of the day the primary difference between transparent forging and DPOS is only how the block producers are selected. In one case you do it based upon balance, we do it by vote.
Aye, I thought so too.
-
I think that at the end of the day the primary difference between transparent forging and DPOS is only how the block producers are selected. In one case you do it based upon balance, we do it by vote.
Aye, I thought so too.
This is a good sign for both of our communities.
-
I think that at the end of the day the primary difference between transparent forging and DPOS is only how the block producers are selected. In one case you do it based upon balance, we do it by vote.
Aye, I thought so too.
This is a good sign for both of our communities.
+5%
-
the possibility both to be wrong is small I guess...
Sent from my ALCATEL ONE TOUCH 997D using Tapatalk
-
the possibility both to be wrong is small I guess...
(Devil's advocate mode on)
The truth is not to be found by voting...
(Devil's advocate mode off)
-
the possibility both to be wrong is small I guess...
(Devil's advocate mode on)
The truth is not to be found by voting...
(Devil's advocate mode off)
(Angel's advocate mode on)
Devil is lying because they don't want us to find the truth... :)
(Angel's advocate mode off)
-
Bytemaster what about:
"The truth is NOT to be found ONLY by VOTING..."
What about a hybrid solution ...like 50% of the delegates to be elected like the original plan propose, and the other 50% to be "elected" depended of their % of stake on bitshares or "whatever" mix brings optimal results... ?
PS + variable number of delegates depending on transactions volume...?
-
PS + variable number of delegates depending on transactions volume...?
Variable number would at least remove the magic number of 100 delegates. Magic numbers is the 1st thing that attracts attention of opponents.
-
PS + variable number of delegates depending on transactions volume...?
Variable number would at least remove the magic number of 100 delegates. Magic numbers is the 1st thing that attracts attention of opponents.
You missed some insight's... 99 or 101 delegates! Like the dalmatians dogs (that's a marketing idea Brian)
Notice the detail... that it is optimal to use odd* number for delegates...
* Recent update... the number of delegates must be a ODD number to prevent the potential of a chain split of equal length. We had discussed making the number of delegates PRIME, but this seems to be an unnecessary considering a it does not prevent a 3-way split from potentially forming two equal length chains.
At every time interval (30 sec) exactly one block can be produced (or not produced). If the network splits this means that two chains with opposite holes will be produced until the missing delegates are fired. Assuming both sides of the fork replace their delegates at an equal rate then the chain that started out with the most delegates will always have the most blocks and thus be the best.
If you get a chain fork that lasts for a prolonged period of time then which ever chain is most effective at keeping delegates online will ultimately win. To be effective at this will require that the delegates that were disconnected be replaced rapidly; however, to replace them requires shareholders to switch votes or to vote against them. This means that the fork is ultimately resolved by how the shareholders are divided by the network split rather than just how the delegates are divided.
What will likely happen in the event of such a split is that all shareholders will become aware of the split immediately and also know which side of the split they are on. Many delegates can immediately detect that they are on a minority fork and could choose to let the minority fork die by voluntarily not producing blocks for it. Only in the event of hostile delegates would the minority delegates & shareholders attempt to 'make a run for it'...
Conclusion: having an ODD number of delegates makes it easy to identify a minority fork and the shareholders and delegates will act accordingly.
There is one last 'far-out-there' attack where the network is divided into 3 or more pieces less than 50%... in this case the delegates would have to stay online producing blocks until they could confirm that their 3rd is the largest 3rd. If they are in the smallest 3rd then they should stop producing blocks to let that third die.
These corner cases are all ultimately resolved by the longest-chain standard and it is inconceivable to think that a consensus would not force once fork or another to win out.
source: https://bitsharestalk.org/index.php?topic=4009.45 (https://bitsharestalk.org/index.php?topic=4009.45)