Mining pools have too much power? Maybe it’s time for Bitcoin to use the BetterHash protocol

Note: The original title is "Betterhash: Decentralizing Bitcoin Mining With New Hashing Protocols", and the author is StopAndDecrypt.

The following is the translation:

Introduction

BetterHash is an alternative mining protocol currently being developed by Bitcoin developers. When it is completed, there will need to be enough miners willing to use this protocol to switch to the new mining pool, or there will be an existing mining pool willing to serve both the old and new protocols, and miners will gradually be ready to switch. In either case, the initial conversion will need to have enough miner support to be profitable, otherwise the profit fluctuations will be too large. Ultimately, miners will need to understand why they are switching, and forward-thinking mining pool operators (who do not want to control existing mining pools) will be needed. This can only happen if the problems and risks of the current system are properly understood and communicated, which is a prerequisite for the BetterHash mining protocol to be adopted.

So, what problems does Bitcoin mining currently face?

There is an agency problem in Bitcoin mining: Bitcoin mining pools are not miners, but mining pools send inappropriate signals on behalf of miners. Mining pools run nodes, which are responsible for building blocks, selecting transactions, and can represent all the miners in the pool to support which fork chain. This creates some incentive problems, and some rather unwelcome political pressure. Betterhash aims to solve this problem by giving these responsibilities back to individual miners, and take away the influence of mining pools for the greater good of the network. With BetterHash, miners can control the computing power themselves, and the mining pool is just responsible for coordinating them and distributing rewards.

The hashrate distribution of mining pools vs. the miner distribution of Slush Pool projected to each mining pool

Before we get started, let’s briefly review the structural differences between existing protocols and what the BetterHash protocol will change.

Currently, many miners don't even run nodes, but simply connect their ASIC miners to a mining pool using a protocol such as Stratum. The mining pool runs the node, selects transactions, creates a block they want to mine, and then sends the block to all miners using their pool, who start hashing it. Once a miner successfully mines a block, it is sent back to the mining pool and then output to the Bitcoin network.

With BetterHash, miners will run their own nodes individually, select transactions, create a block, and then mine it. The block will be configured to pay the pool, and just like with the Stratum protocol, these unsuccessful blocks (called "shares") will be used by miners to prove that they have been mining for the pool. By changing the participants who create block templates and then building a new protocol around this concept, BetterHash bypasses all of the problems we are going to discuss.

For a more technical overview of the Betterhash protocol currently under development, this demo video by Matt Corallo should suffice:

It should be noted that the name “Betterhash” is already finalized, as mentioned in the video.

https://www.youtube.com/watch? V=0LGO5I74QJM

The current state of Bitcoin mining

To understand why switching to BetterHash is so important, let’s unpack all the issues related to the way miners live now, which would no longer exist if they used the BetterHash protocol.

In short, the returns from solo mining are highly volatile, which is why mining pools were created in 2010. Critics will point out that the distribution of hashrate among mining pools makes Bitcoin mining centralized, and while refutators assert that miners can switch the pools they use, it's not always that simple. If you're a miner, your choices are limited to a handful of pools, and each pool has terms of service that you either accept or don't. Mining pools are too large to offer multiple options.

In reality, you have no choice but to choose the pool that works best for you, and if most or all of the pools decide something you don't like or agree with, then you have no real choice but to deal with the problem, as setting up your own pool may not generate a stable enough income stream. The ones that already exist become larger, and by having a large number of miners under their umbrella, the pools have rights that miners do not have. We will discuss each one individually.

Mining pools can:

1. Determines which transactions are included in a block or not executed.

2. can be bribed to reorganize the blockchain under the right conditions;

3. Backlog transaction mempool to increase transaction fee rate;

4. Directly use computing power to mine competing forked chains without the consent of miners;

5. Dishonest mining, the motivation for doing so should be ulterior motives;

6. Use miners’ hashrate to signal support for a proposal;

As mentioned earlier, all of these issues are essentially a direct result of mining pools creating Bitcoin blocks, rather than miners. With mining pool exploits come third-party issues. Mining pools can be hacked, who can then potentially execute these exploits, or mining pools can be attacked at the network level, and miners are left to either fix the problem or switch to another pool. With BetterHash, mining pool hackers can no longer control miners’ hashrate, and network-level attacks on mining pools will not have a direct impact on miners using that pool.

With network-level attacks, the attacker can knock down a large amount of hashrate, or redirect it as needed. BGP attacks are easy to accomplish, and the time and resources required to recover from them are relevant, to say the least. To understand how an attacker can steal mining pool hashrate and perform any of the exploits written in this article, watch the 3-minute demo below:

