diff options
| author | Sebastian Falbesoner <sebastian.falbesoner@gmail.com> | 2020-04-02 17:26:40 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2020-04-02 15:26:56 +0000 |
| commit | 6983b9b97eabc87bb67394c160359160bbb6dc23 (patch) | |
| tree | 7493c56f64964d4ad0565321c7dda73400a9b71f /92/b28d2c0f88eebb1be72e2fb14bb3a687af2073 | |
| parent | fd750532c7520f1bffb50af31dd30ad1734b4b4b (diff) | |
| download | pi-bitcoindev-6983b9b97eabc87bb67394c160359160bbb6dc23.tar.gz pi-bitcoindev-6983b9b97eabc87bb67394c160359160bbb6dc23.zip | |
[bitcoin-dev] BIP37: 'getdata' request for filtered blocks is answered with 'merkleblock's even if no filter is set
Diffstat (limited to '92/b28d2c0f88eebb1be72e2fb14bb3a687af2073')
| -rw-r--r-- | 92/b28d2c0f88eebb1be72e2fb14bb3a687af2073 | 114 |
1 files changed, 114 insertions, 0 deletions
diff --git a/92/b28d2c0f88eebb1be72e2fb14bb3a687af2073 b/92/b28d2c0f88eebb1be72e2fb14bb3a687af2073 new file mode 100644 index 000000000..778abc975 --- /dev/null +++ b/92/b28d2c0f88eebb1be72e2fb14bb3a687af2073 @@ -0,0 +1,114 @@ +Return-Path: <sebastian.falbesoner@gmail.com> +Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 497F2C07FF + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 2 Apr 2020 15:26:56 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by whitealder.osuosl.org (Postfix) with ESMTP id 38D0C88116 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 2 Apr 2020 15:26:56 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +Received: from whitealder.osuosl.org ([127.0.0.1]) + by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id p+pKcqryjyVN + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 2 Apr 2020 15:26:55 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from mail-ot1-f48.google.com (mail-ot1-f48.google.com + [209.85.210.48]) + by whitealder.osuosl.org (Postfix) with ESMTPS id 7B3C288072 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 2 Apr 2020 15:26:55 +0000 (UTC) +Received: by mail-ot1-f48.google.com with SMTP id f52so3793923otf.8 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 02 Apr 2020 08:26:55 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=mime-version:from:date:message-id:subject:to; + bh=m1z2Z7O8wJFgoQq3q+4Ywy869ZdSXLgeAyPS8MAl5Zo=; + b=h2t1RtPb7L7vwYC53vn62w0uFrqnuO5Cf2X3VcdhYadEV3JOtt38v29CqHxbSltTCW + UAM10NVLHRL75zB2+MWOQgMcW8X7eZrDIkjoL+5PUkSdh61wX8qZ1YbBgZTRQx8Vgc3a + foReGXWmAp0GHxNDCEhU3YeuYpagntOqUUctztKXR2+30KsZvU8ljIIqnduzJM4kYUQC + FMb9XGaQeyjVdeWa4b2lWwiko9h7J8c5wXmc94jjOqCSvXi4T/mMO00prvFQnhusc36b + zS8NvbON7Mcux5MHmve2QEhIQ7uMaGVEOKpftIv+9a8Ku1XgJib8gUpXIY9ay3Yqu/oN + qNgQ== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:from:date:message-id:subject:to; + bh=m1z2Z7O8wJFgoQq3q+4Ywy869ZdSXLgeAyPS8MAl5Zo=; + b=OCYEZK//DmJBH0v6pkXzmqY3oqmvRhuMRUc72b/nCfPaDWSzQmidWC+djmNyzJB75x + JgrW+fi8jxW2vANW8GitPpzd+YEZ7qjsc9Q7k6zZrs/Y8+cwu5ezPfTDKa0jj51/bm39 + EIZuc2mfLbL7dlqhKxYYSxKHUYQGtWi/912f1gDXeroFtYfDibShVYs8luGjkWVrrCh9 + 1MCKUkO5qob3YidAl/QoVD9wsL71fYWt8MnH39ld6uSwsU2WmK/+7R829Vh0tA/yyPUV + hENH9/sZrbIP/zRisBsR613VbxvJM9vP/CNETwZ8LM/ElB6nw5OY5Jyhr1Bhw1RiH6HV + 5bzQ== +X-Gm-Message-State: AGi0PuahYtp1drxat5jwfw+DmCAImHyxmiEvgFain4HEfHMKEKghjgzR + bu5nC1L2qzKemuoRAhZ9mxkXfI3vfL/tTUPqvFDnndBtEQ== +X-Google-Smtp-Source: APiQypIIHxwraEQF36UM/fpirjDa0It4Yd4wvqEt7zidqQuw/ULdltmyVQV+/WSh7BFDgCeAktIe6zABk67PHzN8FEE= +X-Received: by 2002:a05:6830:1d95:: with SMTP id + y21mr2929929oti.180.1585841213487; + Thu, 02 Apr 2020 08:26:53 -0700 (PDT) +MIME-Version: 1.0 +From: Sebastian Falbesoner <sebastian.falbesoner@gmail.com> +Date: Thu, 2 Apr 2020 17:26:40 +0200 +Message-ID: <CACi0ghtvniaA4sVty4ZuYk84F1PG-O4QvixS3sbp_RidB0K2dQ@mail.gmail.com> +To: bitcoin-dev@lists.linuxfoundation.org +Content-Type: text/plain; charset="UTF-8" +X-Mailman-Approved-At: Thu, 02 Apr 2020 15:27:27 +0000 +Subject: [bitcoin-dev] BIP37: 'getdata' request for filtered blocks is + answered with 'merkleblock's even if no filter is set +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Thu, 02 Apr 2020 15:26:56 -0000 + +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 + |