How to achieve decentralization of Bitcoin mining?

BetterHash is the code name for an alternative mining protocol currently under development. Once developed, there needs to be enough miners willing to switch to a pool that uses these new protocols, or there needs to be an existing pool willing to serve both the old and new protocols, while miners gradually prepare to switch. In either case, the initial switch needs enough miners to be profitable, otherwise the profits will fluctuate too much.

Ultimately, miners need to understand why they should switch, and there needs to be forward-thinking pool operators who don’t want to own the control of current pools. This can only happen if the problems and risks of the current system are properly understood and communicated.

Disclaimer: This is not a fork, nor a change in consensus rules.

So what’s wrong with Bitcoin mining now?

Bitcoin mining has a representation problem. Bitcoin mining pools are not Bitcoin miners, but mining pools overly signal for them. Mining pools run nodes, build blocks, select transactions, and can decide which fork all miners' hash power should be used for. This creates some incentive problems and enables some rather unpopular political leverage.

BetterHash aims to solve this problem by returning these responsibilities to individual miners and taking away the influence of mining pools for the greater good of the network. With BetterHash, miners control their own hashing power, and mining pools simply coordinate them and distribute rewards.

This article aims to highlight the types of abuse that can be perpetrated by mining pools in the current mining environment (which would not be possible if a protocol like BetterHash were adopted) at the expense of the miners’ best interests. Mining pools can also be hacked, and then used by the attacker to perpetrate the behavior. Before we get started, let’s briefly review the structural differences between the status quo and what the BetterHash protocol will bring.

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

With BetterHash, miners will run their own nodes individually, select transactions, create a block, and start mining. The block will be configured to pay the mining pool, just like the Stratum protocol, and those unsuccessful blocks (called "shares") will be used by miners to prove that they have been mining for the pool.

BetterHash circumvents all of the issues we are going to discuss by replacing the miners who create the block templates to be mined with the pool owners, and then building a new protocol around this concept.

For a more technical overview of the BetterHash protocol currently under development, it should be sufficient to watch Matt Corallo’s talk without having to understand the issues discussed in this article, as conceptually BetterHash is objectively better and a full code implementation is not necessary to understand how significant this is.

It’s worth noting that “BetterHash” is not the finalized name, as mentioned by Matt Corallo.

status quo

To understand why switching to BetterHash is so important, let’s list all the problems that current miners will face if they don’t use BetterHash.

In short, the returns from mining on your own are likely too volatile, which is why mining pools have been around since 2010. Critics will point to the distribution of mining pools and claim that Bitcoin mining is centralized, although counterarguments claim that miners can switch the pool they use,

But it’s not always that simple. If you’re a miner, your options are limited to a handful of mining pools, each with terms of service that you may or may not agree to. Mining pools are too large to offer a wide range of options.

In the end, you have no choice but to choose the pool that works best for you, and if most or all of the mining pools decide to make something you don't like or agree with the norm, then you actually have no choice but to accept it, as starting your own mining pool may not generate a sufficiently stable income stream. The existing mining pools are relatively large, each with many miners under their umbrella, and the mining pools have the ability to control the miners' hash power and do some problematic things that we will discuss one by one.

Mining pools can:

• Decide which transactions to include or exclude from a block

• Reorganize the blockchain under the right conditions after being bribed

• Backlog transaction memory pool to increase fee rates

• Switching hashing power to mine competing forks without miners’ consent

• Dishonest mining, they must have ulterior motives in doing this

• Use miners’ hash power to support proposals

As mentioned earlier, all of these issues are basically a direct result of the fact that mining pools, rather than miners, build Bitcoin blocks. Along with the abuse of mining pools, there is also the abuse of mining pools by third parties.

A mining pool could be hacked, and then the hacker could potentially perform these operations, or a mining pool could suffer a network layer attack, and then miners would be scrambling to figure out the problem or switch to another pool. With BetterHash, an attack on a mining pool cannot control the miners’ hash power, and a network layer attack on a mining pool will not have a direct impact on the miners using that pool.

Network layer attacks and mining pools abusing miners’ hash power are equally worrisome. An attacker can slash large amounts of hash power or switch it around as needed. BGP attacks are easy to pull off, and the time and resources required to recover from them are significant and worrisome, to say the least.

