What (if any) mechanism is there to protect against a massive hash rate drop?

[kjj]

The bug is that the timestamp difference is calculated on the wrong blocks.  If you change it, then the new software will be instantly incompatible with the old software, and they will never, ever, ever reconverge.  That is a hard fork.

That is the only bug that I'm aware of in the difficulty code.  You are talking about something entirely different, which is not a bug, but a design decision.  The looseness allowed in block timestamps is something else that generates a bunch of whining and "good" ideas for fixing, but so far, no one has actually come up with a compelling argument on why the numbers they pulled out of their ass are better than the numbers satoshi chose.

[TierNolan]

The bug is that the timestamp difference is calculated on the wrong blocks.  If you change it, then the new software will be instantly incompatible with the old software, and they will never, ever, ever reconverge.  That is a hard fork.

[Edit]Updated the numbers[/edit], since it is backwards looking.

My suggested solution, that the 2 blocks in question must have nearly the same timestamp doesn't cause a fork at all.  The reason the bug works is that it lets you cheat the timestamp system.

The bug is basically that you can have something like this

Note:
You would actually start around 2 months (4 difficulty periods) before current time.
The end time may not be more than 2 hours into the future.

Block 2160000: 2010: Jan 1, 9:00am
...
...
...
...

Block 2162145: 2010: Jan 1, 9:01am
Block 2162146: 2010: Jan 1, 9:02am
Block 2162147: 2010: Jan 1, 9:03am
Block 2162148: 2010: Jan 1, 9:04am
Block 2162149: 2010: Jan 1, 9:06am
Block 2162150: 2010: Jan 1, 9:07am
Block 2162151: 2010: Jan 1, 9:08am
Block 2162152: 2010: Jan 1, 9:09am
Block 2162153: 2010: Jan 1, 9:10am
Block 2162154: 2010: Jan 1, 9:11am
Block 2162155: 2010: Jan 1, 9:12am
Block 2162156: 2010: Jan 1, 9:13am
Block 2162157: 2010: Jan 1, 9:14am
Block 2162158: 2010: Jan 1, 9:15am
Block 2162159: 2011: Jan 1, 9:00am

Time: 1 year
Difficulty: X 0.25

----------------------------------------------

Block 2162160: 2010: Jan 1, 9:16am
......
Block 2164319: 2011: Jan 1, 9:00am

Time: 1 years
Difficulty: X 0.25

----------------------------------------------

Block 2164320: 2010: Jan 1, 9:32am

The start and the end of the difficulty period are in bold.  This gives a time of 1 year to get 2160 blocks.  Suffice to say that causes a drop in difficulty.  In fact, it hits the limit and the difficulty drops by a factor of 4 (max drop allowed).

However, all the blocks have valid timestamps.  The rule is that a block must have a timestamp that is higher than at least 6 of the last 11 blocks.  That is true for Block 2162160 even though it jumps back by 100 years.

You then pull the same trick on the next 2160 blocks.  The 100 year in the future block is ignored.  

If you start with a block a few weeks previously, you can gain a full difficulty period and only use up 2160 seconds worth of timestamps.

If you required that last block in the difficulty period was nearly equal to the first block in the next difficulty period (say within 2 hours), then you prevent exploiting the adjustment.

[evilpete]

2016 blocks is a feature, not a bug.

Yes, it has some downsides, but it is also the mechanism that ensures that forked chains don't take on a life of their own.

If bitcoin could rapidly re-target difficulty then it potentially makes forked chains viable.  And that is an even worse outcome.

[pyra-proxy]

yes but firmware crash on all ASICs them what!!!! or hardware flaw, they let the smoke out...dead.


then what.

And how is that easier than upsetting the difficulty repeatedly on purpose over a span of Months vs. a span of Days/Hours before having to come back and repeat the task again?....  This is effectively what is happening to Terracoin right now, and I bet if you ask most users, would you prefer the namecoin experience (where it was taking many months to have a difficulty drop, and block times that were numbering many hours) or the Terracoin experience (where, ya hashing could hop in and out repeating in a shorter time than before but at least difficulty fixes itself fairly rapidly when the disproportionate hash rate comes and goes)

