This is all complete nonsense. Are you really suggesting that nodes with differing consensus rules would "re-align" with one another? Why? There is nothing enforcing consensus between 2mb and 1mb nodes.
The picture is silly -- consider another common situation, post-rules activation:
Group C (2MB miners) finds and publishes Blocks 400,000c, 400,001c and 400,002c (all > 1MB) at 12:05-12:15, making it the longest valid chain by 3 blocks for all nodes enforcing 2MB rules. Groups A or B (1MB miners) finds and publishes Block 400,000a at 12:16.
Now, why would nodes enforcing 2MB rules orphan any of Blocks 400,000c-400,002c? They are valid blocks built on the longest valid chain by timestamp. Block 400,000a was found well after Block 400,000c. There is no reason for 2MB nodes to "re-align" with Groups A or B. To 2MB nodes, Block 400,000a is a stale block and nothing more. 2MB nodes will continue to recognize blocks built on top of 400,002c as valid.
Meanwhile, Blocks 400,000c-400,002c break the consensus rules enforced by 1MB nodes. So for them, the next valid block on the longest valid chain is 400,000a. 1MB nodes will continue to recognize blocks built on top of 400,000a as valid.
When you break consensus, there is no incentive for nodes with different rules to "re-align" their blockchains. Miners running one set of rules or the other will continue to build on the longest valid chain. If a different chain is the longest but is built on top of invalid blocks, they cannot be re-aligned. Miners running incompatible software will continue to mine on top of separate chains, and so on, and so forth.
Having the 2mb setting "as a buffer" does nothing to avoid orphans or headaches; it could help to trigger a hard fork that results in multiple blockchains built on top of differing consensus rules.
maybe worth you looking how orphans work
then realise that 2mb miners can accept blocks below 1mb aswell..its a 0 to 2000000... not a 1000001 to 2000000 rule
so at the 400,002 where the <1mb block gets a block solved first.. the 1mb block wins because it solved a block first (wins the block height race)
(i wrote it twice for emphasis)
and when it sees the chain of previous blocks of that winning block.. they do not contain any over1mb blocks.. so then that causes C to orphan the chain to realign..
please learn about orphans
Please don't tell people to learn how things work when nearly everything you've said is factually incorrect.
Sure, 2MB nodes can accept blocks smaller than 1MB. So what? That a 900kb block found 3 blocks later is valid doesn't mean nodes will orphan the 3 valid blocks that came before it based on block height.
Why would the 1MB block (according to 2MB nodes) win the block height race? Group C mined Blocks 400,000-400,002 before Group A mined Block 400,000. 2MB nodes recognize Blocks 400,000-400,002 as valid. Why would they possibly orphan them? Because some other software version disagrees? LOL.
Group C won't orphan any blocks because they have built on the longest valid chain, according to their 2MB rules and according to block height. And that's how a chain fork occurs.
in your scenario, miners A and B will ignore and instantly reject 400,000c as it doesnt fit the rules.. miners A and B do not stale their attempts, but instead continue to mine their own blocks until they reach a solution that fits them. which is the timestamps
400,000a at 12:05:05
400,001b at 12:15:15
400,001a at 12:25:15
please learn orphans and stales and how they work and choose when to give up and when to keep trying.
oh and by the way the more transactions you add to a block, the more processing time it takes. so hash for hash.. the chances of a miner with 2mb rule hitting first is reduced just because of processing time. so the chances of 1mb rules hitting first is more.
Yes, 1MB nodes (Groups A and B) will instantly reject 400,000c. That doesn't magically mean that Groups A and B instantly find blocks as fast as Group C. The premise is simple -- if Group C finds 3 blocks (or even 2 blocks) before Groups A and B find 1 block, what happens?
And throwing latency time into the mix as you are is completely ridiculous. You're merely arguing that since something very slightly reduces the chances of a chain fork (and miners generally mitigate this reduction by SPV mining), that it is therefore safe? Are you kidding?
even in a case where miner C makes 20 blocks in a row first. and the other 1mb miners ignore that and mine there own. second later height for height.
when that minority miner does get blockheight win... then the C miners 20 blocks get orphaned. because C miner still treats <1mb blocks as valid because the rule is 0 to 2000000.. not 1000001 to 2000000
Why does it matter that <1mb blocks are valid? That doesn't make all the blocks Group C mined before invalid. Explain to me: Why would Group C (and 2MB nodes) orphan all blocks found by Group C? They are building on the longest valid chain. Their blocks are valid according to consensus rules and earliest based on block height. Why would they be orphaned? It doesn't matter if another "valid" block was found later by Group A -- that's just a stale block.