51% attack is a myth

[Come-from-Beyond]

From https://en.bitcoin.it/wiki/Attacks#Attacker_has_a_lot_of_computing_power:

An attacker that controls more than 50% of the network's computing power can, for the time that he is in control, exclude and modify the ordering of transactions...

That's almost correct, but it doesn't take into account orphaned blocks. Each orphaned block is wasted hashpower. An attacker won't have orphaned blocks at all, coz they don't need to distribute found blocks to other peers. When the time comes, the attacker will distribute the whole fork at once. So instead of "51%" we should read "49%" or even less. After the 15th of May, when blocks become bigger, the rate of orphaned blocks will increase. This means that instead of "49%" we'll get "45%" or less.

I created this thread to attract attention to the following issue:

Increasing the blocksize limit we increase odds of a successful forking attack.

[cypherdoc]

i'm not seeing much of a problem.

[Come-from-Beyond]

i'm not seeing much of a problem.

Ostrich policy?

[dree12]

From https://en.bitcoin.it/wiki/Attacks#Attacker_has_a_lot_of_computing_power:

An attacker that controls more than 50% of the network's computing power can, for the time that he is in control, exclude and modify the ordering of transactions...

That's almost correct, but it doesn't take into account orphaned blocks. Each orphaned block is wasted hashpower. An attacker won't have orphaned blocks at all, coz they don't need to distribute found blocks to other peers. When the time comes, the attacker will distribute the whole fork at once. So instead of "51%" we should read "49%" or even less. After the 15th of May, when blocks become bigger, the rate of orphaned blocks will increase. This means that instead of "49%" we'll get "45%" or less.

I created this thread to attract attention to the following issue:

Increasing the blocksize limit we increase odds of a successful forking attack.

Two things:

1. The May 15 update does not increase the block size limit. Blocks at the maximum possible size can already be mined and will already be accepted. Only blocks with too many inputs and outputs are affected.
2. A larger block does not necessarily cause an increase in orphaned blocks rate. Block time, at 10 minutes, is more than enough to download a block.

[Come-from-Beyond]

1. The May 15 update does not increase the block size limit. Blocks at the maximum possible size can already be mined and will already be accepted. Only blocks with too many inputs and outputs are affected.

OK. But the issue is still there.

2. A larger block does not necessarily cause an increase in orphaned blocks rate. Block time, at 10 minutes, is more than enough to download a block.

Common sense tells me that a larger block has higher odds to become orphaned, coz Bob can send a new block to Carol only after he downloaded it from Alice. Is this correct?
10 min is enough to download a block, but it's AVERAGE time.


EDIT: I found charts related to the discussion - https://bitcointalk.org/index.php?topic=88302.msg984376#msg984376.

[dree12]

1. The May 15 update does not increase the block size limit. Blocks at the maximum possible size can already be mined and will already be accepted. Only blocks with too many inputs and outputs are affected.

OK. But the issue is still there.

2. A larger block does not necessarily cause an increase in orphaned blocks rate. Block time, at 10 minutes, is more than enough to download a block.

Common sense tells me that a larger block has higher odds to become orphaned, coz Bob can send a new block to Carol only after he downloaded it from Alice. Is this correct?
10 min is enough to download a block, but it's AVERAGE time.


EDIT: I found charts related to the discussion - https://bitcointalk.org/index.php?topic=88302.msg984376#msg984376.

Yes, it is correct. However, this issue can be solved by applying a patch to the code (as Bob can verify block header veracity and send to Carol simultaneously as he is downloading from Alice). BitTorrent uses the same solution.

Consequently, the issue, once it becomes important, can be solved.

[Come-from-Beyond]

Consequently, the issue, once it becomes important, can be solved.

Everything can be solved. But it should be solved BEFORE someone makes a successful attack.

[Etlase2]

I created this thread to attract attention to the following issue:

Increasing the blocksize limit we increase odds of a successful forking attack.

