==> what "orphaning effect" ? Orphaning occurs when OTHER MINERS decide to mine upon ANOTHER block than the orphaned block. If miners decided to mine upon block A, with blocks B, C, D and E, there simply isn't any other set of blocks around that a P2P node could "prefer". Suppose that a majority of P2P nodes decides to "orphan" block B. But the miners have been building blocks C, D and E on top of B. What happens ?
Well, these nodes stop. They stop at block A. And they can't find any other block that pleases them. B wasn't according to their taste. But there's NO OTHER BLOCK around that is built upon A. Nobody has ever made a block on top of A with a higher PoW than the chain B,C,D,E. In fact, nobody ever made a block on top of A.
but then pools see that all the merchants cant see their rewards for BCDE..
the users waiting on transactions cannot see BCDE
and pools have to wait until Z4 before they can even spend B...
so way way way before z4 (z4=going through the alphabet 4times(100 block confirm maturity)) occurs just to spend B.. pools realise they better make blocks according to rule A otherwise they have wasted half a day building b-zb-zb-zb-z that would be unspendable.
this is why instead of having orphans of 100 blocks deep where pools realise they cant spend their funds..
they only at most regularly have orphans of 1 block deep. because:
they know its foolish to keep mining b-z 4times.
they know its foolish to keep mining b-z 4times HOPING the delay would force 6000 nodes to download and waste a week re-syncing to new B rules.
pools only move to B rules if the nodes accept it, which pools find out about alot sooner than 6 hours+ when its time to spend.
pools can usually find out within a few minutes if their block is 'good' for the majority
some pools realise in 3 seconds
2017-01-29 06:59:12 Requesting block 000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5
2017-01-29 06:59:15 ERROR: AcceptBlock: bad-blk-length, size limits failed (code 16)