BetterHash: Decentralizing Bitcoin Mining With New Hashing Protocols

An Overview Of Mining Pool Exploits That BetterHash Disables

Intro

BetterHash is the working name for alternative mining protocols currently in development. When it’s completed there will need to be enough miners willing to switch to a new mining pool using these protocols, or an existing pool that is willing to service both the old and new protocols while miners gradually ready themselves to switch over. In either circumstance the initial switch will need to be supported by enough miners to make doing so profitable, else profit volatility would be too high. Ultimately miners will need to understand why they should switch, and there will need to be forward thinking pool operators who don’t want the control current pools have. This can only happen if the problems and risks with the current system are properly understood and conveyed.

Disclaimer: This is not a fork, or a consensus rule change.

So what exactly is wrong with Bitcoin mining now?

Bitcoin mining has a representation problem. Bitcoin mining pools are not Bitcoin miners, yet pools unduly signal for them. Pools run the node, construct the block, select the transactions, and can choose what fork all of their miner’s hashpower is used for. This creates a handful of incentive issues and enables some pretty undesirable political leverage. BetterHash aims to address this by giving those responsibilities back to the individual miners, and stripping the mining pools of their influence for the greater good of the network. With BetterHash miners would control their own hashpower, and pools would just coordinate them and distribute the rewards.

Mining pool hashpower distribution, versus Slush Pool’s miner distribution projected onto every pool.

This article aims to highlight the kinds of exploitation pools can conduct under the current mining environment — of which would not be possible if BetterHash-like protocols were adopted — at the expense of what may be the miner’s best interests. Pools can also be hacked and then used by the attacker to engage in this behavior. Before we get to that let’s briefly go over the structural differences between what exists now and what BetterHash protocols would change about it.

Currently, many miners don’t even run nodes and simply connect their ASICs to a mining pool using protocols like Stratum. The pool runs the node, selects the transactions, creates a block they would like mined, and then sends that block out to all of the miners using their pool and the miners begin hashing it. Once a miner successfully mines a block, it gets sent back to the pool and out to the Bitcoin network.

With BetterHash, miners will individually run their own nodes, select the transactions, create a block, and then mine it. The block would be configured to pay the pool, and just like with the Stratum protocol, those unsuccessful blocks (called “shares”) would be used by the miners to prove they’ve been mining for that pool the whole time.

By just changing who creates the block template to be mined to the individual miners, instead of the pool owner, and then building a new protocol around that concept, BetterHash circumvents all the issues we’re going to cover.

For a more technical overview on the BetterHash protocols currently in development, this presentation by Matt Corallo should suffice, but is not necessary to understand the exploits this article discusses because conceptually BetterHash is objectively better, and a fully codified implementation doesn’t need to exist in order to grasp how important this is.

It should be noted that the name “BetterHash” is not definitive, as mentioned in the video.

The Status Quo

To understand why switching to BetterHash is so important, let’s unpack all the problems associated with the way things are now for miners that wouldn’t exist if they were using BetterHash.

To be brief, mining on your own has returns that are most likely too volatile, which is why pools have existed since as early as 2010. Critics will point at pool distributions to claim Bitcoin mining is centralized, and while counterarguments assert miners can just switch the pool they use, it’s not always that simple. If you’re a miner your options are limited to a handful of mining pools, each with their own terms of service that you may or may not agree with. Pools are too large to provide a diverse set of options to pick from.

At the end of the day you have no choice but to choose the pool best suited to you, and if most or all of the pools decide that some practice you don’t like or agree with is going to be the norm, then you have no real alternative but to deal with that, since starting your own pool probably won’t produce a steady enough income stream. Pools that already exist are relatively large, and by having many miners under each of their umbrellas, pools have the power over their miner’s hashpower to do a number of questionable things that we’ll go over one by one.

Pools can:

Determine what transactions do or don’t go into a block

Be bribed to reorganize the blockchain under the right conditions

Backlog transaction mempools to inflate the fee rate

Direct hashpower without consent & mine competitive forks

Dishonestly mine, should they have ulterior motives for doing so

Signal support for a proposal using a miner’s hashpower

All of these issues are essentially the direct result of pools building the Bitcoin blocks instead of the miners, as mentioned earlier. Along with pool exploitation comes third-party exploitation of the pools. Pools can be hacked and then the hackers can potentially conduct these exploits, or pools can be attacked from a network level and then miners are left scrambling to figure things out or switch to another pool. With BetterHash a pool hack wouldn’t be able to control a miner’s hashpower, and network level attacks targeting a pool wouldn’t have a direct effect on the miners using that pool.

Network level attacks are just as concerning if not more than pools exploiting their miner’s hashpower. An attacker can bring down a large chunk of the hashpower or redirect it as they please. BGP attacks are easy to do and the time & resources required to recover from them is concerning, to say the least. To convey how trivially an attacker can steal a pool’s hashrate and conduct any of the exploits written in this article, watch 3 minutes of this presentation below:

https://youtu.be/k_z-FBAil6k?t=353 — Network level attacks discussed at the 5:52 mark, ends at 9:00.

There’s no doubting the benefits of a protocol that defends against these kinds of issues, but solutions to often unheard of potentialities don’t always do a great job on their own conveying their necessity. I’d like to bring to light some hypothetical scenarios as well as some that have already occurred in some fashion, so that necessity is more readily understood. So let’s take a closer look at what each of them are. (Please note that some of these are hypothetical and unlikely to actually occur, and some require very specific circumstances, while others have occurred in one form or another already.)

