Difficulty adjustment mechanism

[BTCgithub]

Apologies in advance as I'm not a dev, but I'm following the topics here closely.

With SegWit2x support currently at 90%, at hard fork we'd expect to see at least a 10% loss in hash rate, possibly more with politics/defections.

Considering a scenario where a minority chain continues (which is not 51% attacked by the majority for some reason, POW change, other) and pulls 10-25% of the hash rate, would an automatic difficulty adjustment be helpful?

This seems to be the main feature that saved Bitcoin Cash from failure and may be something to learn from. We wouldn't see a hash rate loss as dramatic as they did, but some amount of auto difficulty adjustment could be helpful to prevent network disruptions/delays as we adjust.

Ref: https://reviews.bitcoinabc.org/rABC7ad1105f43d7bff158d4b5c882ab9bf1b74d6cce

[christophebiocca]

Let's use 50% hashrate loss as an example.

Then network capacity (in tx per second) will remain the same. Then after about 1 month, a difficulty adjustment will get us back to 10 minutes per block.

Bitcoin Cash split off with a tiny minority of hashpower, which is why waiting for a normal difficulty adjustment wasn't going to work for them at all.

The downside of introducing any new difficulty adjustment code is that it can break even SPV clients, which we're trying hard not to.

[BTCgithub]

Ah cool, right due to the block size increase.

So with a worst case of 2MB Blocks + 50% existing Hash Rate we'd have the same tx/s and ~20 minutes/block. 2MB Blocks + 75% Hashrate would yield an increase of 50% in tx/s and ~15 minutes/block until the 1 month adjustment if I follow.

Thanks for everyone's work so far!

[christophebiocca]

75% Hashrate would yield an increase of 50% in tx/s and ~15 minutes/block until the 1 month adjustment if I follow.

At 75% it takes ~3 weeks for the recalculation to happen (the recalculation interval is 2016 blocks, not any fixed period of time). Otherwise yes, that's accurate.

[WuCris]

Considering a scenario where a minority chain continues (which is not 51% attacked by the majority for some reason, POW change, other) and pulls 10-25% of the hash rate, would an automatic difficulty adjustment be helpful?

Difficulty stopping a minority chain from surviving isn't a flaw, it's a feature. The reason why BitcoinABC does this is because they want the chain to survive whether miners want it or not. But in order to resolve consensus failure we need Bitcoin to understand if the hashrate isn't behind it it's dead.

For example look at Bitcoin Core. If Segwit2x gets 90% of the hashrate then 10% is left on the legacy chain block times take several hours to solve on that chain and months for readjustment target to be reached causing miners to ditch this chain as block reward is far and few and users ditch it as it's slow further causing those left behind to ditch the chain and it dies an honorable death and the Segwit2x chain suceeds it and becomes Bitcoin.

This goes both ways. If miners only give Segwit2x 10% of the hashrate then it'll die.

If miners spread hashrate between the two chains then they're both given a fighting chance as should they then be given.

Think if we change these rules then that says it's acceptable to A) have a chain be born when it doesn't have the hashrate required to secure it and that B) If an other chain was to ever succeed the Segwit2x chain then both chains would be allowed to live on rather than conceding to the one with more hashrate.

It doesn't make sense to modify difficulty rules because that fundamentally changes Bitcoin's consensus resolution formula.

[AllanDoensen]

@BTCgithub It does not look like the segwit2x chain will have the lowest hashrate so it is not a concern here. Maybe you could suggest this feature over at the core github repo where it would be more useful?