Pool shutdown attack

[jvierine]

I just thought about one possible attack that could potentially disrupt block generation and potentially halt transaction confirmations. This could also happen by accident, if many of the largest mining pools were to shut down (e.g., by a hostile goverment).

Because of the increasing difficulty in block generation, bitcoin is moving towards an ecosystem of few large mining pools, which control most of the computation speed of the network. They are also highly centralized in nature. I think there is a risk associated with this.

If I understand correctly, the difficulty adjusts every N generated blocks. Now what if this difficulty has been adjusted to a very large value, and then suddenly most of the computing power is suddenly removed, e.g., by several of the largest mining pools shutting down. This would have the effect of significantly slowing down block generation rate (as most of the computing speed has been removed from the system), which would slow down transaction confirmations to a grinding halt. Many of the users in the pools have fairly slow hash rates, so they would most likely not start solo mining, as they would not see a steady income of bitcoins.

Has anybody though about this? Is there a safety mechanism to readjust the difficulty in case no blocks are generated in some period of time?

[1715135953]

1715135953

[1715135953]

1715135953

[1715135953]

1715135953

[kjj]

This is trivial to counter:  just promote the flexible mining proxy.

[Matt Corallo]

If I understand correctly, the difficulty adjusts every N generated blocks. Now what if this difficulty has been adjusted to a very large value, and then suddenly most of the computing power is suddenly removed, e.g., by several of the largest mining pools shutting down. This would have the effect of significantly slowing down block generation rate (as most of the computing speed has been removed from the system), which would slow down transaction confirmations to a grinding halt. Many of the users in the pools have fairly slow hash rates, so they would most likely not start solo mining, as they would not see a steady income of bitcoins.

These kinds of things have been discussed at length before...anyway, that shutdown wouldn't last long.  There are already a ton of pools and more popping up daily.  Switching takes a matter of seconds so even if many of the largest pools were shut down, the time the network has such low power would be small (probably only 30 minutes or so before the majority of mining power was back online) making the difficulty not change too much from where it would have been on the next adjust.

[rezin777]

127555    2201f7d916...    2011-05-29 22:41:30    43    1472.65095723    21.143
127554    15fa32c760...    2011-05-29 22:13:38    37    877.09812426    23.145
127553    1de06a4a0a...    2011-05-29 21:46:22    47    2052.27689526    17.552

Only 2 blocks in 55 minutes due to deepbit being DDOSed. Then it starts getting better (but not great) as people realize deepbit is down and switch.

While it isn't a show stopper, it certainly isn't what I would consider healthy for the network.

Miners in deepbit don't seem to care about the health of the network, or even the fact that they make less BTC there compared to other pools, so I don't expect them to be bright enough to use things like instantaneous pool switching software. Not that you even need switching software, a low priority mining window in the background already pointed to another pool works fine.

If a future attack is coordinated enough to take down all the major pools at the same time, the network would be in shambles as people figure out how to solo mine.

[Steve]

I don't think this is a huge problem, but it could be improved.  If there was widely available, somewhat standard pool software that made it simple for anyone to setup a pool, then I think you'd see a lot of smaller, private pools being created.  All a pool really needs is a few blocks/day to counter the effects of difficulty adjustments.  Right now, 50Gh/s is sufficient for that.

[Vladimir]

The netwrok will self heal and route around the damage.. there are very strong incentives for that in place.

[2_Thumbs_Up]

I'm thinking a bit of the difficulty adjustments. Why is it that we only change difficulty every ~2 weeks. Since luck plays a part in block generation, difficulty probably needs to be somewhat stable. But if the difficulty would adjust faster than it currently does, we would probably improve the defense against a similar attack, since a lowered difficulty would provide even stronger incentives for miners.

[Vladimir]

I think there is no reason to change bitcoin protocol to help pool operators. That would be like bringing GUI libs into linux kernel to make GUI quicker. Ohhh wait.... M$ thought once that this was a good idea.... nevermind...

