Of course, if a persistent repeated sequence of such blocks were to be somehow mined back-to-back, that might slow transaction processing to a crawl*.
That is, if no other miner bothered to mine a competing block. Which, of course, is what a rational miner would do in such a situation. For then he would reap the rewards of a more-quickly validating block. (That would be the coinbase reward for solving a block).
The 'excessivity' solves itself. Through natural incentive of rational self-interest.
You keep talking about miners mining this more quickly validating block... there is no code currently that can try to validate two different blocks concurrently and pick the one that validates faster. The first one that comes in will be under validation while any other blocks come in wait before they can be validated so unless someone has a rewrite that does what you claim, the problem still exists. First block that hits will always win.
No disrespect intended. But should excessively-long-to-validate blocks ever become significant, mining using an implementation that does not perform parallel validation is a guaranteed route to bankruptcy.
"no code" - you sound pretty sure of yourself there. It may even be the case ... right up until the point in time that it is not.
Right, there is no *public* code that I'm aware of, and I do hack on bitcoind for my own purposes, especially the mining components so I'm quite familiar with the code. As for "up until the point in time that it is not", well that's the direction *someone* should take with their code if they wish to not pursue other fixes for sigop scaling issues as a matter of priority then - if they wish to address the main reason core is against an instant block size increase. Also note that header first mining, which most Chinese pools do (AKA SPV/spy mining), and as proposed for BU, will have no idea what is in a block and can never choose the one with less sigops.
For those unwilling to click through:
BUIP033: Parallel Validation
Proposer: Peter Tschipper
Submitted on: 10/22/2016
Summary:
Essentially Parallel Validation is a simple concept. Rather than validating each block within the main processing thread, we instead create a separate thread to do the block validation. If more than one block arrives to be processed then we create yet another thread. There are currently up to 4 parallel block processing threads available making a big block DDOS attack impossible. Furthermore, if any attacker were somehow able to jam all 4 processing threads and another block arrived, then the processing for the largest block would be interrupted allowing the smaller block to proceed, unless the larger block or blocks have most proof of work. So only the most proof of work and smallest blocks will be allowed to finish in such
as case.
If there are multiple blocks processing at the same time, when one of the blocks wins the race to complete, then the other threads of processing are interrupted and the winner will be able to update the UTXO and advance the chain tip. Although the other blocks that were interrupted will still be stored on disk in the event of a re-org.
...