https://youtu.be/k_z-FBAil6k?t=353

(Network-level attack discussion starts at 5:52 and ends at 9:00)

Whether a protocol is suitable for adoption will undoubtedly depend on whether these issues are urgent to address.

However, the potential of these scenarios is not always well expressed as their necessity.

I want to shed some light on some hypothetical scenarios, as well as some that have already happened in some way, so that it is easier to understand the need for Betterhash. So let's take a closer look at what each of them is. (Note that some of these are hypothetical and unlikely to actually happen, some require very specific circumstances, and others have already happened in one form or another.)

1. The mining pool determines which transactions go into a block

When discussing the possibility of a 51% attack, a question often raised is if enough mining pools could be persuaded to blacklist a transaction type or address, even temporarily. This could be done under duress or simply out of financial incentive, whether it be the mining pool itself or an external party paying the reward.

Scenario 1: Reviewing a server’s hot wallet

Imagine that an exchange's hot wallet is blacklisted by 40% of the mining pools (perhaps paid by a competing exchange behind the scenes), then it will not prevent this hot wallet from making transactions, but it will significantly slow down its transaction processing speed. As a miner, maybe you don't think this behavior is healthy for the ecosystem, but maybe you have no other choice because you have no say in it.

Scenario 2: Review of confidential transaction types

"Maybe the developers were just as lazy," causing the code to ignore confidential transactions.

The tweet above ultimately proves (if we trust him) that this example was non-malicious, but it's worth considering the possibility that the situation could be malicious. Bitcoin doesn't have confidential transactions yet, and likely never will, but it has a lot of different transaction types. If a mining pool had reason to do so, then they could theoretically ignore those transactions, thus increasing the backlog of transactions of a particular type, raising transaction fees, and potentially slowing down any services that use those specific transactions.

Related reading: ZCash Confidential Transaction Censorship Incident: https://medium.com/@levdubinets/zcash-shielded-transaction-censorship-12098f21090b

2. Mining pools can be bribed to reorganize the blockchain

Similar to the example above, a mining pool could decide that they do not want a particular version of a transaction included in the ledger, and then attempt to enforce this decision. This would be nearly impossible to coordinate spontaneously or after the fact, but if the mining pools were so inclined, and if there were only a few such pools willing to accept the bribe and act immediately, then the miners would have no say in the matter.

If the mining pool is willing to share these bribes with the miners, the miners may accept them, but the higher the share given by the mining pool to the miners, the less motivation they have to accept them. In addition, in the scenario of a hacker attack, the hacker can bribe the mining pool, making the situation more complicated.

This was a suggestion that was mentioned after an exchange was hacked. Although mining pools are not prepared to do this, many people use it to argue that Bitcoin mining is centralized. For more details on this topic, please listen to the podcast below, and note that if you use Betterhash, anything discussed there is irrelevant because these issues do not even need to be considered when miners are building blocks, not mining pools.

3. Mining pools can backlog transactions to increase transaction fees

Mining pools can not only block specific transactions, but can also choose to ignore all transactions below a certain fee rate, thus raising costs for everyone trying to transact. Some argue that this is a trivial issue because smaller mining pools will take the opportunity to include these transactions because the reward for them to do so will be greater, and therefore this will reward weaker pools in the long run. I do not believe this is trivial, as we have seen the effects of this behavior, how it can steer debates in the political arena about rising fees in the short term.

Fee markets are here to stay, but they shouldn’t be used to profit from them by dictating the rules of the network. While there may be competition at the pool level to counter this behavior, we still see some pools choosing to mine empty blocks. There have been instances in the past where specific pools only included transactions above 5 satoshis per byte, even when there was room left in the block. This may require some coordination between pools to work, but if incentives are aligned, then coordination is not difficult or even necessary, and now a small number of pool operators will have a valuable tool that no one else has.

Mining pools can also do this covertly, instead of creating "non-full" blocks, they can fill those blocks with seemingly legitimate but unannounced transactions, and then re-collect those transactions by leading them to believe that the new "going fee rate" is real. Once the market starts paying a higher price, the mining pool can then re-adjust their malicious transactions. At the time shown in the figure below, the bottom 50% of the Tx backlog only accounted for 7% of the fees collected by miners. The rewards grow non-linearly with the median fee rate in the transaction backlog, and it can be profitable if a large enough mining pool wants to try this.

https://www.reddit.com/r/Bitcoin/comments/7lwajx/spamming_the_network_unfortunately_doesnt_result/

4. Mining pools can use computing power directly without the consent of miners