A protocol that can defend against these kinds of problems is undoubtedly valuable, but solutions to potential problems that have never been heard of before don’t always make sense in a good way. I want to show some hypothetical scenarios and some that have already happened in some way to make it easier to understand why they are necessary. Let’s take a closer look at what they are. (Note that some of these are hypothetical and unlikely to actually happen, some require very special circumstances, and others have already happened in one form or another.)

1: The mining pool decides which transactions to include in the block

When discussing the possibility of a 51% attack, one of the issues that often comes up is that if enough mining pools are convinced to blacklist a transaction type or address, even temporarily, then even if you as a miner don’t care, you have already participated in it. The motivation for doing so may be coercion, or it may simply be a financial incentive, either from the mining pool itself or an external incentive paid to the mining pool.

Scenario #1: Censoring a service’s hot wallet

Imagine that a hot wallet of an exchange is blacklisted by 40% of mining pools at the behest of a competing exchange? It won't block the wallets from making transactions indefinitely, but it will noticeably slow down their transaction processing speed. As a miner, maybe you think this behavior is unhealthy for the ecosystem, but you have no other choice because you have no say in what the mining pools do in secret.

Scenario #2: Review of confidential transaction types

Bitcoin does not currently have confidential transactions and may never have confidential transactions, but it does have different transaction types that mining pools could theoretically ignore if they had reason to do so, thus creating a backlog of transactions of a particular type, driving up fees and potentially slowing down any service that uses those specific transactions.

2: Mining pools are bribed and reorganize the blockchain

Similar to the example above, a mining pool could decide that they don’t want a particular version of a transaction to be included in the ledger, and then attempt to enforce that decision. This would be nearly impossible to coordinate spontaneously or after the fact, but if the pools were so inclined, it would only take a few of them building software to be prepared to accept bribes and then act on them immediately, without the miners having any say in the matter.

Miners may think it is in their best interest if the bribe is shared with them, but if they give the miners a higher share, they will have less incentive to do it. Additionally, in the event of a hack, the hacker can counter-bribe the mining pool, muddying the waters even further.

This was a suggestion after an exchange got hacked - although mining pools were not prepared for this - many people use this to discuss Bitcoin mining being centralized, when in reality it is just because mining pools have too much leverage (for miners) and can even be abused. Note that if using BetterHash, none of the discussion here matters, as if miners, not mining pools, are building blocks, none of these issues exist.

3: Mining pools pile up transactions to increase fees

Not only can mining pools block certain types of transactions, they can also choose to ignore all transactions below a certain fee rate, thus raising transaction costs for everyone. Some people think this is a trivial issue because smaller mining pools will take advantage of the opportunity to include these transactions because the reward for them is larger, rewarding the disadvantaged in the long run. I do not think this is trivial, as we have seen how the effects of this behavior can steer debates in the political arena about short-term fee increases.

Fee markets will exist sooner or later, but constraining the network to consensus-enforced limits should not be a tool for a few to run mining pools. While there may be competition at the pool level to combat this behavior, we still see examples of pools that choose to mine empty blocks due to financial incentives, and certain pools that only include transactions with a transaction fee higher than 5 satoshis/byte, even if there is still room left to accommodate the backlog of transactions.

This may require some coordination between mining pools to have an effect, but if the incentives are aligned then coordination is not difficult or even necessary, and now a small group of mining pool operators will have a valuable tool that no one else has.

Mining pools can also do this covertly. Instead of creating “unfilled” blocks, they can fill them with legitimate-looking but unbroadcasted transactions and then retract those transactions, thereby misleading individuals, businesses, and fee assessors into believing that the new “going rate” is real.

Once the market starts paying higher prices, then the mining pools can re-adjust their malicious transactions. In the image below, the bottom 50% of the backlog transactions only account for ~7% of the collected miner rewards. The rewards scale non-linearly with the median fee rate of the backlog transactions, making this a profitable endeavor for any large mining pool that wants to try this.

4: Mining pool switches hashrate without consent

There are a number of ways that mining pools can choose which chain to extend. The pool gives miners a block and essentially just says "mine this block", and the miners start mining until someone finds it, and then the pool gives them the next block. Miners don't keep track of the different forks themselves, they usually assume that the pool is honest and will mine the coin/fork you want them to mine.

