By all accounts, the bitcoin difficulty algorithm does not seem to be a good one. If there is a fork due to miners seeking to maximize profit without regard to security, users, and nodes, the "better" coin could end up being the minority chain, at least for a time. If 95% of hashrate is really going to be biased towards using SegWit2x, BTC would face 20x delays in confirmations until the next difficulty adjustment, negatively affecting its price relative to BTC1, causing further delays from even more miner abandonment, until the adjustment. The 5% miners remaining on BTC do not inevitably lose by staying to endure 20x delays because they have 20x less competition. If the BTC price does not fall to reflect the decreased hashrate, the situation still seems to be a big problem for both coins: BTC1 miners will jump back to BTC, initiating oscillations between the two coins, potentially even worse than what BCH is experiencing due to asymmetric rise and fall coding in the difficulty algorithm and BTC miners switching back and forth to maximize profit. On the upside, BTC and BTC1 will not issue coins too fast since the algorithm is symmetrical.
I have worked a lot in trying to find the ideal difficulty algorithm for Zcash, Sumokoin, and Karbowanek. A karbowanek github thread shows my work (every failed alternative) this year. Zcash is an example of a coin that wanted to follow BTC exactly, but felt compelled to completely abandon the difficulty algorithm, like almost every other alt coin. I do not recommend Zcash's method because it take over 60 blocks to adjust to hashrate changes and a 6 block delay due to using bitcoin's MPT.
I recommend the following difficulty algorithm for Bitcoin, as fast, simple, and better than any other algorithm I'm aware of.
# Zawy v6 difficulty algorithm (modified for bitcoin)
# Alt coins see more complete v6 at
# http://zawy1.blogspot.com/2017/07/best-difficulty-algorithm-zawy-v1b.html
# Keep negative solvetimes to correct bad timestamps.
# Do not be tempted to use the next line.
# next_D = sum(last N Ds) * T / [max(last N TSs) - min(last N TSs];
# ST= Solvetime, TS = timestamp,
# set constants until next hard fork:
T=600; # coin's TargetSolvetime
N=30; # a nod to statistics. Smoother than N=15, faster response than N=60.
X=5;
limit = X^(2/N); # limit rise and fall in case of timestamp manipulation
adjust = 1/(1+0.67/N); # keeps avg solvetime on track
# begin difficulty algorithm
avg_ST=0; avg_D=0;
for ( i=height; i > height-N; i--) { # go through N most recent blocks
avg_ST += (TS[i] - TS[i-1]) / N; # Note: ST != TS
avg_D += D[i]/N;
}
avg_ST = T*limit if avg_ST > T*limit;
avg_ST = T/limit if avg_ST < T/limit;
next_D = avg_D * T / avg_ST * adjust;
# Tim Olsen suggested changing coin reward to protect against hash attacks.
# The method below also keeps number of coins issued per real time correct
# for the life of the coin.
# BaseReward = coins per block
next_reward = BaseReward * avg_ST / T;
Due to the limit and keeping negative solvetimes in a true average, timestamp errors resulting in negative solvetimes are corrected in the next block. Otherwise, one would need to do like Zcash and cause a 5-block delay in the response by resorting to the median of past 11 blocks (MPT) as the most recent timestamp, offsetting the timestamps from the difficulties that "caused" those solvetimes by 5 blocks.
Philosophical note: Even if BTC1 results in lower transaction fees for the user and better profits for the miner, it sets a bad precedence. Bitcoin was started as a way to stop banks from influencing the law (code) that governs our currency via its lobbying. It's hard not to see miners as an excellent parallel to banks and the Fed, creating coin and trying to influence the fees gained from coin transfers. If they successfully cause a fork to double the coin quantity, it is inflation all over again.