1: Pools determine what transactions go into a block

Often an issue raised when discussing the possibility of 51% attacks, if enough pools can be convinced to blacklist a transaction type or an address, even temporarily, then it doesn’t matter if you — a miner — personally don’t care and would have included it. The motivation for this could be coercion or just a financial incentive to do so, whether the pool’s own, or a external one paid to the pool.

Scenario #1: Censoring a service’s hot-wallet

Imagine an exchange’s hot wallet being blacklisted by 40% of the pools, paid for by a competing exchange? It wouldn’t bar that wallet from transacting indefinitely, but it would noticeably slow down their transaction processing. As a miner, maybe you don’t think that behavior is healthy for the ecosystem, but maybe you just have no other choice since you have no say in what your pool does in secret.

Scenario #2: Censoring confidential transaction types

“Maybe the developer was the same kind of lazy”, resulting in code that ignored shielded transactions.

The tweet above ended up proving — if we trust his word — this example to be non-malicious, but it’s still important to consider scenarios in which something like this was done intentionally. Bitcoin doesn’t have confidential transactions at the moment — and may never have them — but it does have different transaction types. If a pool had a reason for doing so, then they could theoretically ignore them so a backlog of specific kinds of transactions exacerbates, raising fees and potentially slowing down any service that makes use of those specific of transactions.

2: Pools can be bribed to reorganize the blockchain

Similar to the examples above, pools can decide they don’t want a specific version of a transaction to be included in the ledger, and then try and act on this decision. Such a scenario would be next to impossible to coordinate spontaneously, or in hindsight, but if pools were so inclined then just a few of them could build software in preparation for a bribe, and then act on it immediately without miners having any say in the matter.

Miners might believe this is in their best interest if the bribe was shared with them, but pools have less of an incentive to do this the higher a share they give to the miners. Additionally, in a hacking scenario the hacker could counter the bribe to the pool, muddying the waters even more.

This was a suggestion after the exchange Binance was hacked — although the pools weren’t prepared for it — and many used this to make arguments about Bitcoin mining being centralized, when in reality it’s just the pools that have too much leverage over miners that this could even be potentially abused. For more nuance on this subject, give the podcast below a listen and make note that none of the things being discussed in it would matter if BetterHash was being used, because this would have been impossible to even consider if miners built the blocks instead of pools.

3: Pools can backlog transactions to inflate the fee rate

Not only can pools bar specific transactions, they can choose to ignore all transactions below a specific fee rate, raising the costs for everyone trying to transact. Some consider this a trivial issue because smaller pools will take the opportunity to include those transactions since the reward for them is greater, rewarding the underdogs in the long-term. I don’t think it’s as trivial as this, since we’ve seen how the effects of this behavior can steer arguments in the political arena over rising fees in the short-term.

Sooner or later a fee market is going to exist, but throttling the network below its consensus enforced limitations shouldn’t be a tool granted to a handful of people running pools. While competition may exist at the pool level to counter this behavior, we continue to see empty blocks mined by select pools because the financial incentives are aligned, along with instances in the past where a few specific pools only had transactions that were above 5 satoshis/byte, even when there was room for the remainder of the transactions in the backlog. It might require some coordination among pools to have an effect, but if the incentives align then that coordination isn’t difficult or even necessary, and now a small group of pool operators would have a valuable tool at their disposal that nobody else has.

Pools can also do this covertly. Instead of creating “non-full” blocks, they can fill them with what looks like legitimate but unannounced transactions that they then collect back to themselves, to throw off people, businesses, and fee estimators by leading them to believe the new “going fee rate” is real. Once the market starts paying the higher price then pools could just adjust their malicious transactions up again. At the time of the image below, the bottom 50% of the TX backlog in size accounted for only ~7% of the reward miners collected in fees. The reward grew non-linearly with the median fee rate in the transaction backlog, making this a lucrative endeavor for any large enough pool wanting to try this out.

4: Pools can direct hashpower without consent

In more ways than one, pools choose what chain to extend. Pools feed the miners a block and effectively just say “mine this block”, the miners mine that block until it’s found by someone, then pools feed them the next block. Miners aren’t tracking different branches themselves, and miners generally assume that the pool is being honest and mining the coin/fork you expect them to mine. Many miners aren’t running nodes, so they aren’t validating the consensus rules. This has caused problems in the past when pools decided that they were also not going to validate blocks, but instead “SPV mine” on top of invalid blocks. As a miner you should want to know that your time and money isn’t being wasted by the pool you’re using.

A scenario:

You’re a miner, and you’re part of Pool_A. You receive a steady stream of payments for the amount of hashpower you provide to the pool. You’ve done the math, it checks out, and that never changes.

The operator of Pool_A decides they are going to use your hashpower to provide “life support” for another chain that’s at risk. One that you don’t care about and possibly dislike or consider to be competition. The pool continues to pay you “the market rate” for your SHA256 rigs, but your hashpower isn’t actually being used on the chain you think you’re mining.

Since there’s now an entire pool mining a different chain, the network’s block production rate slows down — decreasing rewards — and the market is potentially fooled into thinking there’s more support than there actually is for another chain — decreasing the potential value of your chain. As a miner, this is probably a scenario you would want to avoid. Unfortunately, this scenario has already happened in real life: