Title: "ARE MINING POOLS BECOMING A PROBLEM?"
Author: Bitcoin Mechanic
Translator: Luccy, BlockBeats
Editor's Note: Mining is one of the solid and elegant designs designed by Satoshi Nakamoto, and it is also one of the most remarkable aspects of Bitcoin. However, mining is not just about hash calculations.
Bitcoin advocate and educator Bitcoin Mechanic delves into the various issues and challenges in Bitcoin mining, with a particular focus on the dynamic relationship between mining pools and miners. He proposes solutions to existing problems, focusing on increasing miners' autonomy and the overall trend towards decentralization.
The discussion of the StratumV2 protocol and the future development of the mining ecosystem is full of unique insights. In addition, the article points out the latest developments in ASIC manufacturing and mining pool infrastructure, providing new possibilities for decentralization in the mining field through critical analysis of existing mining patterns and prospects for potential improvements in the future.
Bitcoin miners provide a crucial service to the entire ecosystem. As part of ensuring network security, they receive rewards from the network, which is one of the solid and elegant designs designed by Satoshi Nakamoto and one of the most remarkable aspects of Bitcoin.
However, it seems that more and more people are overlooking the fact that mining is not just about hash calculations.
Those involved in the process must run a node to obtain the latest state of the blockchain and then begin constructing a new block. This includes validating the validity of the previous block, discovering unconfirmed transactions, and typically selecting the most profitable transactions. They pay themselves in the generated transactions, construct multiple Merkle trees of these transactions, and finally perform hash calculations to actually solve the block. The transactions in the block template will continue to change as new transactions are broadcast to the network. When others find a new block, miners must switch to building on top of it and dump all transactions already in the blockchain to fill a new template.
Fork Activation
As you can see, performing hash calculations to actually solve a block is only part of this process. Bitcoin mining ASICs can only perform hash calculations. In the current environment, all other aspects of mining are often delegated to mining pools. This leads to some confusion. For example, in any discussion of a soft fork activation through a version bit flip within a block template, people always mention this process as a MASF, i.e. "Miner Activated Soft Fork," and there are always those who will point out that this is the full responsibility of the mining pool, not the miners. They may also point out that miners are ultimately responsible because if they want to upgrade but their pool does not, they can simply switch pools. For clarity, in the rest of this article, I will only refer to those who only engage in hash calculations and leave all other aspects of mining to the pool as "hashers."
Returning to soft forks, in the current environment, over 99% of blocks built by the same organization, more accurately called "pool-activated soft forks," may be more accurate, although no one currently calls them that, leading to a dangerous illusion: mining can be considered decentralized only because of the distribution of hash power. When all hash power is limited to a few pools, this claim becomes untrustworthy, so the content of the Bitcoin blockchain will ultimately not include anything that these few entities find unacceptable, as well as a range of other issues.
By only performing hash calculations on blocks built by the pool, Bitcoin miners have largely relinquished a key part of their role. This is not only possible, but it is the smoothest path, indicating that we have systemic problems.
Mining Pools and Block Space Market
The impact of only performing hash calculations and letting the pool handle everything else goes far beyond soft fork activation. For example, miners currently have no idea what the solved block will look like, meaning miners are working blindly trusting that the block only contains expected transactions. But in blocks like this, you will see a blatant violation of this trust, which sparked the "sequence" frenzy. Note that the miners working on this block actually only enjoyed about $200 in Bitcoin transaction fees, while the average transaction fees on either side of the block reached about $5000 in Bitcoin.
Block space has value, which is part of why Bitcoin operates in the long run. But in a world where only a few participants can make their templates eventually enter the blockchain, these entities have almost exclusive rights to sell this space and gain excess returns. Do they have a responsibility, or even possibly confess to their miners that they are doing this? Certainly, in this case, the intent is to surprise everyone. In the future, will they forward the funds they receive for selling off-chain block space to their hashers?
In short, while the incentives of mining pools and their hashers are usually aligned to maximize profits, pools may sell block space to obtain something other than regular Bitcoin transactions, and miners' income is more limited unless the pool chooses to be transparent and agrees to share the revenue. Even if they do, validation needs to be approved by the pool, not funds earned from subsidies and transaction fees (tricky when using FPPS pools, detailed later).
Further, the impact of mining pools as builders of centralized block templates in Bitcoin stems from a more fundamental fact - at a more basic level, there are twelve "super nodes" with their own "super memory pools."
This leads people to deal directly with the pool, completely ignoring the memory pool. Some believe that the memory pool is doomed to fail anyway. The current centralized template construction status only accelerates this process, but in any case, it is not desirable, and in a world where truly decentralized template construction is considered feasible, making this assumption may be too pessimistic. Then, if those buying block space want to include it in the blockchain within the same timeframe, off-chain payments must be passed on to a larger audience. This may be more transparent, similar to the current working method. Instead, "super nodes" are likely to be broken down into smaller parts, so they will no longer be able to provide the same guarantees.
To deviate from this aspect of mining, let's focus on how the current payment methods are handled.
Mining Pool Payment Model
Almost all pools pay their hashers through FPPS (Full Pay Per Share) or similar methods. The only exceptions are ViaBTC, which offers PPLNS (Pay Per Last N Shares) in addition to FPPS. Antpool also offers PPLNS, but hashers must forego all transaction fee income, indicating the point I am about to elaborate on. Basically, in a world focused on transaction fee income rather than subsidies, FPPS is not a well-functioning model. It is worth noting that Braiins pool (formerly Slushpool) uses a system called "score," which is actually very similar to PPLNS.
Why such a strong preference for FPPS? From the hashers' perspective, they get paid regardless of what happens on the blockchain. This aligns with the purpose of pool mining, for more consistent income. FPPS provides more consistent payments because pools pay based on expected income and settle independently of the blockchain.
This makes life very easy for miners who want to minimize problems caused by interruptions in cash flow, but of course, there are drawbacks - significant drawbacks that I hope to emphasize here.
First, FPPS requires the pool to become the custodian of all newly mined bitcoins. These bitcoins cannot be forwarded to miners within at least 100 blocks after mining, so the newly mined bitcoins are not usable until then, and in fact, the mined bitcoins are unrelated to what the miners ultimately receive when withdrawn from the pool. The risk of third-party custody should be obvious to almost everyone reading this, so I will skip this point and continue to discuss other issues with FPPS.
The next concern comes from a more general problem, that FPPS pools are an important intermediary between hashers and the network itself. We have established that hashers cannot know in advance what the block they are working on will look like until it is solved. FPPS means they don't even care if a block is found, which is the pool's problem. Ignoring the increased predictability of payments (which will never happen if the pool decides to deceive hashers), we must acknowledge the trade-offs of doing so.
Miners paid directly by Bitcoin itself - as possible in alternative schemes such as PPLNS or solo mining - can expect to receive full rewards, including transaction fees. An FPPS mining pool can only calculate this after the fact, as it is impossible to predict how much the fees will amount to when determining the actual amount received per share by the hashers. The pool cannot simply assume the fees will be some value greater than 0 and include it in the miners' income while mining, as they would simply pay it out of their own pocket if the fees are lower than this value. They must regularly allocate the fees and attribute them to the miners actually held in custody by the pool.
From the hashers' perspective, complete trust in the pool is required, as validation is almost impossible without the pool's full transparency and cooperation. As mentioned above, this was not a major issue in the past, as most mining income came from subsidies, and transaction fees were just scattered parts of the satoshis, but this is not, and cannot be, the future of the growing Bitcoin mining. In the future, miners will primarily earn income through transaction fees, which are more difficult to predict and monitor when using a pool than subsidies.
Compared to payment schemes like PPLNS, hashers accept greater variability (the pool's luck also becomes the hashers' luck), and we see that the mining ecosystem strongly favors payment consistency over the ability to validate the received content. More distorted is the fact that some hashers actually prefer this way - hoping to present themselves to regulatory bodies as a "hash service" completely detached from Bitcoin - some even take pride in it. This is because FPPS is far from the ideal miner/pool dynamic, making it difficult to describe what hashers are actually doing, even in "Bitcoin mining."
In reality, FPPS mining pools are large independent miners, paying hashers to solve their blocks. They then have an internal and opaque process to determine the amount paid to the hashers through this process. To truly illustrate this point, hashers could even (in some not too difficult to imagine scenarios) be paid in something other than Bitcoin.
Why not? If you don't care whether any blocks are found, let alone what they look like before they are constructed, why not just get paid in fiat currency by an independent miner who you conveniently point your ASICs to? Bitcoin is not always the most frictionless choice, but even so, it is reasonable to imagine continuing down a path where "hashing" can be performed by many entities you like, but all on behalf of a small group of "pools," and the entire network needs their permission to truly record anything on the blockchain.
Who is actually hashing?
Let's look at this issue from a broader perspective. We have mentioned that some larger participants want to distance themselves as much as possible from Bitcoin, so they are willing to delegate activities related to Bitcoin as much as possible to their mining pools. These pools are open to regulation, and their significant hash power is very satisfying to them.
This again introduces economic irrationality from the perspective of the network itself, manifested in the behavior of mining blocks that meet certain arbitrary standards. When this has happened in the past, it did not last long due to strong community opposition and the absurdity of trying to please a constantly changing regulatory regime without being asked to do so. But in fact, this option exposes the risks of centralized block template construction. Would a miner in one jurisdiction attempt to ban or refuse to process transactions from another jurisdiction? Are miners just an extension of government or influential bad behavior? There are specific examples that some pools refuse transaction fees for illegal gains, sometimes just to comply with regulatory pressure. From the network's perspective, this again appears economically irrational.
The most extreme recent example is the 19 BTC transaction fee paid in a single transaction, ultimately discovered by F2Pool, which appeared to be an error. As an FPPS mining pool, they became the custodian of this 19 BTC mining fee and chose to return it to the mistaken sender. This perfectly illustrates the cost of placing too large an intermediary between miners and the Bitcoin network. This situation is less likely to occur in PPLNS pools. Not because PPLNS pools are necessarily untrustworthy or non-custodial, but because it may be more difficult for them to attempt to monitor and verify fee income at the exact moment a block enters, as they may have already internally credited their share of the mining funds to the miners' accounts, causing a larger backlash. Although in principle there is no difference, until you compare what happens if a pool pays its miners for coinbase/generation transactions. In that case, the money is already in the miners' hands, and the pool cannot intercept the fee income. Therefore, in this example, the pool's attempt to appear generous or fair resulted in its miners losing $500,000 in fee income, a position it should not have made the decision in.
Next issue: 51% attacks and other attacks
This should be easy to explain: everyone knows what a 51% attack is at the moment. However, what people are far less aware of (until the network bypasses it) is that a 51% attack requires more than just the ability to cause destruction, but also the guarantee and sustained success of this attack method.
In fact, any entity with more than 20% network share can cause problems through various attack methods, some of which are executed in the wild but rarely discussed, which I will detail later. But before that, we can see that the network reliably has only two entities with total hash power exceeding 51%. What's worse is that one of the largest pools does not carefully conceal the additional 10% of blocks found through another large pool, which has a strategic partnership with its parent company. The fact that this farce is still ongoing is not convincing.
There are two common responses to this. First, people point out that miners can simply vote with their feet by changing pools if they unite to carry out a 51% attack. Secondly, any pool attempting to do so is crazy, for the simple reason that disrupting Bitcoin will lead to a price drop, and no one in the investment ecosystem wants that to happen. The second argument ignores human history and further assumes that people will never be forced to engage in destructive behavior simply for the sake of causing chaos or for other nefarious purposes. It also does not consider that the market does not necessarily always reflect a good indicator of Bitcoin's problems, as seen in the 2017 hard fork war.
However, the first argument is more solid, assuming that in the event a pool does indeed become too large, miners will always switch to other pools. In reality, if a large mining operation is constrained by red tape, this assumption is not as reliable, but let's at least assume we are fairly confident that such an attack is unlikely to occur.
Unfortunately, realizing that hash power from any pool will migrate elsewhere once it exceeds a terrifying threshold, causing them to self-regulate, does not help. This is because they do not need to actually maintain hash power below the threshold, they just need to give the impression to the outside world. This essentially means accepting all the hash power they can get, while forwarding it to other pools to avoid alerting the world to the chaos they can cause.
So, we have an unclear picture of the network's situation. 30% of blocks can be found by the largest pool and be accepted by everyone, while an additional 10% of the total network hash power still points to that pool, just secretly redirected to one or more smaller pools. The miners responsible for this 10% may not be aware of how it is being used, and it is more difficult to detect using stratumV2. I will explain this in detail later.
When considering that redirected hash power can be used to harm smaller pools through block mining attacks, this already less than ideal situation becomes even worse.
Specifically, attackers primarily participate in the mining process as normal users of the affected pool. As a result, they receive a portion of the rewards expected from any blocks found by the pool. The rewards ultimately flow to the attackers, who can then pay the actual miners without losing any funds. So far, the only harm caused is the mistaken impression of the pool's hash power, making it appear smaller than it actually is, but the smaller pools remain unharmed.
Now, if the attacker decides not to inform the affected pool when a block is found, harm occurs. This makes the affected pool appear less lucky. They seem to find fewer blocks than they should and pay out more rewards to participants who are actually honest miners, resulting in inevitable losses, assuming they do not make up for these losses in other ways.
If FPPS pools are attacked in this way, they must burn income and pay miners out of pocket to make up the difference. If it's PPLNS, miners would wonder why they didn't get what they were supposed to. Either way, block mining attacks are anti-competitive and could destroy the affected pool by bringing them a bad reputation.
From the perspective of the attacking pool, assuming they have 5% of the affected pool's hash power. This means they still receive 95% of the expected income, while the pool appears 5% less lucky than expected. This is enough to easily destroy the pool, and in larger pools, a 5% loss of redirected hash power would be far less significant. If it only represents 1% of the total hash power of the larger pool, the attacker only loses 1% of 5% - 0.05% of the expected rewards. This is a clear advantage for any malicious, fairly large-scale pool prepared to act unethically.
The smaller the pool, the more vulnerable they are to this type of attack. The larger the pool, the more likely they are to deter smaller competing pools. As large pools approach levels that cause community panic about their total hash power, this risk increases, further prompting them to at least hide their hash power in smaller pools, even if they do not actually use it for attacks or the frequency of attacks is not high enough to be attributed to variance. As the network provides more consistent payments, larger pools have already enjoyed reduced variability, meaning they can operate within tighter margins and charge their miners less. From the perspective of each unaffected miner/pool, this attack means they will enjoy lower difficulty, as the Bitcoin network adjusts to accommodate fewer total blocks.
Is block withholding just theoretical? Absolutely not. Even in the early 2015, several pools suffered attacks in this way. Preventing this attack is very difficult, as pools must monitor all miners and carefully decide whether to kick them out of the pool and/or refuse to pay them if their luck reaches statistically impossible levels, the pool can reasonably assume they are acting maliciously. This type of attack also incentivizes pools to want to "know their miners" and regulate payments, making life even more difficult for those who wish to mine without permission.
In any case, the overall effect of all this is that people are more willing to mine with larger pools for another reason.
We have heard large miners openly state that they are abandoning smaller pools because the payments they receive are not meeting expectations.
This is highly undesirable, as larger pools and the larger miners using them are more likely to be burdened by regulatory concerns, making them more likely to engage in behavior that harms Bitcoin, even surpassing the centralization of block templates and temporary custody of all block rewards.
Pools have effectively become agents, imposing bureaucratic nonsense on behalf of their miners. Currently, the two largest pools require users to go through a bunch of tedious steps, including processes that expose their identities, which should not and do not have to be required for people mining Bitcoin outside of solo mining.
On the subject of block withholding, another point is that, aside from the threat of making life more difficult for smaller pools and those who wish to mine with them, for those who still may try to dismiss it as purely theoretical, even though it has clearly happened in the past, do we believe that pools can naturally maintain a consistent and clearly tolerable size? This implies that new hash power online is always distributed somewhat evenly. We must believe that a pool can suddenly appear, grow rapidly, and then stop just before people start feeling uncomfortable. Do we see pools asking people to stop mining with them, or simply limiting account creation and kicking out miners who exceed the allowed hash power within existing accounts? Of course not.
The more likely of the two scenarios is that miners are collectively self-regulating. But this is unlikely, as it is well known that mining with smaller pools now means miners earn less Bitcoin, even if the reasons I have presented in this article cannot fully explain why. Not to mention that every instance of a significant mass migration from one pool to another is very noticeable, or that pools are simply misleading about the hash power they point to.
In addition, smaller pools have another problem: they may go days without finding a block, while larger pools will not go more than a few hours. This is a resolution issue, the higher your hash power, the closer you are to the expected in the short term. Unfortunately, this creates a lower limit, where pools below this limit cannot expect to make up for losses during a streak of bad luck, making it impossible to compete by that time.
The two-period gap between difficulty epochs means that enough blocks must be found within these two weeks so that any bad luck has a chance to be balanced out by subsequent good luck. If not, for example, if a pool's expected block finding rate is 1 block every 13 days and they do not find a block before the projection of a difficulty adjustment upwards causing them to drop to 1 block every 15 days, the previous time window will be forever closed. If it's a PPLNS pool, miners' income will be less than what they could have expected. If it's an FPPS pool, the pool will burn a lot of cash and/or go bankrupt.
This means that only so many pools can exist, at least in the way pools operate today. Simply put, it is not possible to have hundreds, as many of them may collapse during unfavorable periods, as they have less than 1% of the network hash power, and may not even reliably find a block every day, encountering periods of possibly weeks without a block. This is a limitation imposed by Bitcoin itself.
How do miners and pools communicate?
The communication protocol between miners and pools is Stratum (gradually being replaced by StratumV2). StratumV1 is both old and has deep flaws. First, all communication is transmitted in plaintext. This means that not only does your internet service provider know you are mining, but they also know the scale at which you are mining. Anyone who can eavesdrop on your network traffic can perform a man-in-the-middle attack, using your computer and hash power for someone else's mining. This has been abused in the past by unknown attackers to steal hash power, diverting it away from the intended pool.
In addition to some inefficiencies, StratumV1 has also failed to provide miners with a practical way to construct their own block templates and continue mining within the pool. All of these issues are addressed in the highly attractive StratumV2 (initially called "GBT," then "Better Hash"), which we will come back to later.
Hardware/Firmware
Before discussing the pool/miner dynamic, we will digress a bit, because this article would be incomplete if we did not mention that at any meaningful scale, ASICs are only manufactured by two companies, Bitmain and MicroBT. There are other companies, but almost all hashing occurs on machines made by these two companies.
This is obviously not good, the fundamental reason being that chip manufacturing is very difficult, and therefore too centralized.
The scope of this article does not include discussing solutions here, but there are efforts to make home mining more practical (in North America, the main issue is the need for 220-240 volt voltage and dealing with loud noise). Those involved in "pleb-mining" argue that if enough ordinary Bitcoin users can do this, they can start to account for a significant proportion of the total network hash power, which is more preferable for most scale mining operations, as they are more easily subject to regulatory intervention.
The difficulty of this task lies in the fact that the firmware is closed source. Even custom firmware that can "jailbreak" ASICs is often closed source, to ensure that users pay for development costs, meaning the cost of the market firmware you use represents the mining the development team did.
The original factory firmware on ASICs, especially Bitmain's, well illustrates how confident they are in their market dominance. Besides being closed source, it is clearly malicious. When starting an Antminer, you are forced to mine for them, although miners can at least prevent this by blocking the connection, or installing market firmware and then paying the development fee, which cannot be avoided, otherwise miners will refuse to mine. Bitmain has been found multiple times to add malicious backdoors in their miners' firmware (see Antbleed), and actively works to prevent market firmware developers.
In fact, the way the original firmware does this is shocking and clearly underscores the urgency of competition in the ASIC manufacturing space.
Would anyone feel comfortable if network rules were enforced by closed-source Bitcoin nodes? Furthermore, imagine if we all knew that these nodes would cause users to lose Bitcoin to the developers of that software, would anyone accept it? When it comes to mining, almost no one cares about the sovereignty of participants. Of course, the importance of node software and ASIC firmware is not equal, and we certainly pay more attention to the former, as we should, but the latter is not insignificant and is clearly being overlooked.
Having said all that, let's continue to discuss some solutions, particularly focusing on expanding the range of possibilities for miners and improving existing models.
P2POOL
On this point, there is not much to say other than it basically decentralizes every aspect of pooled mining. While it does many ideal things on a small scale, it requires every user to download, verify, and track every other user's share, and prove to each other that they have correctly calculated everything in the template. Achieving this in any adversarial environment is basically an impossible task. Due to the fundamental nature of pooled mining, the resources required are much greater than running a full Bitcoin node, not to mention making the miner's job more complex.
For these reasons, most people have ignored it, and only more technical users or idealists use it, understandably unable to mine with other alternative methods.
STRATUMV2
This is undoubtedly the most easily solvable problem, providing practical solutions to many of the issues mentioned in this article.
First, by allowing encrypted communication between pools and miners, ISPs and any other entity that can access your network traffic will no longer easily be aware that you are mining, or the extent of your mining. Therefore, "MITMing" you to hash on behalf of an attacker also becomes impossible, or at least not as easy.
Second, perhaps most importantly, it also allows miners to build their own block templates, so while pools will still be the trusted coordinators of reward distribution and may still be custodians of block rewards, this will represent a shift in power from pools to miners, which is undoubtedly a good thing.
In a world standardized by StratumV2, miners are eager to build their own templates, ideally, pools would incentivize miners to build their own templates, which would lead to a more powerful Bitcoin.
The community is essentially united in upgrading the mining ecosystem to StratumV2, but historically, due to the extra effort (though negligible compared to p2pool) and lack of incentives, miners generally avoid using these solutions.
With or without StratumV2, there is a lot of room for improvement. What is needed is a pool that allows miners to directly custody their coins while mining. This requires a pool (or its miners) to build block templates, in which miners' rewards are directly paid in the coinbase/generation transaction included in each block. In an FPPS system, this is practically unfeasible, meaning any pool implementing this approach will face some reluctance from miners, but those miners who transition will enjoy greater transparency, as Bitcoin itself will directly pay them above a certain threshold, with easily verifiable subsidy and fee income distribution. This can be used in conjunction with pools, at least allowing miners to understand the block template they are building before solving the block, and after StratumV2, only extending to verifying that all miners have built templates that accurately reflect reward distribution, without all miners constantly performing this operation.
Pools can also address the issue of miners being unwilling to do this by incentivizing miners to make their own block templates, for example by charging them lower fees. It seems that if miners are still unwilling to bear this burden after it becomes practical again, this additional incentive may be necessary.
The above suggestions would greatly improve the situation.
Many new plans and announcements about ASIC manufacturing and pool infrastructure are emerging, which should be welcomed by anyone hoping to ensure that mining tends towards a greater degree of decentralization.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
