Cryptocurrency | Learn about mining pool attacks

1. Brief Introduction

Those who are familiar with blockchain-related technologies must be familiar with mining. This is the core of the consensus mechanism of proof of work. Everyone solves a cryptographic problem together to obtain a usable block header, thereby generating a new block. In the early days, you could participate in mining directly using your own computer. However, with the growth of the value of Bitcoin, more and more people participated. Large-scale GPU parallel mining provided a lot of computing power. Later, customized ASIC equipment further widened the gap with ordinary computers. As a result, the difficulty of mining also rose sharply with the growth of computing power. Now you have no hope of mining with an ordinary computer.

If you want to make money from mining now, you can only buy mining machines as mining equipment. When customized ASIC chips first appeared, they did cause quite a panic. After all, the performance of this thing is too terrifying compared to ordinary machines. Its computing speed is nearly one million times faster than your computer. This can easily lead to the centralization of computing power. In that case, the right to produce blocks will be controlled by one company and they can do whatever they want. This situation may not have been expected by Satoshi Nakamoto when he designed Bitcoin. Fortunately, mining equipment quickly became popular and widely distributed around the world. Bitmain, as a major mining machine manufacturer, is also quite powerful. This model should be said to have further stimulated the rise in Bitcoin prices.

Of course, with mining machines so common, if your strategy is still to mine by yourself to get block rewards, then it may be difficult for you to recover your capital, so mining pools have become the mainstream of mining power. Everyone is equivalent to mining under one node, and the mining pool distributes block rewards to everyone according to their contribution. In this way, everyone's income will be more stable, which is much better than fighting alone. This situation where the mining pool monopolizes the computing power has both advantages and disadvantages. Its centralized nature has been criticized. When Bitcoin was designed, it may not have been expected that such a situation would occur.

In addition, the cryptocurrency market is now flourishing. Some currencies use special mining encryption algorithms to counter ASIC devices, such as Monero. Because ASIC devices for this algorithm are difficult to design and the speed improvement is not that great, there is insufficient motivation to buy such devices. Some other currencies use different consensus algorithms such as POS and DPOS, which do not require mining to generate blocks. If you are interested in this aspect, you can learn more about it yourself. Let's get to the point.

2. Guarantee of mining pool operation

Everyone joins the mining pool to mine, and the mining pool must also take measures to protect its own interests. Some malicious miners must not be allowed to easily disrupt the operation of the mining pool, right?

Mining pool settlement model for revenue

First, let’s take a look at how mining pools distribute revenue. There are many settlement models on the market. We will introduce several mainstream methods.

Proportional This is a more direct reward mechanism. It uses the time from the last block discovered by the current mining pool to the next block discovered as a cycle, counts the shares submitted by each miner during this period, and then calculates the share of each miner, that is, the percentage, and then issues block rewards.

In fact, this can easily lead to a situation where the shares you submit to this mining pool will become less and less valuable as the time of a cycle increases, because it is uncertain when a block can be mined. If a block is mined at the beginning of a cycle, even if you only submit a few shares, you can get more income than submitting hundreds of shares later. It can be seen that this model is not healthy.

This model is the reward mechanism adopted by the early Bitcoin mining pool, but this model easily leads miners to adopt a pool hopping strategy to obtain more benefits. We will describe this later, so this model is basically abandoned now.

Pay-per-share (PPS) In this mode, the mining pool will pay the miner immediately according to the share submitted by the miner. The mining pool will distribute the income to you according to the proportion of your computing power in the mining pool and the estimated daily income of the mining pool's computing power. Generally, the cost of each sahre is fixed, so the daily income of the miner is relatively stable. However, in this case, the mining pool has to bear certain risks, so it needs to charge the miner a higher handling fee. This is also the price to pay for stability.

