Topic: Rapid decrease in mining power? (Read 1389 times)

That happened to Yaccoin (not to be confused with Yacoin with 1 C).  It was released and immediately the difficulty jumped into the 60k range for a few hours, then the network hash rate dropped to very very low.  The programmer recoded and put in a Scrypt  re-target using Kimoto's Gravity Well so if a sudden increase in hashing power arrives, the difficulty increases immediately and if there is a large dropoff, then once a block is solved, it is decreased again.  Works great!  That way, if someone decides to point a few GH/s of scrypt power at the coin, it goes up a lot and very quickly to compensate, and once the miner is gone, it drops back.

Several altcoins have stalled because a multipool mined for a bit, then left as difficulty adjusted way, way upwards. The remaining miners are left with a difficulty that is impossibly high for their aggregate hashing power, so they start dropping off, which makes it even worse for those still sticking around. A little bit different to your scenario, but it does demonstrate the potential issues with a long retarget period.

A 50% reduction would still be recoverable.  Blocks would take twice as long and within 1-4 weeks it would update and be back to normal.  Even a 75% reduction while painful would still be manageable.  Blocks would take on average 40 minutes (most places would probably reduce the number of confirmations as 6 is beyond stupid for most transactions anyways) and in 2-3 months things would be back to normal.

If you mean a 99% reduction then yes Bitcoin probably couldn't recover from that without a hard fork in the code.  If there was a 99% reduction with no hope of hashrate rising 100x in the near term, most people would support a hard fork over a dead chain.

Of course this is really a non-issue as a 99% reduction is highly implausible and even if it wasn't it now means 10 minute block or not the network is 100x easier to attack.  The most probable reason you see a 99% reduction in Bitcoin hashrate is because the network is already dead from some other reason.

I have wondered about this as well. It seems to me that the decrease in the number of blocks being hashed could cause a backup in transactions being processed. Probably not currently, but in the future when there are more transactions being done.

I'd like to see the difficulty adjusted every 1024 blocks for downward adjustments and the upward adjustment period left as is. This just feels right to me.

Would this work better or worse than the current system?:

Let the last difficulty change happened at block X

MT(Xi,Xj) = median timestamp (in days) of block Xi, timestamp of block Xi+1 .... timestamp of block Xj-1, timestamp of block Xj

If for any positive integer n < 2016, [MT(X-10+n,X+n) - MT(X-11,X-1)] > 14

With the smallest n, difficulty is multiplied by difficulty factor DF = (n / 2016) starting at block X+n+1

If there is no such positive integer n,

Difficulty is multiplied by DF = {14 / [MT(X+2006,X+2016) - MT(X-11,X-1)]} starting at block X+2017

We may put further restrictions on DF, for example 0.5 <= DF <= 4

In case of increase in hashing power, the difficulty will always increase before the 14th days, just like the current system

In case of decrease in hashing power, the difficulty will always decrease on the 14th day.

If the hashing power decrease to 50%, the difficulty will halve on the 14th day. Average block time will be 20 minutes in the first 14 days, and will be 10 minutes after difficulty adjustment. With the current system we will have 20 minutes block time for 28 days.

If the hashing power decrease to 25%, (with the lowest DF restriction) the difficulty will halve on the 14th day, and halve again on the 28th day. Average block time will be 40 minutes in the first 14 days, 20 minutes in the next 14 days, and 10 minutes after the 28th days. With the current system we will have 40 minutes block time for 56 days.

Weird, I thought it would have caught on elsewhere.
http://techland.time.com/2011/05/23/report-police-confuse-bitcoin-miners-power-use-for-weed-grow-op

Internet connection uses more than enough electricity for a few light bulbs.

In comparision, USB ASICMiners use much less than that.

This can only be done in the United States of America, not in the free world.

Yes, welcome to north Korea 

True, but when you can raid the house of anyone who uses more than enough electricity for a few light bulbs under the guise of the "war on drugs", you can shut down miners over a few Mhash/s pretty quickly

Mining could be completely anonymous with TOR. The ONLY practical way for government to ban mining is to shutdown the internet. Who care bitcoin when the internet is already shut down?

Whoptie do, blocks are expectation 20 minutes for a month.

Difficulty being hesitant to change improves security against isolation and decreases the amount pumping of difficulty by variance.

By "government disaster", I meant "government caused disaster". For example, all of the EU bans mining. >50% permanent reduction in mining

Yes, a power shortage, natural disaster, or government disaster could cause a sudden and permanent 92% reduction in hashrate and that would be bad. Wait, what?

The difficulty is changed every 2016 blocks (2 weeks). When the amount of mining power stays the same, this works fine because there's still a block every ~10 minutes. If there's a sudden increase in mining power (ASICs), this works fine because there's a block every couple minutes and the difficulty is fixed much sooner.

But, what would happen if lots of Bitcoin miners in the world had to stop mining for one reason or another (power shortage, natural disaster, government disaster). If mining power dropped suddenly so that there was only a block every 2 hours, it would take almost half a year for the difficulty to be fixed.

Wouldn't this be a problem? It's kind of a catch-22, the network needs more miners to speed up blocks in order to live without more miners