Dropping transactions

As every Bitcoin Node is free to act however it desires within the boundaries of the Bitcoin Protocol, some malicious Nodes can opt to transmit only certain transactions discriminating against the rest[127]. Moreover, any Mining Pool is also free to include any and all valid transactions in the Blocks it creates.

As the Standard Client usually makes 8 outbound connections to other Nodes (not counting any possible inbound connection), in order for malicious Nodes to be able to successfully stop certain Transactions from propagating through the network they would have to be in vast

41

majority. This would be possible with the use of cancer nodes (see 4.5.1), a very popular non- standard Client, or a malicious code being introduced into the Standard Client. A simple workaround could solve this problem if it was to ever arise by encouraging the Clients to relay their Transactions to some trusted fallback nodes.

While Bitcoin Pools that discriminate against some Transactions can’t stop them from propagating through the Network, they can delay them from having any confirmations until they are part of a Block mined by another Pool. Each time the malicious Pool solves a Block before other pools, the Transaction gets delayed further. Should the Pool have a majority of computational power, however, any Transaction could be delayed indefinitely (see 4.5.11). As Transaction fees are an additional source of revenue for the Pool solving a Block (on top of generation reward), not including a Transaction with a fee in a Block penalizes the malicious Pool. Even the inclusion of a Transaction without fees does not incur additional costs (asides hashing the Transaction and constructing a merkle tree with it as one of the leaves, computationally insignificant in comparison to solving a Block). Thusly this behaviour is counterproductive, unless carried out for reasons other than profiting at full potential from Mining.

Such malicious Pool activity was not seen in the Bitcoin Community until recent times [128], when a single Miner started producing Blocks without any additional Transactions. The problem was discussed by Satoshi Nakamoto in June of 2010 [129], suggesting that additional measures can be taken if it ever becomes a problem. However, unless the malicious Pool gains a large amount of computing power, such activities might at most be disruptive, but not destructive to Bitcoin’s functionality (see 51% attack 4.5.11).

4.5.11 51% attack

The security of the Block Chain depends on the amount of processing power of all the Miners in the Network. The 51% attack [130] assumes that a malicious attacker could secure and sustain a computing power bigger than all the other Miners combined. This would ensure with a high probability all the Blocks created will come from the attacker. Controlling the majority of the computational power would allow the attacker to:

 Control which Transactions will be included in the Block Chain

 Negate all mining effort done by any other Miner

 Reverse any and all Transactions that were included in any recent Block

This attack stems from the fact that the Bitcoin Client will always prefer to use the longest correct Block Chain if contrasted with a shorter Chain. An attacker controlling most of the computational power of the Network will eventually build up a longer Chain than any other Miner.

The attacker need not send all of its Blocks at once. Should it mine two Blocks ahead of any other Miner, it can store the Blocks and wait for any other Miner to advertise its newly created Block. Then, upon receiving that single Block, the attacker could release two of its

42

Blocks, creating a fork in the Block Chain. As the attacker’s Chain would be longer, the honest Miner’s Block will be discarded, and all Transactions included therein will be recycled by the Network. As all the Blocks that will be used by the Network will come from the attacker, they decide on which Transactions, if any, will be included in the Block Chain. Should the attacker choose to reverse any Transaction that is already included in the Block Chain, they would have to start overriding the Blocks starting from the one holding the given Transaction up until the current Block and then one more. Depending on how deep the Transaction is in the Block Chain, the process could take a considerable amount of time. The amount of time on average required to reverse a Transaction can be calculated from a formula:

Where t is the time, Speed1 is the computational speed of the attacker (in Shares per second), Speed 2 is the speed of the other Miners, Difficulty is the Difficulty of the Blocks (how many Shares it takes to solve the Block on average), and NumberOfBlocks is the number of Blocks one would need to override at the start of the attack.

As the computational speed of the Bitcoin Network at the time of the writing is 10.5THash/s [131], and the most cost-effective graphic card for mining is ATI 6950 (costing about $230, consuming 840Watts and giving 344MHash/s). It would require 30523 such graphic cards, costing over 7 million dollars (plus the cost of non-graphic card hardware) and consuming 25.6MW of power just to meet the current Network computation speed.

Given the cost of the attack, it is very unlikely to occur, but if sustained could cripple the normal operations of the Bitcoin Network. An attacker holding the majority of the computational speed of the Bitcoin Network effectively holds all of the computational power of the Network, turning it into a semi-centralised network.

There exists a possibility that a 51% attack could be launched by using a botnet [132]. Currently the biggest reported botnet is estimated to consist of about 230’000 computers [133]. However, as few of the older graphic cards support OpenCL which is used for effective mining, it is unlikely that many of the infected computers could reach any meaningful hashrates. A top-of-the-line CPU reach about 20MHash/s[30], putting the biggest botnet a potential speed of 4,6THash/s. Given that most computers would not use such hardware, the actual figure would likely be an order of magnitude smaller, however no specific data on the subject was found.