Block Re-announcement post-compact-fast-announcement after a GETHEADERS or GETBLOCKS request #11522

BIP 152, in the "Pre-Validation Relay and Consistency Considerations" section, point 3, suggests that nodes "SHOULD re-announce" a "block using the associated announcement methods after validation has completed if it is not included in the original response [to a GETHEADERS/GETBLOCKS message]". This is a pretty strange requirement that we currently do not meet (it implies that, if you announce a compact block to a peer using HB mode, and it then requests the header/block inv from you, and you do not supply it as you have not yet finished connecting the block, you need to, once you finish connecting the block, send the header/inv. Because this requirement is not there for GETDATA messages directly (BIP 152 instead requires that the message-processing-pipline stall until you've connected the block), this does not effect our usage of compact blocks, but technically we are not faithfully implementing BIP 152.

Adding a check for this case and handle it explicitly (by watching for GETHEADERS/GETBLOCKS and then setting pindexBestHeaderSent back if we have a most_recent_block which is not included but which has more work than our tip) is doable, but somewhat gross. Personally, I'd prefer that BIP 152 either be changed to drop this SHOULD, or make a note that Bitcoin Core does not meet this SHOULD and implementations SHOULD NOT rely on this behavior.

Actually, I take that back, there is a minor esoteric edge-case here - if we do not have the previous block, receiving a compact-HB-announce will result in a getheaders message to try to get in sync (see https://github.com/bitcoin/bitcoin/blob/master/src/net_processing.cpp#L1980). We will then (possibly) get a response including everything up to, but not including, the new block, but which the peer will not re-announce to us, delaying us from getting the new block from that peer (though unlikely to be an issue as we should receive the announcement from one of our non-CB-HB peers in an announcement that we can handle).

I think the behavior described in the BIP is reasonable, but it seems like a pain to implement. otoh not doing it isn't good either because of the example you gave. Perhaps we should step back a bit and try to imagine what the protocol and synchronization state machines would look like if we wrote it from scratch, then see if that informs us about the direction we should take what we have.

For example, would be have headers responses that included blocks we haven't validated yet but could serve to those who want them?