Who is Monitoring Mining Pools?

One of our goals at the Digital Currency Initiative is to harden the security of cryptocurrency networks. Most users of cryptocurrency take the actual network protocol and all of its implementation — mining, pools, validation, messaging, and more — for granted, and aren’t necessarily aware of all the ways these mechanisms might be attacked or fail. For example, though mining pools are a huge part of Bitcoin’s network security, there isn’t any available public monitoring to make sure that mining pools are well-behaved. There isn’t even a standard way to look at what pool operators are doing or infrastructure to keep tabs on pool operators.

This is an example of what we call protocol risk: cryptocurrencies are only as secure as their networks. If a network is insecure, it can become unusable or users could lose their money. Businesses and users who are deeply invested in cryptocurrency should understand how to evaluate and mitigate this risk.

Review of mining

In Bitcoin and other proof-of-work cryptocurrencies, miners secure the network by using their computational resources (usually ASICs or GPUs) to compete for block rewards. In total, these resources are known as the network hashrate, which is the rate at which all the mining equipment operating in the network can execute the cryptocurrency’s hash function. Bitcoin and other longest-chain protocols rely upon the distribution of hashrate among miners for security; if an attacker can obtain a majority of the network hashrate, they can mine an alternative chain that will become the network’s longest chain and they can double spend. We’ve seen this happen ourselves on five occasions on several low-hashrate cryptocurrencies to date. Most recently there were multiple attacks on Ethereum Classic, where attackers took several million dollars worth of money from their victims.

The hashrate of the biggest cryptocurrencies has grown very high — in Bitcoin the network completes 2⁷⁶ hashes every ten minutes. As a solo miner, it will likely take you a very long time to find a block and collect your rewards — using a cutting-edge miner today, it will take on average 19 years to find a block. But miners make an up-front investment in equipment and have to pay power costs; they often can’t wait that long for income.

In order to reduce this variance in rewards, miners combine their hashrate together in mining pools and split the rewards according to how much hashrate each miner contributes. The first mining pool was established in 2010. Mining pools work as follows: Miners register for a pool with a payment address, usually through a website, and point their miner towards the pool. The mining pool operator distributes work to miners (making sure they don’t do overlapping work) and has the responsibility of accounting how much work each miner performed. Work is a version of a block header with a transaction that pays the mining pool operator; the miner tries different nonces. A miner gives the pool operator shares which are mined block headers that hash to low values, but not low enough to meet the blockchain’s difficulty target; this is evidence to the pool operator of the miner’s hashrate. When a miner finds a share low enough to meet the difficulty target, they report it to the pool operator, who attaches it to the block and gossips it to the network. The pool then distributes the block reward to all the miners proportionally to the work each miner did.

Mining pools in Bitcoin make up the vast majority of the total Bitcoin hashrate. Generally somewhere between 4–8 mining pools comprise a majority of the hashrate. They’re a critically important part of Bitcoin’s security.

What exactly are the pools mining?

In existing mining pool software, the mining pool operator chooses and distributes the work: miners do not get to choose what block contents to mine. In fact, miners only get the block headers, not the transactions that form the block. This is in contrast to solo mining, where the miner runs their own full node and chooses their own transactions for a new block, and new mining pool protocols like Stratum v2 where the miner can have a say in what they mine. But right now, miners pretty much mine whatever they are given.

This is risky: pool operators control large amounts of network hashrate, and could conduct attacks like double spending and selfish mining without the miners even knowing it. Or, a pool operator could redirect a miner’s hashrate to a different coin with the same algorithm.

A miner decides what pool their hardware connects to, and pool operation is competitive: miners can leave and join pools whenever they like. So miners could abandon a pool for bad behavior, and in fact, this has happened in the past when miners decided to leave Ghash.io after it accumulated more than 50% of the Bitcoin hashrate. But how do miners even learn about bad behavior?

Introducing Pool Detective

In order to address the risk that mining pool operators could go rogue, DCI developed Pool Detective. The idea is simple: We join all the public mining pools and monitor what they’re doing, making sure it matches the work we’d expect to see. We add a proxy server between our own mining hardware and each mining pool in order to archive the jobs the mining pool instructs our hardware to perform, and the work we produced in return. We are currently mining in 32 pools across 17 cryptocurrencies. We also run full nodes for each of the cryptocurrencies we monitor, as well as block observers which connect to full nodes and listen for block propagation messages in five different locations around the globe. This gives us an overall view of the network and we can detect things like delayed blocks or spy mining by seeing when our observers find out about blocks as compared to when our miners switch work in the pools.

The protocol over which miners and pools talk to each other is called Stratum. We’ve built a Stratum proxy server that connects to all of the 32 upstream pools, and receives jobs to work on which it archives in a database. It then acts as a stratum server to our mining hardware, using a single miner per mining algorithm to produce valid work for these pools.

Mining pools usually disconnect miners that don’t produce work, so in order to do our monitoring we actually have to run mining hardware as well. In addition to monitoring, we’re also contributing useful work, honestly mining in each of the individual pools.

