Topic: What (if any) mechanism is there to protect against a massive hash rate drop? (Read 1892 times)

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.

...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.

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.

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.

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....

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...

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

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....

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.

[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.

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.

A soft fork is banning something that was previously allowed.  However, since that exploit assumes that the attackers have > 51% of the hashing power, the distinction soft and hand fork changes.

You could add a rule that the last block in a difficulty period and the first block in the next difficulty period must have the a similar timestamp and reject the first block in the new re-targeting period if it doesn't meet that rule.  You could scan the blockchain and see what the largest difference was and use that (or say 30 minutes if lower).

All new clients could have that rule.  Forking the chain means that only the old clients are kicked and only then for as long as that chain maintains hashing power.  If the "economic majority" decides that the non-forked chain is the real one, then the only benefit to the attackers is that they can fool users of the old client.

You are missing my point.  A poorly chosen difficulty mechanism is a force multiplier.  It lets someone with considerably less than 50% of the network power fuck with you.

P.S.  The bug cannot be fixed with a soft fork.  It is an absolutely hard fork to change the number of blocks used in the calculation.

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


then what.

Your concerns are inherent if someone has > 51% of the hash power.

Rather than show 6 blocks required for security require 6 blocks worth of POW is required.  Clients would show that the chain has lost hashing power without completely locking up.

So, the conclusion is that if you can't generate enough hashing power, you can't assume the chain is safe.  However, the standard difficulty rule does help there anyway.


Yeah, they should soft fork that one out.  Require that the two blocks have the same timestamp (or the one after must have timestamp + 10 minutes of the old one).

Any asymmetric function for difficulty adjustment can be gamed.  If anyone with a bit of hashing power cared enough about the scamcoin de jour, they could use it to overwrite the current chain.  If they don't have quite enough hashing power for that, they can manipulate the future chain to exclude whatever they want excluded.  If you compensate for either of those attacks by adding state to the block acceptance mechanism, they can fork your network into oblivion.

Note that most of these things have already been done.  Feel free to search for the various threads where they have been discussed.  Sooner or later, everyone comes to the conclusion that Satoshi got it exactly right*, but there is usually a bunch of whining and crying along the way.

*  Well, almost exactly.  There is an off-by-1 bug in the difficulty calculation that throws things of by about a twentieth of a percent, but the bug is symmetric, so it doesn't change the security of the system.

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.

YET TRC survived and thrives....

worth taking a good look at the retarget code used

legit concern here

Total proof of work still increases and the "real" main chain should still be the highest.  Is there a specific flaw in it?

This is an insanely bad idea, just like it was the last 20 or so times it was suggested.