Pool operators and miners will figure out how to mine during DDOS attacks or let smarter and nimbler miner to do all the work and rip all the reward. Why would we want to institute a nanny state here.... survival of the fittest is quite a nice paradigm which worked so well until recently...

[2_Thumbs_Up]

I wasn't really suggesting a change of the protocol, just a discussion of the pros and cons of the current way. And it wasn't to help pool operators, but to make sure that the incentives to provide a strong network are as strong as possible at all times, even during attacks. I don't really think a discussion about optimization and strengths/weaknesses is the equivalent of a nanny state.

Lets say someone does a huge coordinated attack like this right after a difficulty increase. I think it could be somewhat of a problem that this doesn't increase in any higher profitability for the rest. Obviously some miners would still find their way back mining solo. But some others would maybe not think it's worth it without the pooling feature. Assuming the attacker has the capacity to do this for a prolonged period of time, this could potentially lead to several weaks of a slower network.

I don't really know if this is actually an issue or not. But irregardless if it is, the questions i had was, would faster difficulty adjustments make the network stronger against attacks like this? And would there be any severe drawbacks to this?

[ene]

Many of the users in the pools have fairly slow hash rates, so they would most likely not start solo mining, as they would not see a steady income of bitcoins.

Yes, but most of them would switch to solo mining.

I hope future versions of miners will have an option to automatically fall back to solo mining if a pool appears to be offline, but you are still connected to the bitcoin network.

[2_Thumbs_Up]

Many of the users in the pools have fairly slow hash rates, so they would most likely not start solo mining, as they would not see a steady income of bitcoins.

Yes, but most of them would switch to solo mining.

How sure can we be of this? It's basically like a lottery but with a positive expected return. The problem is that very many doesn't care about their expected return when they play lotteries. They usually care about the joy and excitement more. How can we actually know that most miners will find their way back if the chance of getting payed is ridicilously low?

[ene]

How sure can we be of this? It's basically like a lottery but with a positive expected return. The problem is that very many doesn't care about their expected return when they play lotteries. They usually care about the joy and excitement more. How can we actually know that most miners will find their way back if the chance of getting payed is ridicilously low?

How can we be sure of anything? Personally, I'm sure enough. A lot of the mining power comes from graphic cards purchased specifically for bitcoin mining. These miners are in a pool because it works better for them, but if pools weren't available, they would still solo mine in the hope of recouping their investment.

It's basically like a lottery but with a positive expected return.

So it's not a lottery? They aren't in it purely for fun.

[2_Thumbs_Up]

How sure can we be of this? It's basically like a lottery but with a positive expected return. The problem is that very many doesn't care about their expected return when they play lotteries. They usually care about the joy and excitement more. How can we actually know that most miners will find their way back if the chance of getting payed is ridicilously low?

How can we be sure of anything? Personally, I'm sure enough. A lot of the mining power comes from graphic cards purchased specifically for bitcoin mining. These miners are in a pool because it works better for them, but if pools weren't available, they would still solo mine in the hope of recouping their investment.

Yeah I'm with you. +EV is +EV after all. Even if some people are irrational, other people would just take advantage of the opportunity. I'm getting a bit worried about the possibility of a negative expected return for miners as I expressed in this thread though: http://forum.bitcoin.org/index.php?topic=10708.0

It's basically like a lottery but with a positive expected return.

So it's not a lottery? They aren't in it purely for fun.

Mathematically, it's even better than a regular lottery. The point I tried to make was that the physical activity of a regular lottery is probably part of the fun for the participants. But this should be irrelevant.

[gmaxwell]

The netwrok will self heal and route around the damage.. there are very strong incentives for that in place.

Apparently not.  It hasn't been healing when these big pools keep going down— we lose hashrate, and most doesn't come back until the pool does. In spite of the concerns for the stability and security of the bitcoin network— and in spite of actually losing money due to downtime and higher fees— people continue to use deepbit.

