Attacks in the World of Cryptocurrencies
You must have heard of "51 percent attack", "double spend" and other frightening phrases that disturb cryptocurrency-related communities. Although such caution is not unfounded, the fuss together with ignorance give rise to numerous rumours. Are Bitcoin and other digital currencies in danger? Let's clear things up and review the most widespread attacks that might affect the sphere.
We cannot help starting with the most familiar attack, which was described in the article by Satoshi. This one covers a situation when someone (one person or a group) has more than half of all the mining powers in the network.
It is widely known that "cryptocurrency is protected by mining". What does it mean? How, and against what is it protected? Mining is a process of creating new blocks. Why are those needed? Technically, they are needed for identifying "good" and "bad" transactions. If Alice tries to send the same money both to Bob and to Carol, theoretically, it does not matter, which of the transactions is "correct". What matters is that there should be only one. Each miner should decide: choose the one that appeared a second earlier, or the one with a larger fee, or the one with a nicer hash etc. If there are many miners, we see a distributed consensus.
A node that stayed offline for a while and is slightly behind time, gets a history of "good" transactions at the moment it gets back online. If there are alternatives, i.e. two versions of blockchain, it will select the version where more work was performed. Therefore, an owner of the majority control can decide single-handedly, which transactions will be "accepted", and which will not. Almost like your bank.
There is an even more unpalatable option: attacker might change his mind and rewrite the complete block history starting from some point in the past. As he possesses the majority control of the network powers, it is but a matter of time when he catches up and overtakes the other chain. As a result, "good" transaction will become "bad" and vice versa. The money you have received a month ago will disappear from your wallet and get back to their owner. It is almost similar to your bank account.
- Attacker can: "prohibit" individual (or all) transactions from getting to the blockchain; cancel old transactions (return the money); make canceled transactions valid again.
- Attacker cannot: manage other people's money (reroute or steal transactions); prohibit nodes from exchanging other data.
Another talk of the town. Actually, it is not a particular attack but rather a notion used for naming different actions that might allow the cracker to use his already-spent money for a second time (return them or spend once again). There are the following scenarios for this:
Race Attack. The attacker sends transaction A paying for the purchase. Simultaneously, he sends transaction B transferring the same money to another account of his. If a shop does not wait for the money and ships the purchased goods, it undertakes a significant risk: transaction B might get to the blockchain with 50% probability, and without any efforts from our cracker. Even worse, he can increase this rate by selecting the nodes to send one or another transaction. Calculations for this can be found in this document. That is why we should not trust the unconfirmed transactions, m'kay?
Finney Attack. Now, let us provide the attacker with some mining powers. He tries to find a normal block that would contain his transaction B. The main point here is that neither transaction A nor B are sent yet. As soon as the block is found (sooner or later, depending on his processing powers), he sends... transaction A! He buys some goods in the shop. The latter, sadder but wiser, waits until a block with transaction A appears in the network. As soon the block is found, it ships the goods and... here comes the block with transaction B that was found by the cracker. This results in so called fork, when the miners should select the version to be continued.
If they select on a non-random basis (which alone guarantees 50% success!), the attacker can raise his chances under some conditions. Therefore, even a transaction with 1 confirmation might not be safe.
Now, let us provide our cracker with A LOT of mining powers, but still not 51%. What happens now? He can prepare not one block, but a few in order to overtake the "honest" chain. Probability of this event is not high, but the attack described above will be 100% successful. For example, if he has 10% of hashrate, than, once every 100 blocks (more than once per day!) he can find two "fast" blocks in a row and commence his attack. Now, the shop waiting for two confirmations is in danger again! How many confirmations do we need based on the potential of the attacker? Detailed estimations can be found in this article, but Satoshi himself answered this question: "six confirmations would suffice for all".
In a manner of speaking, this attack is an evolution of the previous scenarios regarding the double spend. However, in this case, the cracker will aim not for simple cheating with the purchases, but for control of the network while having less than 50% of the powers.
It starts like this: some pool owned by the cracker claims that "mining here is more profitable than on other pools". Let us assume for a moment that this is true. What will common miners do then? Most probably, they will come to the pool and start mining. As a result, the pool gains 51% at once. Of course, every miner realizes that, by joining a large pool, he brings this moment nearer thus endangering the system that makes his profit. Unfortunately, this is human nature, so, when everyone makes decisions on his own, the outcome is mostly deplorable.
Here comes the question: how a pool can be more profitable? Naturally, the attacker would not pay out-of-pocket to compensate for the difference.Although it might be more cost-effective than buying 51%, still, it is quite expensive. Now, we will describe an algorithm from the article that allows one pool to get a bit more than any other common pool regularly.
The pool is mining in secret, always aiming to continue its private chain. At some point, the last blocks of private and public chains might be similar, but such moments are quite rare.
When a pool finds another block that enlarges its private chain, than:
- If the blockchain is forked at the moment, than the pool publishes its own block and wins the race. The block found by honest miners becomes an orphan and their work is wasted.
Fork situation, means that BlockN is already published to the network
- If there is no fork, the pool keeps this block secret and continues working on extending its chain (thus increasing the breakaway)
Attacker is winning in this situation, but the network is still mining BlockN chain
If the rest of the network finds a block for public chain, than:
- If the public chain is ahead of the private one, the pool "throws away" its non-published blocks (if any), and starts a new private chain from the new block. This is the most unlucky scenario for the pool as it has to dispose of a part of its work.
Attacker lost and starts a new private chain from the "New Block"
- If the public chain is equal in size with the private one, the pool publishes all its blocks at once. This way, it cause the blockchain fork and wins it with some probability. here, everything depends on the response time of the pool, because common miners will continue the chain they get first. If the pool, for example, has access to all nodes in the network, than it will broadcast its chain before the fresh block is distributed.
Attacker publishes all blocks that are located in private chain and the fork begins. Chain that finds the next block - wins.
- If the public chain is behind the private one by N blocks, than the pool sends N+1 blocks, instantly making the fresh block of the network orphan (so the network wastes its work again).
Attacker publishes all blocks that are located before BlockN+3* and keeps the rest of the blocks in secret.
The main goal of this attack is to make the network waste its resources. It happens every time when there is at least one 'private' block: the normal network does not know that it is behind, and mines for a block that will be orphan with quite high probability. Naturally, the pool will lose money sometimes, when it does not publish its own block, which, in its turn, becomes orphan after losing the race. However, according to the calculations presented in the article, this tactics on average proves more profitable than normal mining. Notably due to the fact that the honest network is going to lose blocks as orphans.
Therefore, every reasonable miner finds it more profitable to join the pool rather than lose resources on other pools. Which was, actually, the goal of our cracker.
So, how this attack can be countered? First of all, there is hope that in such case our reasonable miners will count two steps ahead and realize that by earning 1 cent after joining the pool they lose dollars after the network is compromised following 51%. Second, the model we described only provisions one attacker. What if all pools implement this algorithm? As logic suggests, if all participants act in the same way (even not honest one), this algorithm does not give any advantage.
Actually, this type is more common for p2p networks in general. In essence, the attacker tries to 'surround' the victim's node, i.e. make all the neighbours of the node belong to the attacker. After achieving this, he basically controls all the data, both incoming and outcoming: he can feed false data to the victim, or prevent him from sending something to the network. Moreover, the attacker can identify the transactions sent by this node.
Normally, achieving this is very hard: both Bitcoin's and other currencies' codes establish that the node selected other nodes for connection on almost random basis. Even if the cracker controls 80% of all nodes in the network, and we need to establish 8 random output connections, the probability of being completely surrounded is only 0.8^8 = 17%.
And yet it is possible, if we know how the algorithm for establishing connections works, and exploit its weaknesses. We will not go deep into details here, only describe the general idea. The vulnerability mainly lies in the fact that a node, when going online, does not know the IP addresses of the trusted nodes, and has no other option but to request them from... the trusted nodes. The problem of chicken and the egg.
Moreover, even if the list of trusted nodes is known in advance, one cannot maintain connection only with this nodes: not exactly a decentralized way, right? If we block the connections from new nodes and prohibit adding them to the list of trusted nodes, the network will operate very inefficiently (from topological point of view).
Technically, every node stores a list of all known IP addresses of other nodes. The following data is associated with them: when it was last seen online, how many successful connections with it were established, etc. If necessary, the nodes share parts of this list with their networks, thus updating the information.
At the start, the client tries to diversify its circle of contacts, connecting both to the known nodes and to the ones it has not 'tried with' yet. Although the process is randomised, this and this articles show how a cracker can make notebook of the victim contain almost exclusively the addresses of the cracker's nodes.
Fortunately, the authors themselves provide a number of recommendations for remedying the situation. As the discrepancies of a certain algorithm in the Bitcoin code are exploited, upgrading the algorithm should solve these problems.
This text was not intended to be an "exhaustive guide on attacks". Some points we might have forgotten, some were omitted on purpose, and there might be some unknown to us as yet. The fact of the matter is that there is no disruptive attack that could raze our infant industry to the ground.
Moreover, any new (described) attack is actually a great thing, since it helps to improve technology.
If you are interested in the cryptocurrency sphere, make sure to let us know what else you would like to know about it and we will throw light upon it: firstname.lastname@example.org