Pay-per-last-N-shares (PPLNS) PPLNS is very similar to PPS, but it uses N shares submitted before the block is found to distribute rewards. N is fixed, but it is uncertain when the block will be found. Therefore, if the total shares are greater than N, some of them must be discarded, and if they are less than N, some of them must be calculated repeatedly. The advantage of this is that it avoids the continuous depreciation of shares in Proportional, and thus prevents miners from jumping pools.

Slush's Method This method is an improvement on Proportional. The original intention was to counter the pool-hopping strategy. It calculates points based on the shares submitted by miners, and the points of each share continue to increase with the growth of time. This is a partial compensation for the low reward of the last share in the longer period of Proportional. However, this method does not completely eliminate the impact of Proportional. When the interval between two blocks is short, each share is still very valuable. In theory, there is still the possibility of pool-hopping.

Geometric method is a further improvement of Slush's Method. It also scores shares. The later the shares, the more points they get. However, the way the points grow is different. Here, they grow exponentially. So the return of each share decreases exponentially over time, which curbs the value of the shares submitted earlier.

Of course, the specific algorithm design needs to be more sophisticated. The expected reward calculated in the end is the same whether or not the pool-hopping strategy is adopted, so the pool-hopping strategy attack can be completely avoided.

In addition to these methods, there are many other reward distribution modes, such as MPPS, SMPPS, ESMPPS, etc. I will not introduce them one by one here. Those who are interested can learn about them by themselves.

Block rewards that cannot be taken alone

Some miners may think that since everyone is mining together, when I mine a block, I will keep it and not submit it to the mining pool, but broadcast it myself, so that I can take the block reward alone.

It should be pointed out that although this idea is very dangerous, it is not feasible, because when we mine, we are actually calculating the block header that meets the requirements. This block header contains the block reward income address of this block. When this block is confirmed, only the address in the block header will receive the block reward. When the mining pool distributes the mining task, the receiving address of the block reward has been written, so even if you broadcast it privately, you will not get any income. If you tamper with this address during the calculation, it becomes your personal mining, and it has nothing to do with the mining pool, so this path is currently not feasible.

The reason why it is not feasible at present is that this ecosystem where large mining pools monopolize computing power has caused many people to worry. Some people have proposed to modify the mining algorithm to make it possible to modify the revenue address in the block header. In this way, the miners under the mining pool may choose to broadcast blocks privately, thus causing the mining pool to collapse. Of course, I think it is just a thought, after all, it involves too much.

The mining process cannot be lazy

After finding out that it is not feasible to monopolize the block rewards, some miners will think that since the final distribution of the income is based on everyone's computing power, then if I don't do any calculations and just submit a random value, can I get away with it? Wouldn't it be possible to save a lot of money by faking computing power?

This idea is still very dangerous, but it is not feasible. What we need to know here is that when the mining pool distributes tasks, it does not let you directly calculate the block hash that meets the mining requirements. They often set a lower difficulty target. For example, if the hash of the block header that meets the requirements must satisfy the first 16 bits to be 0, the task given to you by the mining pool may only require the calculated hash to satisfy the first 10 bits to be 0 and then submitted as a share. Generally, the mining pool will also do a verification. Because the difficulty coefficient of this task is relatively low, it can basically guarantee that you can submit shares frequently, which also provides help for the subsequent analysis of your submission records to discover block deduction attacks. We will talk about the details later.

As for how such a low-difficulty task can satisfy the need to calculate a block header that meets the requirements, it is a matter of probability. The mining pool sets this goal to ensure that everyone is performing calculations and actively submitting shares. As long as everyone is calculating, there is a probability of encountering a block that meets the requirements. For example, this time you complete the task and submit a block with the first 10 bits of the hash being 0, the next time you mine a block with the first 12 bits of the hash being 0. If you keep mining, you will always encounter a block header that meets the requirements.

3. Types of Mining Pools

Managed mining pool

Hosted mining pools should be considered the current mainstream, that is, a mining pool has a central server to coordinate and manage all its subordinate mining machines. At the same time, this server will generally synchronize with one or more full nodes, so that it can help subordinate miners complete the verification of blocks, thereby alleviating the pressure on mining machines. After all, a complete block copy is still very large, so miners can also invest more computing power to obtain more profits

