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.
Concept ACK, good step forward.
#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).
Testing.
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);
This appears to be a novel use of fForceProcessing(not non-network nor whitelist peer), might want to note that in the argument description.
The documentation is just flat out wrong, it seems. fForceProcessing means "make sure to store this to disk, we decided we wanted to request this block for some reason, so probably want it no matter what validation.cpp thinks". Indeed, the use here is slightly different from elsewhere, but given that we already check for blocks which do not mesh with our idea of the best chain further up, and that we will only get here if the block was within two blocks of our tip, I'm pretty confident this is the right use.
utACK 7017298eb2c72e262b865cd417d6844bcdd14a3f
utACK 813ede91e12dd777faee60f6286a9ed5bb72761a
ACK. Appears to be highly effective on mainnet too.
utACK 7017298eb2c72e262b865cd417d6844bcdd14a3f
posthumous utACK
Milestone
0.13.2