We’ve been running this system since November 2019, and are collecting the work pools give out and how and when new blocks are gossiped on the peer-to-peer networks. We are then analyzing this data for unexpected behavior and anomalies. The mining jobs that the pool sends us contain a number of interesting aspects that we can correlate to the data we observe using our full node, for instance:

Block hash

Each job contains the hash of the block it’s trying to build on top of. This should be the publicly known tip of the blockchain (i.e., the most recent Bitcoin block on the chain with the most work), since that’s the chain we want to extend with the new block we’re trying to find. If this is not the tip of the chain we’re mining, it could indicate a number of things:

• If we don’t know this block hash at all, then the mining pool is potentially engaging in selfish mining. The network doesn’t yet know about the block that we’re working on.
• If we’ve seen this block on a different blockchain, then the pool could be mining on a different chain than the one we expect. For example, a pool advertised as mining BTC might direct some hashrate to BSV, perhaps because the reward is more favorable. This is possible because Bitcoin and Bitcoin SV share the same proof-of-work function, SHA256, and thus the same type of hardware is effective at mining both.

Coinbase transaction.

The first transaction in every block is the pool operator paying rewards to themselves. This transaction is included in the job sent to the miner, allowing the miner additional space to put random data (nonce space) while mining. This transaction contains identifying information such as which key the rewards are paid to. Linking blocks in the blockchain to mining pools is generally done by looking at the payout address of the coinbase transaction. It also contains various marker data that can be used to identify the mining pool. It is possible to link blocks from the blockchain to these mining jobs using this identifying information. Mining pools could decide to include an unknown pay-out address (that they still control) and/or the marker of a different mining pool — to attribute blocks to a different pool or to “unknown” hashrate. While this might seem far-fetched, it’s a possibility allowing pools to conceal their true hashrate. It is risky for a single pool to dominate the hashrate of a coin since users are at risk of double spends and the miners might leave, but there’s economic incentive to do this if the pool operator can get away with it: more miners means more income to the pool.

Merkle proof of the coinbase transaction.

The block header of each block contains a cryptographic proof that commits to all the transactions in the block. Since miners change the coinbase transaction to use the extra nonce space, they need more of the Merkle tree to re-calculate this proof after the transaction is altered. We can learn a few things from his merkle proof in the mining job:

• We can take the same Merkle proof from blocks on the chain to see which jobs included the same transactions (besides the coinbase) as the block that ended up being appended to the ledger.
• We can identify mining pools that mine on empty blocks (blocks with only a coinbase transaction), because the Merkle proof will be empty. From this, we can see how often and how long mining pools ask their miners to mine empty blocks, and evaluate if this is longer than it absolutely needs to be. Mining empty blocks is unhealthy for the network because it decreases total throughput.

Moving forward

Mining pools play a vital role in the security of proof-of-work networks and therefore deserve to be monitored more closely than individual miners currently do. Pool Detective is already uncovering threats, and we’ve just started. With more resources, we’d expand our work in the following ways to effectively monitor more networks at scale and monitor more operations:

• Monitor more messages on the P2P networks. Right now we’re just monitoring blocks. If we saved and analyzed all messages on the P2P network, we could create a way to detect things like transaction censorship and mempool attacks, which could be important once Lightning is more widely deployed. The information on the P2P network, observed from multiple places, can help us understand what kind of work we should expect our miners to receive. We can match that against what we actually receive to search for anomalies.
• Design a compact, self-hosted Pool Detective so more miners can monitor. Ideally, everyone could run this for themselves. We think we can create a way for individual miners to monitor, ensuring they’re mining on top of the expected chain tip — and if not, report or switch to a different pool.
• Add more proof-of-work networks. In order to reliably identify unknown or suspicious blocks from mining pools (especially pools from hash rental markets) we need to rule out that the work is not from a lesser-known (but valid) proof-of-work chain. This means adding and maintaining more cryptocurrency nodes.
• Educate the community. People aren’t necessarily talking about these risks yet, but they will as the ecosystem grows. We need to better explain the potential attacks that could happen, how they affect businesses built on Bitcoin and other digital assets, and how monitoring and detection can help mitigate them. We intend to help quantify this risk and cultivate awareness of it.

We’re currently in the process of analyzing all the data we’ve collected and are moving forward with three immediate next steps:

1. We found and reported unexpected mining behavior in one of the top mining pools. We expect to have a report ready to share soon.
2. We’re working on a video series explaining this work in more detail. Follow the DCI on Twitter (@mitdci) or subscribe to our YouTube channel to be notified when episodes are posted.
3. We’re working on analyzing all our data and sharing it through a public website which will allow anyone to query our dataset through an API. Work in progress can be seen at https://pooldetective.org.

If you have any suggestions or ideas, feel free to leave a comment below or reach out to pooldetective@mit.edu.

Pool Detective is one part of a comprehensive effort at DCI to improve the security and robustness of global cryptocurrency networks. Please reach out if you’re interested in learning more or supporting our work.

Authors: Gert-Jaap Glasbergen, Neha Narula