Issue Details

Number

11522

Title

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

Description

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.

URL

https://github.com/bitcoin/bitcoin/issue/11522

Closed by

Notes

Attention of

Kill Factor (1-10)

Save

Back to List