When do we know a mining pool really has more than 50% of the hash rate?

[davejh]

I've been generating more statistics based on Monte Carlo simulations. This time I've been looking at what would be the reported hash rate for a pool that actually has 50% of the network hash rate. Over a 24 hour period there's quite a spread of hash rates that can be inferred from the blockchain stats:

http://hashingit.com/analysis/31-51-percent-of-the-network

This isn't to say that a pool appearing to have 50% of the network hash rate doesn't pose a problem, but that it's more tricky than we might expect to decide that a pool has really crossed that threshold.

[1713582048]

1713582048

[-ck]

For a real "51%" attack, the pool would be quietly mining to a blockchain they're not transmitting anyway until they're ready to unleash it onto the world. In other words, you only will know after the fact and there is no way of knowing while they're preparing for the attack.

[davejh]

For a real "51%" attack, the pool would be quietly mining to a blockchain they're not transmitting anyway until they're ready to unleash it onto the world. In other words, you only will know after the fact and there is no way of knowing while they're preparing for the attack.

Agreed - anyone doing anything that involves public interactions with the blockchain is almost guaranteed to be be playing nicely because anything else they do will become obvious to an observer.

[jonnybravo0311]

As with your other articles, this one is well written and executed.  Great job.

Kind of off topic, but related to your articles.  You have one entitled "Reach for the ear Defenders!" that starts out talking about how noisy miners are, but then spends the rest of the article discussing theoretically what would happen if the hash rate stayed consistent for 52 difficulty changes.  While I enjoyed the article, I'm a bit confused with the title and first sentence

[davejh]

As with your other articles, this one is well written and executed.  Great job.

Kind of off topic, but related to your articles.  You have one entitled "Reach for the ear Defenders!" that starts out talking about how noisy miners are, but then spends the rest of the article discussing theoretically what would happen if the hash rate stayed consistent for 52 difficulty changes.  While I enjoyed the article, I'm a bit confused with the title and first sentence

In that one I was really looking at how much random noise is implicit in the way mining is set up. By keeping the hash rate changes out of the calculation the only cause of any changes is just the noise (a surprisingly large amount of it).

I have another set of sims running at the moment (will take a few hours to get the results) - I'm going to look at mining pool variances as I think there's an interesting story there too.

[os2sam]

When do we know a mining pool really has more than 50% of the hash rate?

When they find more than 50% of the blocks in a difficulty period?  Do I win a prize?

[nwfella]

Pretty decent article.  I agree with your 'Final Thoughs' as well (ya, chu might wanna change the spelling on that real quick;)

[DeathAndTaxes]

For a real "51%" attack, the pool would be quietly mining to a blockchain they're not transmitting anyway until they're ready to unleash it onto the world. In other words, you only will know after the fact and there is no way of knowing while they're preparing for the attack.

For a private entity this is true but pools can't hide their hashrate from the public. Say right now GHASH has 51% of the hashrate and they start mining an attack chain in private.  Now I am sure you understand this but most people seem to forget that their public hashrate (i.e. based on "legit" blocks added to the longest chain) would drop to 0 blocks per hour.   With 51% of the hashrate GHASH would be expected to out race the main chain by 2 blocks per day.   So to overturn a tx with 6 confirmations miners would have to see the reported blocks go from ~5 per hour to 0 per hour not for 1 hour, or 2 hours, or even 8 hours but for 72 hours in a row.  How many miners would keep mining on GHASH if they produced 0 blocks and thus 0 BTC in revenue for miners for 72 hours in a row.  My guess is next to none.  As soon as enough miners defect enough that GHASH hashrate fell they would quickly lose any chain of pulling off the attack. 

I don't trust miners to do the right thing, but I do trust them to notice that their pool hasn't found any block in 3 days.  Miners who leave simply looking out for their own bottom line will help to secure the network against that type of attack.

[davejh]

Pretty decent article.  I agree with your 'Final Thoughs' as well (ya, chu might wanna change the spelling on that real quick;)

Many thanks - fixed! I'm a terrible proof reader for my own articles 

[davejh]

For a real "51%" attack, the pool would be quietly mining to a blockchain they're not transmitting anyway until they're ready to unleash it onto the world. In other words, you only will know after the fact and there is no way of knowing while they're preparing for the attack.

For a private entity this is true but pools can't hide their hashrate from the public. Say right now GHASH has 51% of the hashrate and they start mining an attack chain in private.  Now I am sure you understand this but most people seem to forget that their public hashrate (i.e. based on "legit" blocks added to the longest chain) would drop to 0 blocks per hour.   With 51% of the hashrate GHASH would be expected to out race the main chain by 2 blocks per day.   So to overturn a tx with 6 confirmations miners would have to see the reported blocks go from ~5 per hour to 0 per hour not for 1 hour, or 2 hours, or even 8 hours but for 72 hours in a row.  How many miners would keep mining on GHASH if they produced 0 blocks and thus 0 BTC in revenue for miners for 72 hours in a row.  My guess is next to none.  As soon as enough miners defect enough that GHASH hashrate fell they would quickly lose any chain of pulling off the attack. 

I don't trust miners to do the right thing, but I do trust them to notice that their pool hasn't found any block in 3 days.  Miners who leave simply looking out for their own bottom line will help to secure the network against that type of attack.

