Why Bitcoin Mining Pools Aren’t Incentivized to Broadcast Blocks Quickly

It is generally accepted that latency in block propagation is one of the bottlenecks for Bitcoin scaling. This is why many of Bitcoin’s most active developers and researchers have presented a series of solutions to compress blocks and speed up propagation over the past years.

It is not as well known that these solutions may not suffice on their own. Due to a practice called “spy mining” or “pool-watcher mining,” Bitcoin mining has increasingly come to rely on the data and network infrastructure provided by mining pools.

As a result, many mining pools are not necessarily incentivized to broadcast their blocks to the network as fast as they can — regardless of latency in block propagation.

Selfish mining

To understand how this is possible, let’s first take a brief look at an older concept: “selfish mining”.

In short, selfish mining is a type of attack where miners find new blocks, but do not immediately broadcast these blocks to the network. The miners do, however, mine on top of any new found block they find themselves: they are mining “selfishly.” This gives them a head start to find the next block, while all other competitors are wasting their resources mining on top of an older block.

But hiding a new block is also risky. While a selfish miner hides a block, competitors may find a competing block. If this competing block makes its way through the network before the selfish miner’s block does, the selfish miner would have wasted its own resources by hiding the block: the block is now worthless.

For selfish mining to be profitable, therefore, the attacker requires a significant amount of hash power on the network — some 25 to 30 percent at least. And more than half of all hash power on the network is surely enough. Though, with a majority of hash power, the attack perhaps starts to resemble a 51 percent attack and not just a selfish mining attack.

A “selfish 51-percent attack,” if you will.

Luckily, no miner (or mining pool) currently controls over half of all hash power on the Bitcoin network, or even 25 percent. At least not directly…

Validationless mining

A lot of miners do engage in a type of “validationless mining” or (less accurately termed) “SPV mining”.

A Bitcoin block consists of several pieces of data: transactions, a timestamp, a nonce and more. One important piece of data is a reference to the previous block: the block header hash. The block header hash can only be generated using the block header of the previous block, which can in turn only be generated using all data in that block. The idea is that a miner cannot mine a new block before it has seen the previous block.

But there is a bit of a loophole. Using onlythe block header hash, miners can try and find the next block just as well — even without knowing the previous block header, nor any of the other data in the previous block.

This can potentially come in handy. If miners can get a block header hash before receiving an actual block, they can try and find a new block more quickly, which allows them to be more profitable.

And as it turns out, there is indeed a way for miners to often get a block header hash before receiving an actual block.

Spy mining

The mining pools that today account for most blocks mined on the network really consist of many individual miners: e.g., “hashers.” These hashers are all trying to find a new block on behalf of their pool, using a block header hash they received from their pool.

A pool, of course, wants its connected hashers to mine on top of a new block as soon as possible. So if a pool finds a new block, it immediately sends the block header hash to all its hashers for them to mine on top of. And since this block header hash consists of minimal data, and because there is a direct connection between the pool and all hashers, the block header hash typically gets to these hashers very quickly.

This is where spy mining comes in.

Competing miners (including competing mining pools) can receive this block header hash from the mining pool as well. They simply need to connect to the pool, much like all the hashers. But instead of hashing for the pool, these miners then take the block header hash and mine on top of it for themselves. They’re spy mining.

The pool that has the block header hashes may not even notice the difference between real hashers, and the spy miners. And if the pool does notice the difference, it may not even care. There’s no real disadvantage for the pool.

Perhaps unsurprisingly, therefore, over half of all miners on the network (by hash power) currently engage in spy mining.

Smaller problems

Unfortunately, spy mining — like all validationless mining — does present some problems.

Spy miners can’t check block header hashes for validity; they need all the other block data for that (the transactions, the nonce, etc). As such, spy miners have to place some trust in the mining pools they get the block header hashes from. This means that if the mining pool mines invalid blocks, it can — in a worst case scenario — lead to blockchain forks. (Much like the 2015 BIP66 blockchain fork.)

Additionally, mining pools can abuse the trust placed in them, especially if they can identify their spy mining competitors; for example, by feeding corrupt block header hashes to (some of) the spy miners. This tactic can cause spy miners to waste their resources, in turn making the Bitcoin network less secure.

And, until they receive the full block, spy miners can only mine empty blocks; that’s the only way to ensure they don’t include any double-spend transactions. This means that the total number of transactions throughput on the Bitcoin network is lower than it could be.

Luckily, however, in part thanks to several safeguards applied by spy miners, these problems are all relatively minor. While probably not ideal, risks to the Bitcoin network are limited.

Broadcasting

Widespread engagement in spy mining, however, enables a bigger problem.

Because so many miners (and pools) are spy mining, each time a mining pool finds a block and transmits the block header hash, this mining pool effectively directs a majority of all hash power to mine on top of that block — immediately. As such, there is no longer a big risk of this block being rejected and discarded for a competing block. Most of the network already accepts this block through the block header hash.

This practice, in turn, allows mining pools to launch selfish 51 percent attacks, simply by delaying broadcasting their new blocks to the network. More specifically, it allows mining pools to launch selfish 51 percent attacks against any miner that does not engage in spy mining, and against some identified spy miners. While a mining pool and its spy miners get a headstart mining on top of the new block, all other miners waste their resources. (At least for some time, depending on the safeguards imposed by spy miners.)

Amazingly, this even means that mining pools can gain advantage by being sloppy. Mining pools can, for instance, benefit from buggy software that delays broadcasting blocks by a few seconds — or more than a few.

Although mining pools should want to broadcast their blocks to the network as fast as they can, widespread engagement in spy mining seems to have skewed these incentives for the worse — with no clear solution in sight.

The post Why Bitcoin Mining Pools Aren’t Incentivized to Broadcast Blocks Quickly appeared first on Bitcoin Magazine.