pools which manage multiple coin use different servers per coin. thus upgrades of one coin dont affect/delay other coin upgrades. (different men in different office.. not banging heads together)
A merged mined (mm) coin requires supporting that in the coinbase of the Bitcoin work sent to the miners.
Thus the Bitcoin work generation requires code changes when supporting any scamcoin or when the scamcoin changes anything related to that.
Each Bitcoin work generation also requires access to the scamcoin so that the mm information in the coinbase is accurate.
Most pools do this (look for a larger coinbase sig with the letters 'mm' in it)
If instead you are talking about a scamcoin being directly mined on a pool, well that's off topic here anyway
miners(asics) dont send every attempt back to a pool. an asic is provided with hash, nonce range and difficulty target. if they run out of nonce range allocated to them. they just request another nonce range
they wont send a hash back unless it meets the threshold
The miner is in 2 parts:
1) the asic processing the work the miner software sends to it
2) the miner software talking to the pool or bitcoind and talking to the asic
Using stratum, as every Bitcoin mining pool does, they wont exhaust the nonce range, the mining software can generate an exceptionally large amount of work from a single stratum work item sent to it by the pool.
The limit is only ever possible to approach when using a poorly configured proxy, sitting between the pool and a very large number of miners.
anyways
(although most tx are prevalidated during tx relay prior. some blocks include new tx not pre relayed thus requiring nodes to request the tx during the block checks.. its actually this tx request delay that extends block validation delay alot of the time(exploitable))
It's very rare to have delays with a block change, unless you're bitcoin network management is not at the level of a well setup pool
i.e. you may have this issue if you are a typical home user doing home solo mining or using a poorly configured pool
It also makes no sense for a large pool to hold transactions until they submit their block.
This will mean that they are competing against the whole bitcoin network accepting their new block, vs everyone on the network trying to find the previous block as a replacement for their block, during the delay this causes.
Of course the coinbase transaction does not fall under this, since it must be transferred with the block header (and thus the smaller it is the better)
when a blockX is propagated headers first.
the <2min timespan of propagation, analysis difficulty of solved hash, see tx list, see which tx are missing. fetch missing tx, valid fetched tx.. sha the block, make sure it matches the hashs announced earlier.confirm a block.
This time frame is milliseconds, not even seconds.
If you are taking seconds to do this, you can expect a
much higher chance of lost blocks due to either:
1) being stale - no one else on the network will accept it and the only way to not lose the block would be for you to get a fast 2nd block on top of your own
2) orphaned and likely to lose the orphan race due to not getting your block out to the majority of the network, if you were only a few hundred milliseconds behind someone else, not seconds
This incorrect assumption means you need to redo your 3 options.
*(block template takes a few seconds to collate new unspent list, to hash it,send hash to asics with nonce range)
Only milliseconds.
3. ([intent or ignorant] build on first propagated blockX no matter what)
this is where a pool sees the header and just builds on it no matter the content validity
The majority of large pools do this - they build on the header without verifying the merkleroot - which means without verifying the transactions.
It would seem that over the last few years they finally realised they could speed this up a little by sending their miners new work
as soon as they had verified the transactions.
Thus the time they are working on a possible invalid block has reduced.
But alas, this is still the large majority of the bitcoin network.
Fibre network/ merchants
Alas the public fibre network is no longer in existence for quite a while.
Any pool or solo miner needs their bitcoin connected directly to, or at most 1 step away from, the large pools.
Each step will slow down the propagation of any blocks you find.
If you want to compete in the Bitcoin world on your own, you need a network configuration able to compete with the large pools.