This is actually one of the most insightful thoughts I've seen on the whole discussion :-)

I've commented before that I'm pretty sure that any attack via a mining pool would leave some pretty large footprints in the blockchain stats. Huge changes in the visible hashing of any large pool would be very clear, as would a very high orphan rate starting to appear, or fee-based transactions being ignored.

[lowbander80]

Its the unknown you see with blockchain

[os2sam]

So to overturn a tx with 6 confirmations miners would have to see the reported blocks go from ~5 per hour to 0 per hour not for 1 hour, or 2 hours, or even 8 hours but for 72 hours in a row.  How many miners would keep mining on GHASH if they produced 0 blocks and thus 0 BTC in revenue for miners for 72 hours in a row.  My guess is next to none.  As soon as enough miners defect enough that GHASH hashrate fell they would quickly lose any chain of pulling off the attack.

That's fine and dandy for pools who only have public hash rate from miners.  But what about entities, not necessarily a pool, that have enough of their own hash rate to exceed 50%?  That's the real problem.  Not, most likely, a pool with individual miners that have/had large hash rates.

[davejh]

So to overturn a tx with 6 confirmations miners would have to see the reported blocks go from ~5 per hour to 0 per hour not for 1 hour, or 2 hours, or even 8 hours but for 72 hours in a row.  How many miners would keep mining on GHASH if they produced 0 blocks and thus 0 BTC in revenue for miners for 72 hours in a row.  My guess is next to none.  As soon as enough miners defect enough that GHASH hashrate fell they would quickly lose any chain of pulling off the attack.

That's fine and dandy for pools who only have public hash rate from miners.  But what about entities, not necessarily a pool, that have enough of their own hash rate to exceed 50%?  That's the real problem.  Not, most likely, a pool with individual miners that have/had large hash rates.

That's the inherent risk with any public system. The sort of investment required to do this is pretty large though - it's certainly tens of millions of dollars and it wouldn't surprise me if it was nearer $100M.

Let's assume that someone wanted to do this now - they'd need to bring online about 125 PH/s of capacity in order to gain > 50% of the total system (which would now be 250 PH/s). Let's also assume that they can do this for $0.33 per GH/s (that's 3x lower than the current retail pricing levels) so that's an investment of just over $41M. They need to build somewhere to install that (that's either one huge data center or several smaller ones) so there's the cost of the facility and the cost of getting power to it. Let's assume that they can do this with 0.3 W/GH/s so they need 36 MW of power. Let's also assume that they're smart enough to put it somewhere where cooling is free.

In the short term I'd guess that they may cause some amount of the existing network to be decommissioned quicker but then a sustained attack may also cause existing miners to fight the attack and leave economically non-viable hardware running.

Our would-be attacker also has to sign up to fighting the difficulty changes so they'll have to plan to be able to install more capacity in order to stay ahead of everyone. If we assume a 15% difficulty change then every 12 days or so they'll need to bring online 15% more capacity, so that's an extra $6.2M. After 2 months their extra capacity requires $12M. At the 2 month point they'd have spent a little over $82M and now be consuming 72 MW of power.

Of course the other thing that they'll have to do is find ways to hide their hashing capacity because it will be very obvious once we start seeing huge numbers of orphaned blocks and I suspect we'd pretty quickly see some countermeasures that attempted to prevent our attacker.

It's certainly possible, but it's becoming a more and more expensive proposition by the day. I suspect that there are much higher value targets to spend $100M attacking.

[DeathAndTaxes]

That's fine and dandy for pools who only have public hash rate from miners.  But what about entities, not necessarily a pool, that have enough of their own hash rate to exceed 50%?  That's the real problem.  Not, most likely, a pool with individual miners that have/had large hash rates.

That was my whole point.  If Bill Gates tomorrow thought his mission in life was to destroy Bitcoin by a sustained 51% attack he could and there is not much anyone could do about it.  It would cost him a small fortune and his attack would be a massive sunk cost that he could never hope to recover but he could do it.  Worrying about a pool trying to perform a 51% attack using the resources of miners by proxy in a very public and easily disrupted manner is just silly.  

Of course my opinion is that any such disruption attack against Bitcoin would be a fools errand.   Killing Bitcoin isn't going to stop cryptocurrency any more than killing Napster stopped file sharing.   The concept is out there, it is open source, and uses strong cryptography.   If someone spends tens or hundreds of millions of dollars to "kill" Bitcoin something else will take its place, and maybe they disrupt that too at even higher cost, and then a dozen "4th generation" crypto currencies will replace that and then a hundred or more replace that.  Billions and billions of wasted dollars later you will probably see the "bittorrent" of crypto currencies.   Necessity is the mother of all invention.   It can't be stopped.   Of course anyone smart enough to have those kinds of resources should be smart enough to see the futility of that type of direct attack (or be able to hire someone capable of that).  

What is the point of killing bitcoin at huge cost only to have something better replace it.   Napster was regulatable, but once it was killed it spawned not a clone but an evolution of competing ideas which became ever more resistant to oversight and regulation.  Sure some of the ideas failed, some were poorly thought out, but people built upon those ideas.   Future iterations of the same general concept hardened themselves against the weaknesses of the earlier versions.  Today unauthorized file sharing is more widespread than it ever was when Napster was around.