But then what happens if a lot of xt miners are also producing blocks to the point that the forked chain had enough halshpower to survive?
That's the point.
You can't REALLY know how much power is in each side BEFORE the fork, only AFTER the fork.
What will happen if we get that 75% of blocks were mined with those bits setted but, in reality, the hashpower is 49.3% and 50.7%. Goodbye Bitcoin.
This fork COULD BE a mess, maybe not, but could be in the scenario that I'm describing. This is REALLY necessary?, it is too much risk mate. We should stay with Bitcoin Core and make a new version of it, not building ANOTHER client to fork the blockchain.
In fact not.
If the network split in half the hashpower over the two branches, the confirmation times double for both.
The transactions would be the same (apart for the new coins mined) on both chains.
The problem would be for the 1MB, because if the mean blocksize was 500KB before the fork, it now would be > 1 MB after. For both.
Larger the mean block size before the fork, worse the effect on the 1MB branch.
Now, one chain would be able to confirm all transactions anyway. The other would not.
Immediately there would be a backlog of transactions in the 1MB branch but not in the 8 MB branch.
This would last about 4 weeks before resetting the difficulty.
I assume, due to uncertainty, exchanges and payment processors would not process any coin not present in both branches.
So you would have miners starving for 2 or more weeks at least or until one brach die out and all are mining on the surviving branch.
The asymmetry would force payment processors and exchanges to rely more and more to the 8 MB branch, because it confirm valid transactions faster.
Not only, they would need to pay less fees for transactions on the fastest and more on the slower (I assume they would be forced, for compatibility, to try to spend the same amount on both).
If a SPAM attack (or "stress test") happened at the time, the 1 MB chain will choke under an enormous backlog and increasing fee to have a transaction confirmed in a short time.
Effectively, an attacker could have a large transaction (to itself) confirmed in the 8MB branch but not in the 1MB branch (use a really small or no fee at all). Then send out a large quantity of transactions on the 1MB branch (they would be invalid in the 8MB branch and dropped immediately) clogging the 1MB nodes and forcing 1MB users to pay more to have their transactions confirmed faster.
This scenario explain the reasons waiting to implement the BIP 101 or any other increase of the blocksize or any WORKING method to increase the transactions volume will end making a stronger case for implementing the BIP 101 or some other increase.
As the mean block size increase approaching 800 KB, payment processors and exchanges will increasingly pressure miners to support a block increase and will reduce their requirements to support the winning branch. They could start pricing the coins from blocks supporting BIP 101 (or whatever) differently than the default blocks.