p2p mining pool

Because the administrators of the hosting mining pools may cheat, especially those large mining pools, if they have the intention, they can control the direction of the block, so p2p mining pools appeared later.

As its name suggests, this mining pool has no central server. Instead, it uses a blockchain-like system called the share chain. Miners mine on this chain, which is much less difficult than Bitcoin, with one block every 30 seconds. Everyone calculates here and the share chain counts the share. When the hash of a block header on the share chain meets the difficulty requirement of Bitcoin, the block is considered a successful mining result and will be broadcasted. Then the share chain will distribute the block reward according to the counted share. In fact, a central server is implemented using a blockchain system.

However, this type of mining pool is much more complicated than the managed mining pool, and its efficiency is relatively low, so it is gradually fading out of the market. After all, capital always pursues profit.

4. Mining pool attacks

Let’s take a look at the main threats that mining pools face.

Pool hopping

We have actually mentioned this several times before. For the Proportional reward model, if a mining pool is unlucky and has not mined a block for a long time, the shares of the miners in this mining pool will begin to depreciate, which is equivalent to the computing power becoming less and less valuable. At this time, some miners can choose to transfer their computing power to another mining pool that has just mined a block to mine, because at this time the time has just begun to be calculated, and the value of each share is relatively high, which is equivalent to the computing power is also more valuable. If it has not been mined for a while, he can also choose to jump to the pool again and keep looking for a place with a higher share value. As for how much the computing power consumed before is worth, you don’t need to worry too much.

Statistically speaking, the final profit obtained by adopting this strategy is definitely much greater than the profit you get if you stay in a pool all the time. However, with the change of the current mining pool's profit distribution strategy, this attack strategy is no longer feasible.

Block withholding

The next thing to talk about is the block withholding attack. In fact, it should be regarded as a type of mining strategy, that is, after mining a block, whether to keep it for a period of time or discard it directly. This strategy will be adopted by different people for different purposes, but it is not a good thing. Let's analyze the possible situations below.

Selfish mining In this case, miners or mining pools do not broadcast the blocks immediately after mining them, but keep them in their hands for a period of time.

For a miner, he can distribute his computing power to various mining pools. Once he mines a block in a certain mining pool, he will keep the block, and then concentrate his computing power on this mining pool for mining, accumulate shares, and then submit blocks to obtain more benefits. Of course, in this case, it is possible that others may also mine blocks during this period and publish them, so there is still a certain risk, but from a statistical point of view, using this strategy will still increase profits.

The situation is more complicated for mining pools. After obtaining a valid block, the mining pool can choose to keep the block. Then, it can invest its computing power in the next wave of block mining, which can be regarded as a preemptive move to a certain extent. Then, it will immediately synchronize the mined block to its nodes instead of broadcasting it to all nodes.

Then the mining pool can monitor the network situation. Once a new block header is found, the node on hand will immediately broadcast its own block, causing other mining pools to lose the reward of the block. In fact, this risk is still a bit large, unless the mining pool has a large enough computing power and can always be in an advantageous position. In addition, the impact of network transmission efficiency must also be considered. Generally speaking, it is enough to choose to keep the broadcast block for a period of time.

The mining pool adopting this strategy will reduce its own income in the short term, but it will also suppress the income of other pools, or even lose more. Other honest miners may also switch to the selfish mining pool to obtain more income, which will strengthen the computing power of the selfish pool, further aggravate this phenomenon, and allow the computing power held by the selfish pool to continue to increase, even crossing the 50% red line. The consequences are very serious.

However, due to various reasons, this type of attack is still rare. At present, it is mainly theoretical research. In an ideal model, a mining pool with only 33% computing power at the beginning can gradually increase its computing power to 50% by gradually adopting this strategy.

Let’s look at the case where a block is mined but not discarded directly. As you can see, this is a destructive attack, which can also be divided into several cases.

