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.
Topic: 51% attack is a myth - page 2. (Read 3148 times)
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.
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://bitcointalksearch.org/topic/how-you-will-pay-for-bitcoin-network-access-services-in-the-future-197169
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 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.
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.
I created this thread to attract attention to the following issue:
Increasing the blocksize limit we increase odds of a successful forking attack.
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?
I created this thread to attract attention to the following issue:
Increasing the blocksize limit we increase odds of a successful forking attack.
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.
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.
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://bitcointalksearch.org/topic/m.984376.
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.
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://bitcointalksearch.org/topic/m.984376.
From https://en.bitcoin.it/wiki/Attacks#Attacker_has_a_lot_of_computing_power:
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.
Quote
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.
i'm not seeing much of a problem.
From https://en.bitcoin.it/wiki/Attacks#Attacker_has_a_lot_of_computing_power:
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.
Quote
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.
Jump to: