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 40A1EC013A for ; Thu, 14 Jan 2021 05:33:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 31AD186A8E for ; Thu, 14 Jan 2021 05:33:08 +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 mwDmMKfkZazx for ; Thu, 14 Jan 2021 05:33:07 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by whitealder.osuosl.org (Postfix) with ESMTPS id 3FF6A86A89 for ; Thu, 14 Jan 2021 05:33:07 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian)) id 1kzvFl-0007yX-9b; Thu, 14 Jan 2021 15:33:03 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Thu, 14 Jan 2021 15:32:57 +1000 Date: Thu, 14 Jan 2021 15:32:57 +1000 From: Anthony Towns To: Matt Corallo , Bitcoin Protocol Discussion Message-ID: <20210114053257.4ctg3qdvo7s44s72@erisian.com.au> References: <10E92E80-75A3-4C45-8CEA-F1EAA2149761@mattcorallo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <10E92E80-75A3-4C45-8CEA-F1EAA2149761@mattcorallo.com> User-Agent: NeoMutt/20170113 (1.7.2) X-Spam-Score-int: -18 X-Spam-Bar: - Subject: Re: [bitcoin-dev] Proposal for new "disabletx" p2p message 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, 14 Jan 2021 05:33:08 -0000 On Wed, Jan 13, 2021 at 01:40:03AM -0500, Matt Corallo via bitcoin-dev wrote: > Out of curiosity, was the interaction between fRelay and bloom disabling ever > specified? ie if you aren’t allowed to enable bloom filters on a connection due > to resource constraints/new limits, is it ever possible to “set” fRelay later? (Maybe I'm missing something, but...) In the current bitcoin implementation, no -- you either set m_tx_relay->fRelayTxes to true via the VERSION message (either explicitly or by not setting fRelay), or you enable it later with FILTERLOAD or FILTERCLEAR, both of which will cause a disconnect if bloom filters aren't supported. Bloom filter support is (optionally?) indicated via a service bit (BIP 111), so you could assume you know whether they're supported as soon as you receive the VERSION line. fRelay is specified in BIP 37 as: | 1 byte || fRelay || bool || If false then broadcast transactions will not be announced until a filter{load,add,clear} command is received. If missing or true, no change in protocol behaviour occurs. BIP 60 defines the field as "relay" and references BIP 37. Don't think it's referenced in any other bips. Cheers, aj