Quote from: ABCbits on Today at 08:46:38 AM

...

Some sort of decentralization (redundancy and/or regional) was also something I had in mind. Sounds plausible to me.

Quote from: Knight Hider on Today at 09:07:38 AM

...

I know that block 912721 was in both UpdateTip events the same, clearly visible by the same hash. I was just surprised why it would need a second UpdateTip when this block 912721 wasn't realy affected by the fork of block 912722. It was block 912723 which decided what branch of the former tip of 912722 should be followed as the "true" blockchain (most accumulated hash work).

Quote from: BattleDog on Today at 11:17:29 AM

...

Thanks for the more in-depth explanations. I had only vague and more incomplete thoughts what probably was going on. With the immense hash power of those pools, many many devices are crunching hashes, timely coordination becomes a real problem and the competitive mining space doesn't make it easier.

I assume it's not trivial to manage such a large amount of mining gear and participating miners. As you say, I can follow that occasional race conditions happen. Trying to cope and avoid them completely likely has more or other disadvantages than letting them happen.

I didn't expect that my node see most or a lot of the forks. It totally depends on my node's peers and I didn't specifically tune it to be any optimized for such a task. RPC getchaintips gives me a list of branch forks where block 723102 is the first in my list and remarkable entries are the invalid blocks 783426, 784121 and 809478.