YAHF (Yet Another Hard Fork) is coming.

In this article I'll try to describe differences between incoming one (SegWit2x, btc1) and previous (ABC/BCH/BCC/fBTC whatever its name, I'll use ABC). https://i.imgflip.com/7rx3w.jpg

First of all: mining difficulty.

In previous fork

ABC coders correctly assumed, that it will be minority fork, and change well-known difficulty adjustment from "adapt it every 2 weeks" into "down it every time you need". This way they protect themselves from early fork death. ONLY because of this "Bitcoin Cash" still exists. Without this mechanism that fork would have block every hour from months, and probably would be abandoned by miners.

Incoming btc1 fork

not need cheating mechanism like that, for one easy reason: it is majority fork and it have over 80% support of current hashing power. How it will looks like in block times? "Old BTC" will have up to 20% current hashing power, what means over x5 slower block generation time. BTC will have block every 50 (or more) minutes. Totally useless. In contrast, "new btc1" will have blocks every 12 minutes (or less) and those block will have twice more capacity that previous BTC. Also, because of more capacity transaction fees will drop rapidly.

My opinion:

no one want to use slow and expensive fork, when minority miners realize that "old bct" is useless and give them no profit, they will switch into fork that give them money.

Second trouble: "replay protection"

Old fork

changed its transaction structure, this way coins moved by transaction in one fork are still in place in other fork. This way here was no need to change anything on BTC side - ABC transactions and blocks are incompatible. Therefore whatever is send in ABC fork it stays in ABC fork, what is done in BTC - it works only in BTC. Side effect of this behavior is "you have more BTC" thing - every one that have BTC before fork also have same amount of ABC coins. This is second thing that keeps ABC fork alive - free coins.

In btc1 fork

there is no such "protection". Every transaction will be correct in both chains. It will change, when we use coins mined in fork - coins mined in one fork can not be sent in another fork, because they not exist in it. Then if we use in one transaction coins mined after fork and coins we have before it, that transaction will be valid only in fork that mined new coins. From other fork point of view coins are still on address, sending transaction not happen. It is same situation that we encounter when ETH/ETC fork happens - everyone that had coins before fork also had coins in both forks.

My opinion:

using both forks will be hard at start, because no replay protection. People can "lost coins" because they will send them in both chains at same time. There will be probably "splitting services" connected to mines. In time (if "old BTC" still be in use) problem will resolve itself.

Summary

I hope, that miners wont accept FUD spread by part of Core team, that is opposing any hardfork. The only reason that we have SegWit is that SegWit2x code was used. And part of SegWit2x is raising block size. Dispute about raising block size is over 2yr old. Everyone accept fact, that 1MB is not enough. Everyone, except few people that have access to bitcoin/bitcoin repository. Hopefully, when "old BTC" became dead (or dying) chain they will accept fact, that people and miners are supporting bit different vision of future of Bitcoin. Then merge btc1 changes and move on. It is really simple.

Did I miss something? Need/want mooar? Just reply below :)