Date: Thu, 14 Jan 2021 15:32:57 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Matt Corallo <lf-lists@mattcorallo.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20210114053257.4ctg3qdvo7s44s72@erisian.com.au>
References: <CAFp6fsE6gb2PaL3ikDRjS-hNnPLjvtWB+8qZJr3trQe2K9YN+g@mail.gmail.com>
 <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)
Subject: Re: [bitcoin-dev] Proposal for new "disabletx" p2p message
Precedence: list

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