As I write this it's back to ~40% even after the outages a day ago.

[Vladimir]

The netwrok will self heal and route around the damage.. there are very strong incentives for that in place.

Apparently not.  It hasn't been healing when these big pools keep going down— we lose hashrate, and most doesn't come back until the pool does. In spite of the concerns for the stability and security of the bitcoin network— and in spite of actually losing money due to downtime and higher fees— people continue to use deepbit.

As I write this it's back to ~40% even after the outages a day ago.

How do you know this? All I can see is that after recent difficulty change hashing power stopped growing and has declined slightly. That's it. The difficulty change could do it on your own, pools or no pools. At recent peak hashing power was around 6Thps, now it is around 5.3 Thps. This is barely above 10% drop. There can be many reasons for 0.7 Ghps worth of miners dropping off: summer heat, fired rogue IT admins, some 'miners' cannot comprehend how to switch pool or switch to solo mining, mommy locked up basement after she saw electricity bill etc.. Bohoo.. big deal. Who cares?

[kjj]

No one has any idea where the error bars on the hash rate graphs should be.  On the 1 day line, they will be astronomically huge (not to mention the 8 hour window, lol).  Like several times the width of the plotted channel huge.

DO NOT MAKE ASSUMPTIONS BASED ON THOSE GRAPHS.  They are estimates, not measurements.

[ene]

It hasn't been healing when these big pools keep going down— we lose hashrate, and most doesn't come back until the pool does.

We lose hashrate, but do we lose too much hashrate? 

[gmaxwell]

No one has any idea where the error bars on the hash rate graphs should be.  On the 1 day line, they will be astronomically huge (not to mention the 8 hour window, lol).  Like several times the width of the plotted channel huge.

DO NOT MAKE ASSUMPTIONS BASED ON THOSE GRAPHS.  They are estimates, not measurements.

I'm not making assumptions based on "those graphs". I'm looking at the highly improbable gaps between blocks that can only really be justified on the basis of large hashrate graphs. e.g. times 50 minutes or longer has a p-value of .0067 if the expectation is 10 minutes— lower considering that we'd been running a rate higher than one per ten minutes.

Unrelated, it's no "No one has any idea"— Those graphs _are_ a measurement but of a noisy process, however the process in which coins are found is well understood, and you can easily draw confidence intervals based on the known distribution and the number of points in the average. I'll nag sipa to do this. It would be reasonable.

[kjj]

No one has any idea where the error bars on the hash rate graphs should be.  On the 1 day line, they will be astronomically huge (not to mention the 8 hour window, lol).  Like several times the width of the plotted channel huge.

DO NOT MAKE ASSUMPTIONS BASED ON THOSE GRAPHS.  They are estimates, not measurements.

I'm not making assumptions based on "those graphs". I'm looking at the highly improbable gaps between blocks that can only really be justified on the basis of large hashrate graphs. e.g. times 50 minutes or longer has a p-value of .0067 if the expectation is 10 minutes— lower considering that we'd been running a rate higher than one per ten minutes.

Unrelated, it's no "No one has any idea"— Those graphs _are_ a measurement but of a noisy process, however the process in which coins are found is well understood, and you can easily draw confidence intervals based on the known distribution and the number of points in the average. I'll nag sipa to do this. It would be reasonable.

No, they are not measurements.  There is no way to measure how much work went into finding any given hash, unless you are actually monitoring each and every miner involved.

What these graphs do is divide the average amount of work to find a block by the actual time to find a given block.  Note that it is the "average" amount of work, not the actual amount of work.

Oh, and there is other nonsense around too.  Did anyone else notice the two consecutive blocks over the weekend, where the second block had a timestamp before the first block?  I'm pretty sure that block didn't really require a negative amount of hashing to get created.

[forbun]

Is there a good alternative to deepbit?