When a miner is working on a block, it is trying to earn the block subsidy + transaction fees for its proposed block. It will abandon its attempt to find the hash for its proposed block if and only if it is provided with proof that another block spending some of the same transactions has been found. So when a potentially solved block is presented, it needs to validate that block. In the case of a block with excessive sig in a single transaction, this validation process will take an excessive amount of time (indeed, this is the supposed 'nightmare scenario' that makes quadratic hashing such a scary issue). So what is a miner to do? Stop everything, and devote all processing to validating the incoming potentially-solved block? Hell no. A rational miner will spawn off a single thread to validate the potentially-solved block, and devote the rest of its resources to trying to find the solution hash to its proposed block. Anything else would be self-defeating.
As all rational miners would engage in this process, it is likely that some miner will find an alternate block solution while is is still trying to validate the incoming possibly-good but large-sig-containing block solved by the first solving miner. It is free to propagate its solved block to the network at large.
Upon receiving such a block, rational miners will devote (e.g.) one thread to validating the new block - even as they are still trying to validate the first possibly-good but large-sig-containing block. Whichever is the first to be validated is the block which they will propagate and the block that they will build atop. This would be the second-arriving block that does not engender the quadratic hashing issue. The first solution block - containing the large sig transaction - gets orphaned. Problem goes away.
What, me worry?
i get what your thinking. and this has already been solved.. its the empty block concept, people still dont get.
firstly. pool A solves a block hands it out.. lets say pool B receives it.
immediately.
pool B tells the asics. to start working on an empty block. (no tx apart from blockreward claim(coinbase tx))
because poolB does not know what tx's to add into blockB because its yet to validate blockA
what happens is a pool can take upto 2 minutes to validate a block. (as long as its not got a super bloater 1mb tx)
and so before validating a blockA to know what unconfirmed tx's remain in mempool to start adding to pool B's empty block, if blockB 'luckily' gets a solution then Block B looks 'empty'.
obviously if BlockB is not solved after 2 minutes and if all is good with BlockA... poolB starts adding tx's from unconfirmed mempool to blockB and resending a hash to the ASICS to hash away at.
this is why most 'empty' blocks are found within a couple minutes of the previous timestamp. because they are only mpty because they were luckily solved so quick
..
now thats dealt with.
instead of letting 1tx have 20,000sigops, letting it have say 500sigops max. means that we will never ever ever have a risk of it taking 10minutes to solve a block by someone having a 1mb tx.
secondly pools can right now. in their own settings. without needing to get a consensus or an vote or permission. set their pool node to only allow tx's with < xxx sigops. and then those trying to send such clunky tx's will soon realise their tx's are not getting accepted. and will react accordingly (being more leaner with their tx's)
thirdly making leaner tx's also helps more peoples tx get accepted.
EG 2500tx's of 400bytes. instead of 1tx of 1mb
leaving the sigops soo high, even when (lets say segwit activated) quadratics is not an issue. may save processing time.. but still allows a bloater to send a tx of 1mb. so reducing the sigop count of tx's should still be done anyway.
so knowing it should be done anyway. we might aswell just do it. and solve the problem sooner. rather than waiting for segwit to not do a full job