Many miners do not run nodes, so they do not validate the consensus rules. This was caused when mining pools decided that they would not validate blocks either, and instead performed “SPV mining” on top of invalid blocks. As a miner, you should want to know that your time and money are not being wasted by the mining pool you use.

A scenario:

You are a miner and part of Pool_A. You receive a constant stream of payments for the hash power you provide to the pool. You have done your calculations and checks, and this will never change.

The operator of Pool_A decided to use your hashing power to provide "life support" for another chain that is in danger. A chain that you don't care about, may not like, or consider to be a competitor. The mining pool continues to pay the "market price" for your SHA256 computing platform, but your hashing power is not used to mine on the chain you think it is. (Blue Fox Notes Note: Similar situations have already occurred in reality.)

Since there is now an entire mining pool mining on a different chain, the network’s block production slows down, rewards are reduced — and the market may be fooled into thinking that the other chain has more support than it actually does, 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 real life:

https://www.reddit.com/r/btc/comments/9y5qpj/roger_ver_calvin_if_you_happen_to_watch_this/e9yj4fy/?context=10000

https://www.reddit.com/r/btc/comments/9x2ekv/all_poolbitcoincom_hashrate_to_mine_abc_chain_for/e9ozqes/

5: Mining pools use miners’ hash power for dishonest mining

Consider the scenario above, which is the best example of how this would play out: the mining pool is being “honest” with the miners’ intentions, and they are at least “trying” to compensate them for what they perceive as financial burdens. They give the miners a heads up, and tell them that if they don’t like it, then leave — it’s not always that simple. What if they’re not being honest?

If a mining pool shows that they are mining two chains, 80% and 20% yellow and green respectively, and you are mining the green chain through them, how do you know that they are honest and only 20% of miners support this chain? They can tell every miner individually that they are that 20% and they are the only ones supporting it, when in fact they are not.

Miners will have to coordinate through other channels, summing up their hash power to find out if they are being cheated. The main problem is that many miners are private, many want to remain private, and should remain private. Coordinating like this to avoid being cheated and manipulated is an impractical solution.

Not only would such lies allow for full exploitation of the combined hash power 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 use your hashing power to support a proposal

There doesn’t even need to be an actual chain fork to be performed. Since the mining pool votes on behalf of all the hashpower under it before the actual fork, a situation like the one below could result in 80% of the hashpower being for or against a proposal or fork.

Considering that voting is not a financial commitment, there is little risk in doing so. 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 witnessed with NO2X, there is no loss to the mining pool. Regardless of the outcome, everyone's hash power still works.

No one knows exactly what percentage of hash power all mining pools actually own versus what percentage other miners who use the pools own, but the additional transparency would undoubtedly effectively benefit the silent majority of hash power.

No one wants another NO2X scene, and no one can "decide" what the majority supports when they really don't. If BetterHash had existed a few years ago, perhaps the NO2X movement wouldn't have been necessary.

Conclusion: Perspective matters

There are two different common reactions I anticipate people will have when reading this article, and they are both what I have gotten from a small number of readers. I think it is important to highlight this and address it for the reader (that is you).

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

2. “This can make it appear that mining pools have more control than they actually do.”

Now, as for the “meta considerations”, at first glance one might think:

“The first person may not know much about mining or Bitcoin, the second person is closer to the truth and can fully understand the nuances and weigh these scenarios more appropriately. ”

Another possible way to think about this is:

“The first one offers a new and real perspective on the balance of power in the system, while the second one has been around for a while and has become too comfortable and desensitized to the way things work and the potential threats.”

Both of these initial reactions are reasonable. Both of these meta-considerations are valid. If mining pools didn’t have the potential to abuse the system as it is currently set up, there would be no drive to develop a better protocol and you wouldn’t be reading this article. Conversely, if mining pools were such a serious threat to Bitcoin, then by now they have already abused their power in irreparably damaging ways.

Beyond these polarizing opinions, here’s what I hope your takeaway is:

BetterHash needs to be implemented because it is objectively better than what we have now. There should be no possibility for mining pool abuse and network attacks, and we can mitigate these problems by simply having miners run their own nodes and thus create their own blocks, and using a better mining pool protocol that is built around simple but fundamental changes. There is always the possibility of serious problems if we don't solve the problems we know how to solve ahead of time, so let's solve it.