0x1. Malicious sabotage by miners

In this case, miners do not publish blocks they have mined in the mining pool but directly discard them. However, shares are still submitted normally. This means that the miner has not created any income for the mining pool, but has been participating in the dividends of other honest miners' mining results. This behavior is obviously harmful to others and not beneficial to oneself. Generally, no one will use it. It is only used as a possibility here.

0x2. An attack mining pool

The malicious miners we discussed above work for themselves. The malicious miners we are going to introduce here work for other mining pools. For simplicity, we assume that there are two mining pools A and B, and A sends malicious miners to attack B.

This model is relatively simple. Let's assume that the total computing power is 1. Pool A uses x computing power to penetrate into block B to attack. Obviously, this x computing power is just lying there without doing any work. So at this time, our total computing power is actually 1-x.

Then we assume that the computing power of A and B is Ma and Mb respectively, then the probability of B producing a block is Pb = (Mb-x)/(1-x), so A gets the block reward from B

Pb*x/Mb

Mining pool A can also get a portion of the block rewards if it mines honestly.

(Max-x)/(1-x)

So the total revenue obtained by mining pool A is

Q=Pbx/Mb + (Ma-x)/(1-x) = (Mb Ma - x^2)/(Mb(1-x))

This is the profit obtained by mining pool A after the attack. Theoretically, mining pool A can increase its profit by selecting an appropriate x to attack. However, when this idea was proposed, the profit before the attack was simply expressed as Ma, that is, the computing power of mining pool A. Recently, I read a paper that showed that this assumption is not rigorous. In fact, as the attack progresses, the computing power of the system decreases and becomes 1-x. Under this computing power, the block speed of the entire system will also decrease. This means that the number of blocks mined in the same time under two different conditions of attack or not is different, and the difficulty adjustment cycle of Bitcoin is 201 6 blocks, nearly two weeks, is a very long span. The time difference will bring a lot of losses. If you want to make back the money, you have to maintain the attack until the difficulty changes. However, it is very difficult to keep the attack undetected for such a long time. After recalculation, it is found that simply attacking B with block interception is a disadvantageous behavior. This also explains in some ways that the report that this attack has been confirmed is very rare. The main one is that Eligius mining pool confirmed this attack once in 2014, and lost 300 bitcoins. The loss here refers to the loss of the mining rewards that should have been obtained. This may be a combination of other attack methods or a retaliatory attack.

0x3. Two mining pools attack each other

This situation is more complicated. It may be that a mining pool finds out that it has been attacked and retaliates against the attacking mining pool in its own way. It may also be that the two pools have ill intentions and are fighting each other.

For simplicity, let’s assume that there are two mining pools A and B. They both launch block interception attacks on each other. Once this war begins, unless both sides stop at the same time, they will easily fall into a prisoner’s dilemma. It’s very interesting. Now let’s talk about game theory.

I think everyone has heard of the prisoner's dilemma. Here is a simple example.

Now the police have arrested two suspects, A and B, who were part of a gang, but because there is not enough evidence to charge them, they are being interrogated separately.

If both plead guilty, they will each be sentenced to five years. If neither pleads guilty, they will only be sentenced to six months due to insufficient evidence. However, if one party pleads guilty and the other does not, the guilty party will be released immediately and the other party will be sentenced to ten years.

This is a very classic prisoner's dilemma scenario. Here, it is assumed that both parties are selfish and do not care about the other party's life or death. Then they must consider their own interests completely. Then, if you make a choice,

1. If the other party does not plead guilty, then I can be released directly if I plead guilty. OK, choose to betray

2. If the other party pleads guilty, then if I don't plead guilty, I will be sentenced to ten years. No, I have no choice but to plead guilty. Okay, I still choose to betray.

If both parties think in this way, the final result of the game will be mutual betrayal, resulting in each party being sentenced to five years in prison, which is the Nash equilibrium reached by the game. Although the optimal solution for the group should be to keep silent in order to obtain a six-month sentence each, this is exactly the dilemma.

