From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 497F2C07FF for ; 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 ; 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 ; 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 ; Thu, 2 Apr 2020 15:26:55 +0000 (UTC) Received: by mail-ot1-f48.google.com with SMTP id f52so3793923otf.8 for ; 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 Date: Thu, 2 Apr 2020 17:26:40 +0200 Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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