In compact block opportunistic reconstruction we have a comment above the MarkBlockAsReceived call:
0 // Clear download state for this block, which is in
1 // process from some other peer. We do this after calling
2 // ProcessNewBlock so that a malleated cmpctblock announcement
3 // can't be used to interfere with block relay.
That’s great and all, but we don’t have anything similar in ::BLOCK handling. Thus, if you have a compact block blocktxn request in-flight from one peer, another peer can send you a malleated block as a regular block message causing the in-flight state to be cleared. That peer will get banned, so its a one-time block propagation slowdown (and shouldn’t even be all that much of a slowdown), but worth noting. Writing it up primarily cause it should be considered in some eventual in-flight-blocks refactoring in conjunction with a #10984 rebase.
