Not sure about the technical details but if an increase in block limit is made by consensus,
like the past 8 years limit X was a known thing.
and pools only made blocks below limit X, thus acceptable to nodes
even now pools know the block limit today is 1mb so pools have set their maximum as being 0.999mb but actually produce blocks below that.
pools can look at the nodes of the network. remove the obvious amazon server ones and other server hosted nodes from a tally and then see what useragent suggestions which the remaining real home-nodes are flagging
if say 94% were randomly set above 2mb. 1% at 2mb and 5% randomly between 1mb and 2mb.
they would make a judgement call that 2mb was the 95% safe limit where orphan risk was manageable.
they would make a judgement call that maybe 3mb was the 75% was okish limit where orphan risk is higher but depending on depth allowance maybe manageable.
next they make blocks from 1.000250 and test the water, see what bugs might fly out (like the 500kb bug of 2013 due to a berkely/leveldb crossover that wasnt peer reviewed properly by core devs)
if 1.000250 block didnt kick up fuss they increment a bit more. 1.000500, and so on and so on..
as the pools get to the random minority of nodes below 2mb they start to push the nodes preference of that minority and see whats possible without causing much if any orphan drama. once it gets to a certain point where the blocks are getting too much resistance or getting to the minority/majority cut off. pools settledown and see if the network of nodes move their preferences up or hold out at a certain limit.
now here is the thing.. this node limit (majority of 2mb) is actually a LOWER limit.. and there is more of a hard limit in the background which would suggest right now that 8mb is ok.. pools wont jump above 8mb (if thats what the nodes have) they would stay below 8mb and aim to stay below the majority of the lower preference limit(2mb) in this example.
...
another way to imagine it is take the old 1mb limit as being the upper limit from 2010-2016 with a preference of say 250k in 2010. that over the 6 years rose to 500k and then to 750k.. and then 0.99mb where by nodes had more control of the preference below 1mb rather than just accepting anyblock under 1mb.EG the leveldb bug could have been overted if nodes had a lower limit to warn pools not to push so fast above 500k if the nodes couldnt handle it or just prefered not to go above that
wouldn't the mining pool operator with the biggest miners and hashrate be able to decide the block size to be mined with his majority consensus alone?
miners with the biggest hash just means their attempt maybe a few seconds more luckier at getting a block than their competitors.
it does not mean someone with 25% might get it in 10 minutes and a second pool with 24% might get it in 20minutes24seconds
a few pools nd up being just sconds apart but not counted or even spotted because someone has already taken the lead.
so if 25% were cut off the time wouldnt drastically change and so the cat and mouse games between the pools could still cause issues unless clear majority of pools and nodes