It is actually the mining pools that decide which chain to extend, the mining pools give the miners a block and essentially just say "mine this block," and then the miners go and mine that block until someone finds the solution and the mining pool gives the miners another block. Miners do not keep track of the different branches themselves, miners usually assume that the mining pool is honest and will mine the coin/fork chain you want them to mine. Many miners do not run nodes, so they do not verify the consensus rules. This has caused problems in the past when mining pools decided that they would not verify blocks and instead perform "SPV mining" on invalid blocks. As a miner, you should know that the time and money you spend is not wasted because of the mining pool.

A scenario:

You are a miner and part of Pool_A, you contribute your hashing power to the pool and you receive payments that keep coming in. You do the math, you check it, and it never changes.

The operator of Pool_A decides to use your hashrate to provide hashrate (life) support for another chain that is in danger. This chain may be one you don’t care about, or even one you don’t like, or a competitor. The pool continues to pay you for your hashrate at the “market price”, but your hashrate is not actually being used on the chain you thought it was.

Since there is now an entire mining pool mining a different chain, the network's block production slows down (and rewards decrease) (the market may be fooled into thinking there is more support for another chain than there actually is), which reduces the potential value of the chain you support. As a miner, this is probably a situation you want to avoid. Unfortunately, this has already happened in the real world:

5. Mining pools can use miners’ computing power to conduct dishonest mining

Consider the scenario above, which is a prime example of how this would play out: the mining pool is upfront with the miners about its intentions, and at least tries to make it up to them. They tell the miners, if you don’t like it, you can just leave. But what if the mining pool is dishonest?

If a mining pool says they are mining two chains, 80% yellow and 20% green, and you are mining the green chain through them, how do you know they are honest and only 20% of miners are supporting this chain? They can tell every miner individually that they are the 20% and they are the only ones supporting this chain. Miners will have to coordinate on side channels and then add up their hashrate to determine if they are being cheated. The main problem is that many miners are private, and many want to remain private, and should remain so. Coordinating like this to avoid being cheated and manipulated is an impractical solution.

Not only does this type of false information allow mining pools to fully exploit the combined hashrate of all miners, but the fraud could affect the market’s valuation of each chain. Anyone who values ​​the long-term health of the Bitcoin network would want to avoid this.

6. Mining pools can use your hashrate to signal a vote for a proposal

This doesn’t even require an actual chain split. Given that voting signals are not financial commitments, the risk of doing so is minimal. If you want to try to move the market in the direction you want, you only need to convince the minority of people running these mining pools to temporarily signal support. If it fails, as we saw with NO2X, then it’s no loss for the mining pool. Regardless of the outcome, every miner’s hashrate is being used normally.

Each column represents a mining pool. The top portion of each column represents the hashrate that the pool has, while the bottom portion represents the types of other miners using that pool.

No one wants another NO2X scheme, and no one can "decide" what the majority will support when they really don't. If BetterHash had existed a few years ago, the NO2X movement might not have been necessary.

Miners Didn’t Vote for Segwit2X, Mining Pools Did It

Conclusion: A matter of perspective

I expected people to have two different reactions when reading this post, both of which I got from the few people who viewed it:

1. “I didn’t know mining pools had that much power.”

2. “This article makes it seem like mining pools have more control than they actually do.”

Now, regarding the “meta-considerations”, at first glance one might think:

“The first person may not know much about mining pools or Bitcoin, the second person is a veteran who understands the nuances well enough to weigh these situations more appropriately.”

Another possible way to think about this is:

“The first provides a new and authentic perspective to learn about the balance of power in the system, while the second has been in the system for a while and has become overly comfortable and desensitized to the way things are and potential threats.”

Both of these initial reactions are valid, and both of these meta-considerations are valid. If it were impossible for mining pools to abuse the way the system is currently set up, then there would be no drive to develop a better protocol, and you wouldn’t be reading this article. Conversely, if mining pools posed a serious threat to Bitcoin, then they would abuse their power in irreparably destructive ways (see BCash).

Aside from these polarizing opinions, here’s what I hope you’ll take away:

BetterHash should be implemented because it is objectively better than the current protocol used by Bitcoin. Mining pool abuse and network attacks should not be feasible, and we can alleviate these concerns by allowing miners to run their own nodes so they can create their own blocks and use a better mining pool protocol that is structured around simple but fundamental changes. There is always the possibility that serious problems will arise if we don't solve the problems we know how to solve ahead of time, so let's solve it.

Additional Resources:

Bob McElrath: Decentralized Mining Pools for Bitcoin

Off Chain with Jimmy Song : How Mining Pools Work with Matt Corallo

What Bitcoin Did: Matt Corallo on How Bitcoin Works

Thanks to Jameson Lopp and Steve Lee