The same situation actually occurs in the game between the two mining pools here.

The two mining pools have to choose whether to attack or not. If neither of them attacks, the revenue will not be affected. If one mining pool attacks and the other does not, the revenue of the attacking mining pool will increase and the revenue of the victimized mining pool will decrease. If both mining pools attack, the revenue will decrease, but not as much as when the victimized mining pool is attacked. At this time, we still assume that both parties adopt a self-interest strategy. According to the above analysis, without knowing the other party's choice, the two parties are very likely to choose to attack each other, thus falling into the Nash equilibrium of the prisoner's dilemma.

The above game is just a simple analysis. The mutual attack between the two pools is more complicated. When the computing power of the two pools is different or the same, the proportion of computing power they need to invest and the final benefits are also different. In other words, the Nash equilibrium balance point is different. Due to the limitation of space and level, I will not elaborate on it here. If you are willing to study it in depth, you can learn about it yourself.

Moreover, in theory, this kind of attack dilemma is unavoidable. Only when the computing power of one of the two parties accounts for more than 80% of the total computing power can the game gain benefits, that is, the attack can be avoided. Of course, this situation almost never happens.

In addition, there is actually one thing that needs to be paid attention to in this attack mode, that is, to prevent the birth of spy miners. Mining pool A sends miners to infiltrate mining pool B. When mining pool B attacks mining pool A, if it does not check, it may send the miners sent by mining pool A back. In this way, these miners become spies. Mining pool A will naturally be happy to see this happen. The miners sent by B will work honestly under A and submit blocks, causing mining pool B to suffer heavy losses. Therefore, to guard against mining pools, you need to have your own soldiers, that is, verified loyal miners. This is not a problem for general mining pools. They have a large number of mining machines for rent or sale, etc. Of course, the specific scale is unknown to ordinary people.

0x4. How to detect

This type of attack is actually very difficult to detect. At present, the common practice is to calculate the computing power of the shares submitted by the miner, and compare it with the number of blocks he actually found to see if there is a problem. However, this method is indeed very limited in effect, because it is possible that the other party is really unlucky, and the attacker often splits the attacked miners and uses many accounts to mine. In this way, the corresponding computing power is even smaller and the uncertainty factor is greater. Unless the statistical period is long enough, it is difficult to find the specific source of the attack, and you can only passively take the beating.

0x5. How to prevent

The most likely solution to the block interception attack currently proposed is to change the mining algorithm so that miners cannot verify whether the obtained share is a block solution that meets Bitcoin requirements, so that they cannot choose to discard it. The following is a possible way

Three additional fields are added to each Block - SecretSeed, ExtraHash and SecretHash. ExtraHash = hash(SecretSeed) ExtraHash is part of the block header and will also participate in the calculation of blockhash. SecretHash = hash(BlockHash + SecretSeed) Previously, a valid block required the first 32n bits of BlockHash to be 0, but now it is also required that the first 32 bits of BlockHash be 0, and the first n bits of SecretHash be 0. Because miners do not know SecretSeed, they cannot calculate SecretHash and will not be able to verify whether the block meets the requirements. They can only submit shares after finding a BlockHash that meets the requirements, and the mining pool will complete the verification of the block.

5. Final Thoughts

In the above article, we discussed the attack methods against mining pools, which is quite interesting. In fact, most attacks are against hosted mining pools. It seems that P2P mining pools are relatively safe, provided that P2P nodes are well protected. Otherwise, if attackers infiltrate and modify the code, the computing power of subordinates may also be stolen. In addition, the performance gap is also a major obstacle, which is a pity.

In addition, there is actually a lot of content to explore behind the block interception attack. This article only talks about a simple attack model. Students who are interested can continue to explore it in depth.

Finally, I want to say that apart from write-ups, I rarely write such long articles. The logic may not be clearly expressed and there may be some omissions. I hope the big guys can give me more advice. If you have any questions, please feel free to contact me.