There is a bigger issue in a similar vein that isn't even a block propagation issue. An attacker with say, 30% of the network's power could stomp down the blocks of others by putting out mini-chains that beat the real chain temporarily, but replace previous blocks. Every time he gets one, he waits a bit and if a second comes quickly, he can invalidate a block created before his 1st or 2nd. He can choose not to increase the total hashing power of the network while reducing the profitability of honest pools--and potentially causing miners to quit. A naive presumption on the 51% attack is that if the network has an honest 10TH/s, an attacker needs 10TH/s+, but he really only needs 5TH/s or potentially a lot less if he can get that honest 10TH/s down by forcing people on the border of profitability to quit.

[Rodyland]

I created this thread to attract attention to the following issue:

Increasing the blocksize limit we increase odds of a successful forking attack.

There is a bigger issue in a similar vein that isn't even a block propagation issue. An attacker with say, 30% of the network's power could stomp down the blocks of others by putting out mini-chains that beat the real chain temporarily, but replace previous blocks. Every time he gets one, he waits a bit and if a second comes quickly, he can invalidate a block created before his 1st or 2nd. He can choose not to increase the total hashing power of the network while reducing the profitability of honest pools--and potentially causing miners to quit. A naive presumption on the 51% attack is that if the network has an honest 10TH/s, an attacker needs 10TH/s+, but he really only needs 5TH/s or potentially a lot less if he can get that honest 10TH/s down by forcing people on the border of profitability to quit.

I don't get what you're saying.  If he's releasing valid blocks then it's to the benefit of the network.  Sure he'll create some orphans. But create orphans is all he can do. Do you really think if someone had the resources to intentionally create orphans that it would really disrupt the network?

[Etlase2]

I don't get what you're saying.  If he's releasing valid blocks then it's to the benefit of the network.  Sure he'll create some orphans. But create orphans is all he can do. Do you really think if someone had the resources to intentionally create orphans that it would really disrupt the network?

Is centralizing the network to the network's benefit? The attacker is denying legitimate people payment for securing the network. Those people are, in effect, completely wasting their time. Of course averages would say that everyone would take a pay cut fairly equally, but that would cause the least profitable of miners to stop mining, for the most part. It then becomes easier for the attacker to produce more blocks that deny payment to honest miners for the same amount of hash power, and cause more people to quit, and so on.

Depending on how much the attacker is in it for the "long haul", this attack could be performed by amounts as small as 10-20% of the total honest hashing power to cause a serious dent in the security of the network. A pattern of orphaned blocks would probably emerge though, and there could be ways to reduce the attack's viability, but it might come at a cost of causing potential hard forks and lots of confusion.

[jdbtracker]

I think someone should test this, just for arguments sake, it would be good info to check other Bitcoin clones to see if anyone has made a succesful attack using this method. loading the block chain with junk could work too.

[datz]

Consequently, the issue, once it becomes important, can be solved.

Everything can be solved. But it should be solved BEFORE someone makes a successful attack.

How?

[jdillon]

That's almost correct, but it doesn't take into account orphaned blocks. Each orphaned block is wasted hashpower. An attacker won't have orphaned blocks at all, coz they don't need to distribute found blocks to other peers. When the time comes, the attacker will distribute the whole fork at once. So instead of "51%" we should read "49%" or even less. After the 15th of May, when blocks become bigger, the rate of orphaned blocks will increase. This means that instead of "49%" we'll get "45%" or less.

I created this thread to attract attention to the following issue:

Increasing the blocksize limit we increase odds of a successful forking attack.

Excellent observation. But the principle extends even further than that.

By increasing the blocksize limit miners spend more money the overhead of handling those blocks, like expensive VPS servers at datacenters, and less money on actually mining. Gavin for instance thinks we'll very soon see it impossible to run a validating node without spending around $100/month on a fast rented server in a datacenter. That's money I could have spent on my mining rig defending Bitcoin against an attacker.

Of course that isn't going to magically make fees low either. All that fancy equipment has to be paid for someone, and you'll soon find you can't even access the Bitcoin network without paying access fees:

https://bitcointalk.org/index.php?topic=197169.0

[jdbtracker]

wow, that is a serious problem J.

I'm also thinking what if someone did a regional attack? simply started gaining access to the fastest routes on the network and could in effect propagate invalid blocks faster, each node that took the transaction would bloom creating a fork, ... is there any way to map this? Can we observe the bitcoin network through it's nodes? watch visually which bits of data are traveling faster than others or visualize unconfirmed transactions through the network?

