Previously, once a block was in flight, we would ignore compact block announcements from our high-bandwidth peers, even though the block might reconstruct with no additional bandwidth required.
This allows us to optimistically try to reconstruct a compact block from our peers, and if it succeeds with no round-trip, then process the block.
#9325 already does this, and more, doesn’t it? i.e. #9325 will already cause the block to be made if a compact block is received and all txs are present, but in addition, it will request the blocktxns which almost always arrive before the full block requested.
Also, the current logic of requesting a full block, I suspect, will be removed soon as this only happens from peers which cannot provide compact blocks - in a way, these nodes are a hindrance to the network more often than not and I expect a future PR will disable these nodes from being block providers (in much the same way that non-SegWit nodes stop being block providers).
Also, #9325 is incredibly simple - only 2 lines deleted - the only thing missing that I would propose adding is some logic to restrict how many blocktxns it is allowed to request (currently the worst case scenario is that it can request one for every cmpctblock received - which is limited to 3).
1918+ {
1919+ LOCK(cs_main);
1920+ mapBlockSource.emplace(pblock->GetHash(), std::make_pair(pfrom->GetId(), false));
1921+ }
1922+ bool fNewBlock = false;
1923+ ProcessNewBlock(chainparams, pblock, true, &fNewBlock);
fForceProcessing(not non-network nor whitelist peer), might want to note that in the argument description.