What I'm trying to say is that upsetting difficulty is easy both ways, the "Terracoin" way though leaves the end user with a workable network, whereas the current bitcoin way leaves the end user with a horrible system to operate on for a long time....  I would think the latter is a lot more damaging to the adoption rate.

Terracoin is weak and desperate and needs to defend against the top dogs somehow, even if it has drawbacks. The best defense of bitcoin is being  the ultimate top dog.

YET TRC survived and thrives....

worth taking a good look at the retarget code used

legit concern here

No it's not legit. To make it painfully clear: If the ASIC miners coming from bitcoin pumping the difficulty in Terracoin would have instead 51%'ed it, Terracoin would be dead. They probably didn't because Terracoin has not enough value (yet).

On the other hand, all Terra- and other altcoin miners together are not strong enough to do the same to bitcoin, not even close (or a 51% attack would be close), and that's the best defense there is.

But almost everything is better than taking experimental code requiring a hard fork.

Also can't forget the double-tap... a malicious entity not caring for the value of bitcoin as it threatens their sovereignty over some aspect of the global financial machine, buys up enough asic devices to command say 49% of the btc network (note not needing 51% to do this), runs them hard to reach maximum difficulty, hoarding their earnings, transfers the coins to an exchange and dumps (most likely earning their expenses in running this form of attack) then shuts off their asics, none the poorer and bitcoin is left in the wake of extremely hard to solve long duration blocks making the chain dysfunctional.  Solving this problem after the fact shows the vulnerability too late slowing adoption at best, seeing adopters leaving at worse case (and very likely).  Since blocks are so slow and coin price plummets many of the previous hashers, hashing for profit may be deterred to other chains or await a time when their cost to operate equalizes with their profit expectations....

[gmaxwell]

a malicious entity not caring for the value of bitcoin as it threatens their sovereignty over some aspect of the global financial machine, buys up enough asic devices to command say 49% of the btc network (note not needing 51% to do this), runs them hard to reach maximum difficulty, hoarding their earnings, transfers the coins to an exchange and dumps (most likely earning their expenses in running this form of attack) then shuts off their asics, none the poorer and bitcoin is left in the wake of extremely hard to solve long duration blocks making the chain dysfunctional

.  Twenty minute blocks for four weeks is hardly "dysfunctional" esp since blocks that long or longer happen with fair regularity.

[kaerf]

a malicious entity not caring for the value of bitcoin as it threatens their sovereignty over some aspect of the global financial machine, buys up enough asic devices to command say 49% of the btc network (note not needing 51% to do this), runs them hard to reach maximum difficulty, hoarding their earnings, transfers the coins to an exchange and dumps (most likely earning their expenses in running this form of attack) then shuts off their asics, none the poorer and bitcoin is left in the wake of extremely hard to solve long duration blocks making the chain dysfunctional

.  Twenty minute blocks for four weeks is hardly "dysfunctional" esp since blocks that long or longer happen with fair regularity.

At what point does it become dysfunctional? (serious question)

I was going to retract my original question when I realized 50% market share would only double the time between blocks (at most for 4 weeks), but then I thought...4 weeks of 20 minute blocks would be pretty disruptive.

My original concern was that Terracoin was having a problem finding a block for days....but I see that as unlikely happening in this context unless some vendor gets 99% market penetration.

Surely, there must be some threshold at which users/miners are so discouraged that they start leaving the network....thus compounding the problem. Transaction/Confirmation time is already a complaint for many people...

[pyra-proxy]

a malicious entity not caring for the value of bitcoin as it threatens their sovereignty over some aspect of the global financial machine, buys up enough asic devices to command say 49% of the btc network (note not needing 51% to do this), runs them hard to reach maximum difficulty, hoarding their earnings, transfers the coins to an exchange and dumps (most likely earning their expenses in running this form of attack) then shuts off their asics, none the poorer and bitcoin is left in the wake of extremely hard to solve long duration blocks making the chain dysfunctional

.  Twenty minute blocks for four weeks is hardly "dysfunctional" esp since blocks that long or longer happen with fair regularity.

