From: Sebastian Falbesoner <sebastian.falbesoner@gmail•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] BIP37: 'getdata' request for filtered blocks is answered with 'merkleblock's even if no filter is set
Date: Thu, 2 Apr 2020 17:26:40 +0200 [thread overview]
Message-ID: <CACi0ghtvniaA4sVty4ZuYk84F1PG-O4QvixS3sbp_RidB0K2dQ@mail.gmail.com> (raw)
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
reply other threads:[~2020-04-02 15:26 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACi0ghtvniaA4sVty4ZuYk84F1PG-O4QvixS3sbp_RidB0K2dQ@mail.gmail.com \
--to=sebastian.falbesoner@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox