During the recent 2-block reorg at 941880 I noticed while inspecting the log files of a node that was stalled for 10 minutes (link 
big file) that one of it’s peers was sending blockfilter requests for the blocks this node was stalled from receiving:
[net] peer requested invalid block hash: 95b0d0f836f18d78dfbae435fb37bf6fff2e37a4fc01c20be8495bc3ea4fbb58, disconnecting peer=8502032, [...]
A node with a similar version message then proceeds to continually reconnect after being disconnected and asking for more forbidden filters :).
Note, this behavior on the part of the requesting client is a violation of BIP-0157 which states:
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
headersorinvmessage with that block or any descendents. A node that receivesgetcfheaderswith an unknown StopHash SHOULD NOT respond.
But it seems some BIP157 light clients are not complying, and I’m curious to learn what clients out there are getting disconnected for this reason, could anyone that has debug=net logging enabled share the results of the following awk script which prints the associated version strings of compact blocks peers that violate this rule:
awk -F'peer=' '
BEGIN {
print "| peer | version | blockhash |";
print "|------|---------|-----------|";
}
# 2026-03-23T15:23:40.335605Z [msghand] [../../src/net_processing.cpp:3691] [ProcessMessage] [net] receive version message: /btcwire:0.5.0/neutrino:0.12.0-beta/: [etc...], peer=8502032, [etc...]
/receive version message/ {
v=$1;
sub(/.*receive version message: /, "", v);
sub(/: .*/, "", v);
sub(/: .*/, "", v);
p=$2;
sub(/,.*/, "", p);
ver[p]=v;
}
# 2026-03-23T15:23:52.623454Z [msghand] [../../src/net_processing.cpp:3281] [PrepareBlockFilterRequest] [net] peer requested invalid block hash: 95b0d0f836f18d78dfbae435fb37bf6fff2e37a4fc01c20be8495bc3ea4fbb58, disconnecting peer=8502032, [...]
/invalid block hash/ {
h=$1;
sub(/.*invalid block hash: /, "", h);
sub(/,.*/, "", h);
p=$2;
sub(/,.*/, "", p);
print "| "p" | "ver[p]" | "h" |";
}
' debug.log
One-line form:
awk -F'peer=' 'BEGIN{print "| Peer | Block Hash | Version |";print "|------|------------|---------|";}/receive version message/{v=$1;sub(/.*receive version message: /, "", v);sub(/: .*/, "", v);sub(/: .*/, "", v);p=$2;sub(/,.*/, "", p);ver[p]=v;}/invalid block hash/{h=$1;sub(/.*invalid block hash: /, "", h);sub(/,.*/, "", h);p=$2;sub(/,.*/, "", p);print "| "p" | "h" | "ver[p]" |";}' debug.log
This bitcoin core issue is also relevant: bitcoin/bitcoin#29655
All of the nodes on the log sample I analyzed had the same version string: /btcwire:0.5.0/neutrino:0.12.0-beta/
| peer | version | blockhash |
|---|---|---|
| 8531836 | /btcwire:0.5.0/neutrino:0.12.0-beta/ | 00000000000000000000bd4930a5982911e7749eb491886206e71abdc1ec0cc6 |
| 8532044 | /btcwire:0.5.0/neutrino:0.12.0-beta/ | 00000000000000000000bd4930a5982911e7749eb491886206e71abdc1ec0cc6 |
| 8532234 | /btcwire:0.5.0/neutrino:0.12.0-beta/ | 0000000000000000000085ebdcd669c404195dbfeccbee902fc646dadc367a20 |
| 8532026 | /btcwire:0.5.0/neutrino:0.12.0-beta/ | 0000000000000000000085ebdcd669c404195dbfeccbee902fc646dadc367a20 |
| 8541062 | /btcwire:0.5.0/neutrino:0.12.0-beta/ | 95b0d0f836f18d78dfbae435fb37bf6fff2e37a4fc01c20be8495bc3ea4fbb58 |
| 8539079 | /btcwire:0.5.0/neutrino:0.12.0-beta/ | 00000000000000000001f8562235e11fc74d5eea589e4c37b671b4213e89f52f |