At what point does it become dysfunctional? (serious question)

I was going to retract my original question when I realized 50% market share would only double the time between blocks (at most for 4 weeks), but then I thought...4 weeks of 20 minute blocks would be pretty disruptive.

My original concern was that Terracoin was having a problem finding a block for days....but I see that as unlikely happening in this context unless some vendor gets 99% market penetration.

Surely, there must be some threshold at which users/miners are so discouraged that they start leaving the network....thus compounding the problem. Transaction/Confirmation time is already a complaint for many people...

What about in 4 weeks when they rinse/repeat... and then another month later... and then... get the idea?  20 min blocks is I would think unacceptable to most and very damaging to the bottom line of your honest miners....

[kaerf]

What about in 4 weeks when they rinse/repeat... and then another month later... and then... get the idea?  20 min blocks is I would think unacceptable to most and very damaging to the bottom line of your honest miners....

I think a familiar old argument is that if you have that much hashing power, it'd benefit you more NOT to disrupt the network (unless you're a government trying to take down bitcoin). Short of whitelisting hashing power to certain manufacturers there's little that can be done to prevent an entity with really deep pockets from messing with the network (BTW, I think there actually are measures that ASIC manufacturers have or should have taken to be white/blacklisted...not sure where that thread is though).

Again, my original concern is with an accidental "attack" due to a hardware/software failing for a significant amount of time.

[Maged]

Surely, there must be some threshold at which users/miners are so discouraged that they start leaving the network....thus compounding the problem. Transaction/Confirmation time is already a complaint for many people...

That's part of Satoshi's genius in decreasing the block subsidy over time. Once there is no block subsidy, miners could care less if blocks started taking 20 minutes one day, since they would still make the same amount of money over time. It might be a problem for users, but I doubt that waiting 2 hours instead of 1 hour for 6 confirmations would be a big deal in most cases.

[kjj]

The bug is that the timestamp difference is calculated on the wrong blocks.  If you change it, then the new software will be instantly incompatible with the old software, and they will never, ever, ever reconverge.  That is a hard fork.

My suggested solution, that the 2 blocks in question must have nearly the same timestamp doesn't cause a fork at all.  The reason the bug works is that it lets you cheat the timestamp system.

The bug is basically that you can have something like this

...example snipped...

I'm getting tired of saying it.  You are talking about something totally different.  The bug is that the window is calculated on a range of blocks that is offset by one from the blocks it actually should be looking at, leading to a tiny inaccuracy.  The inaccuracy sums to zero in the long run, which is why no one really cares about it.

Amusingly, you are also totally wrong.  No node on the network will accept a block that appears to come from more than a few hours into the future.

[TierNolan]

Amusingly, you are also totally wrong.  No node on the network will accept a block that appears to come from more than a few hours into the future.

Ug, right.  You have to fork with blocks in the past.

However, it still doesn't invalidate what I suggested.

If most clients simply refuse to accept blocks where the transaction blocks differ by more than 2 hours, you can negate the effect.

The exploit was to allow a 51%+ cartel to generate a huge number of block and thus minting fees.

You start with a block at least 2160 * 4 blocks ago (around 2 months). 

You do 2 weeks of hashing and then set the last block to 5 minutes ago (and all the other blocks within a few seconds of the start timestamp).  That gets you 2160 blocks in minting fees.  That is all valid.  The difficulty drops by a factor of 4.  You can then mint another 2160 blocks (at half difficulty) with a slightly later start time.  This gets you another 2160 blocks worth of minting fees.

You can keep repeating over and over.  Each time you get 2160 blocks worth of minting fees for half the previous time.

You need to complete 2 months worth of hashing and then your chain has higher POW than the main chain.  You might even include all transactions from the main chain.

2160: 14 days
2160: 7 days
2160: 3.5 days
...

After 28 days you would have an infinite number of blocks.  In practice, you will hit difficulty one by then.

So for your 2nd month, you mine a massive number of difficulty one blocks and direct the minting fees to yourself.

At the end of the 2nd month, you can publish all your blocks.  Most of them will be headers only.