[bitcoin-dev] BIP37: 'getdata' request for filtered blocks is answered with 'merkleblock's even if no filter is set

[Sebastian Falbesoner <sebastian.falbesoner@gmail.com>]

Hi all,

while experimenting with the functional test for BIP37 bloom filters
(/test/functional/p2p_filter.py) I noticed that there is an odd behaviour
diverging from the specification.

According to BIP37, 'getdata' commands with a request for filtered
blocks via type
MSG_FILTERED_BLOCK in the 'inv' submessage are only responded to if a filter is
set:

> The getdata command is extended to allow a new type in the inv submessage. The
> type field can now be MSG_FILTERED_BLOCK (== 3) rather than MSG_BLOCK. If no
> filter has been set on the connection, a request for filtered blocks is
> ignored.  If a filter has been set, a merkleblock message is returned for the
> requested block hash.

(see https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki#Extensions_to_existing_messages)

When no BIP37 is set and we request a filtered block, there should be no
response from the node, but what indeed happens is that we always get a
'merkleblock' message in reply.

The cause of this is that from a code point of view there is always a default
filter set that matches everything, which was introduced with commit
37c6389c5a0ca63ae3573440ecdfe95d28ad8f07. The behaviour first appeared in
release v0.8.4.

Any suggestion on how we should cope with this issue? Even if this wouldn't be a
problem for the clients (Andreas Schildbach already pointed out that it could
be, though, and suggests that the connection should be dropped to clients that
request filtered block if there was no filter set -- see issue-link below), I
want to point out that this leads to a few "dead code"-spots in the code base.
Whenever there is a check if a filter is set, the corresponding else-branch is
never executed.

More details on how to reproduce this issue and where the relevant code parts
are can be found on the corresponding github issue #18483:
https://github.com/bitcoin/bitcoin/issues/18483

Greetings,
Sebastian