Author Topic: On 51% Attacks  (Read 8989 times)

0 Members and 1 Guest are viewing this topic.

Offline Agent86

  • Sr. Member
  • ****
  • Posts: 471
  • BTSX: agent86
    • View Profile
Welcome to the forum CfB! Thanks for posting!  I love to see tech discussion with NXT devs

Come-from-Beyond

  • Guest
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.

Offline 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.
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.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline BTSdac

  • Hero Member
  • *****
  • Posts: 1219
    • View Profile
  • BitShares: K1
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.
github.com :pureland
BTS2.0 API :ws://139.196.37.179:8091
BTS2.0 API 数据源ws://139.196.37.179:8091

Offline bytemaster

  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.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline Toeaf

  • Newbie
  • *
  • Posts: 4
    • View Profile
  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.
« Last Edit: May 23, 2014, 09:27:42 pm by Toeaf »

Offline bytemaster

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.   

For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.


Offline Toeaf

  • Newbie
  • *
  • Posts: 4
    • View Profile
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/


Offline bytemaster

Quote
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.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline CLains

  • Hero Member
  • *****
  • Posts: 2606
    • View Profile
  • BitShares: clains
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."

Offline Toeaf

  • Newbie
  • *
  • Posts: 4
    • View Profile
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
 


Offline bytemaster

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.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline Agent86

  • Sr. Member
  • ****
  • Posts: 471
  • BTSX: agent86
    • View Profile
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.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
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.

I speak for myself and only myself.