What if we can map the flow of data geographically? mapping the fiber optic cable lines; this could be a game changer.

[jdillon]

What if we can map the flow of data geographically? mapping the fiber optic cable lines; this could be a game changer.

Right now that's really hard to do. People run Bitcoin over Tor and mine over Tor all the time.

But with big blocksizes it'll be very easy to governments to figure out where Bitcoin nodes are just by watching for the huge burst of traffic every time a block is created as Bitcoin miners madly rush to send their block all over the world. All you have to do is block those bursts of traffic, or even just slow down traffic at the right moments for the right servers, and a 51% attack turns into a %10 attack.

Unfortunately Bitcoin is *really* susceptable to traffic analysis because of how new blocks need to be propagated around the world instantly.

[jdbtracker]

What if we can map the flow of data geographically? mapping the fiber optic cable lines; this could be a game changer.

Right now that's really hard to do. People run Bitcoin over Tor and mine over Tor all the time.

But with big blocksizes it'll be very easy to governments to figure out where Bitcoin nodes are just by watching for the huge burst of traffic every time a block is created as Bitcoin miners madly rush to send their block all over the world. All you have to do is block those bursts of traffic, or even just slow down traffic at the right moments for the right servers, and a 51% attack turns into a %10 attack.

Unfortunately Bitcoin is *really* susceptable to traffic analysis because of how new blocks need to be propagated around the world instantly.

Yes that's what I'm worried about, someone or something, gaining control of central propagation routes, a p2p distributed attack at key points, There are data centers that monitor all traffic at key points, the super fast nodes that are located at major geographical areas, the network still propagates from other lines... slowly, but the\ose lanes could pummel legitimate traffic that is propagating slower through distributed channels effectively creating a buffer zone of control, what about satellites? they can propagate key data very quickly at the speed of light! across the planet! who has control of these hubs?

[Come-from-Beyond]

Consequently, the issue, once it becomes important, can be solved.

Everything can be solved. But it should be solved BEFORE someone makes a successful attack.

How?

I don't know. U should ask Satoshi Gavin.

[virtualmaster]

From https://en.bitcoin.it/wiki/Attacks#Attacker_has_a_lot_of_computing_power:

An attacker that controls more than 50% of the network's computing power can, for the time that he is in control, exclude and modify the ordering of transactions...

That's almost correct, but it doesn't take into account orphaned blocks. Each orphaned block is wasted hashpower.

That is correct.

An attacker won't have orphaned blocks at all, coz they don't need to distribute found blocks to other peers.

This assertion is completely obscure. Orphaned blocks are not belonging to the attacker or to anybody. They are just not included blocks in the main chain.
If the attacker makes a double spending then one of his transactions will be always orphaned even if he has success with his attack, by success he have just done a cashout from his transaction in the orphaned block.

When the time comes, the attacker will distribute the whole fork at once. So instead of "51%" we should read "49%" or even less.

There is always a probability of success even if the hash power is lower than 51% even by a very small block size.

After the 15th of May, when blocks become bigger, the rate of orphaned blocks will increase.

If the number of included transactions/block is higher than is always a higher rate of orphaned blocks no matter what is the date. Supposed than the other network parameters and attack rate/transactions probability remain the same.

This means that instead of "49%" we'll get "45%" or less.

I cannot follow how you calculated so exactly and I cannot discover any logical connection to the former points.

I created this thread to attract attention to the following issue:

Increasing the blocksize limit we increase odds of a successful forking attack.

This is also not evident from the former argumentation. There only seems to be a connection between the number of transactions(which is influenced by the number of transactions/block) and the number of orphaned blocks. But why should be a direct connection between the number of orphaned blocks and the probability of successful attacks ?

[Stephen Gornick]

even just slow down traffic at the right moments for the right servers, and a 51% attack turns into a %10 attack.

Source?

[BitshireHashaway]

You guys realize that even though the network power is 90th/s as of now and will increase rapidly as Asics come online, if a 10% or 51% attack is possible, someone will gain enough control to do it, regardless of whether or not they abuse their power. A company will realize the profits  a lot and purchase a ton of Asics to gain full control of the network.