GHASH.IO The Double Spend Threat

There has been a lot of talk on,, and other Bitcoin communities lately in regard to the threat of one mining pool obtaining 51% of the hashing power of the network. Specifically GHASH.IO, which is the mining pool that CEX.IO, the cloud mining provider, uses. The fear is that if a pool or a single miner controls a large amount of hashing power they can initiate a double spend. Essentially a double spend is when you send the same Bitcoin to two addresses with the goal of tricking the recipient controlling one of the addresses that they received payment when in actuality they didn't.

alt text for image

A good analogy for the traditional monetary system is that a double spend attack is like paying a merchant with a counterfeit dollar.

First lets go over what a double spend is:

A Double Spend attack can be performed in multiple ways, but most methods can be avoided by not accepting zero confirmation transactions, especially ones with no fee attached. The more confirmations you accept as a merchant, the harder and more expensive it will be for the person/entity sending the transaction to commit a double spend. The size of the transaction should dictate how many confirmations you wait before releasing the good or service. For example, it is usually safe to accept zero confirmations for the sale of a coffee, as long as the transaction has a fee attached to it. The fee being attached to the transaction is important because a no fee transaction can sit in the network for awhile, making it trivial for a potential attacker to initiate a double spend by executing another transaction with a fee attached.

For this reason, regardless of the amount of the transaction, nobody should accept a zero confirmation payment if there is no fee attached to it.

So how does this apply to a mining pool such as GHASH.IO achieving 51% of the hashing power of the network?

If a pool or single entity controls a majority of the hashing power they can initiate a double spend attack even after multiple confirmations. The more confirmations the payee waits to receive the payment, increases the cost of this type of attack and reduces the likelihood of it succeeding. Essentially the pool would keep mining blocks on their own, and once their fork is the larger chain, it will be accepted as the main chain by the rest of the network. This type of attack becomes easier to do as you control a higher percentage of the network but it can never be absolutely 100% effective unless one mining pool controls the entire hash rate. That means that an attacker can technically try and succeed with this type of attack with much less than 51% of the network, and it also means that an attacker can try and fail with this type of attack even if they have over 51% of the networks hashing power.

Game theory suggests that it is counter intuitive for a mining pool to attempt this type of attack because it reduces faith in Bitcoin, hurting the miners core business and reducing the value of any Bitcoin that they currently hold. However, if a mining pool is incentivized by an outside actor, through monetary payments or by shorting Bitcoin, it could be advantageous for the pool operator to initiate an attack.

That being said, it is theorized that if a mining pool were to try and execute a double spend, the individual miners would leave the pool at the first sign of an attack, as a logical response to protect their investment in Bitcoin and related mining hardware. This would usually be true but, because the majority of GHASH.IO's hashing power comes from cloud mining contracts on CEX.IO, the individual miners do not have control of their hardware.

CEX.IO controls the physical hardware, while the individual miners are merely financing it. For this reason, GHASH.IO is a bigger threat than any other pool, because they control the majority of their own hardware rather than relying on a loose coalition of individual miners.

Technically there is no way to tell how much hashing power each pool controls, only the pool operator knows the exact amount, but it can be estimated. The main method used to estimate hashing power is to divide the number of blocks solved by pool and divide it by the total number of blocks solved by all miners during a time period. This gives you a rough estimate of the amount of hashing power a particular pool controls. has a tool that provides this estimate to users at and it can be toggled to show a 24 hour, 48 hour, and 4 day estimate of total hash power per pool. Currently it shows GHASH.IO at 40% of the total hashing power over the last 24 hours as you can see below:

alt text for image

What can you do if you are currently a miner?

It is in the best interests of all Bitcoin miners and Bitcoin users in general, to support smaller pools. Centralization of hashing power is bad, and reduces the robustness of the Bitcoin network. Preferably, miners should use P2Pools which are more decentralized by design than traditional mining pools because the pool operator does not have sole control of the hashing power of the pool. You can find a P2Pool that is located geographically near you here.

What can you do if you are not currently a miner?

If you currently don't have any mining hardware and are looking to cloud mine to help support the network, you can rent mining hardware from NiceHash or BetaRigs and point it at a P2Pool. A solid guide on how to do that can be found here. This technique won't be profitable unless the Bitcoin price goes up, and in that case you would make more money by simply buying Bitcoin, so it should only be done as a way to help protect and support the Bitcoin network.

If you do not want to be a miner, you can donate to P2Pool miners using the built in donation function, creating further incentive for other miners to switch to P2Pool's from traditional pools. Blisterpool is a P2Pool that also provides an easy to use donation tool that provides donations to miners on all P2Pools for the good of the community.

Disclaimer: This post is intended solely to provide information. As I have no knowledge of individual circumstances and technical level, readers are expected to complete their own due diligence before proceeding with anything mentioned in this article. The topics discussed in this post are advanced and readers proceed at their own risk. Readers are expected to complete their own due diligence before purchasing or selling anything mentioned or recommended.