net: cbfilters: Don’t disconnect peers for requesting unknown blocks. #34933

1. 
   davidgumberg commented at 3:28 am on March 27, 2026: contributor

   Some BIP157 light clients are not complying with the following requirement:

   StopHash MUST be known to belong to a block accepted by the receiving peer. This is the case if the peer had previously sent a headers or inv message with that block or any descendents. A node that receives [getcf(ilter|header|checkpt)s]with an unknown StopHash SHOULD NOT respond.

   https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki#getcfilters

   During the recent 2-block reorg I observed on one node’s logs that it disconnected BIP157 peers with the version string /btcwire:0.5.0/neutrino:0.12.0-beta/ for asking for filters from the other side of the block race:

   0[net] peer requested invalid block hash: 95b0d0f836f18d78dfbae435fb37bf6fff2e37a4fc01c20be8495bc3ea4fbb58, disconnecting peer=8502032, [...]
   

   (https://bnoc.xyz/t/raw-data-request-block-filter-peers-being-disconnected-due-to-invalid-block-requests/101)

   The broken implementations should fix themselves, but disconnecting is too harsh of a punishment for this mistake, this PR keeps the log message and returns early without responding when this happens, but doesn’t set fDisconnect=true.

2. net: cbfilters: Don't disconnect peers for requesting unknown blocks. 40219f9242
3. DrahtBot added the label P2P on Mar 27, 2026
4. 
   DrahtBot commented at 3:28 am on March 27, 2026: contributor

   The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

   Reviews

   See the guideline for information on the review process. A summary of reviews will appear here.

5. 
   mzumsande commented at 10:26 am on March 27, 2026: contributor

   #29655 looks related (not a reorg there, but a race in which peers asked for the filter before the node had connected the block). Looks like Neutrino may still not be fully compliant with BIP157?

   I don’t know if not disconnecting the peer is necessarily better though - in some cases it may be preferable if a non-compliant peer gets disconnected (so that they could 1) ask another peer and 2) fix their software)? If we just ignore the request, this may result in them unnecessary waiting for an answer that never comes, plus never noticing that there is a problem on their side.

6. 
   Crypt-iQ commented at 1:18 pm on March 27, 2026: contributor

   I’ve made an issue on their repo if you want to chime in with more details: https://github.com/lightninglabs/neutrino/issues/338.
7. 
   0xB10C commented at 2:55 pm on March 27, 2026: contributor

   I’ve followed @davidgumberg’s request for data on this and posted it in https://bnoc.xyz/t/raw-data-request-block-filter-peers-being-disconnected-due-to-invalid-block-requests/101/2
8. 
   ajtowns commented at 3:28 am on March 28, 2026: contributor

   but disconnecting is too harsh of a punishment for this mistake,

   I don’t see why this is the case? They can still reconnect, and I don’t think they’re marked as discouraged let alone banned or anything?

Contributors
davidgumberg DrahtBot mzumsande Crypt-iQ 0xB10C ajtowns

Labels
P2P