Re: [bitcoin-dev] Proposal for new "disabletx" p2p message

[Matt Corallo <lf-lists@mattcorallo.com>]

So we’d kill two birds with one stone if all bloom support was dropped. As far as I understand, precomputed filters are now provided via p2p connections as well.

Matt

> On Jan 14, 2021, at 00:33, Anthony Towns <aj@erisian.com.au> wrote:
> 
> 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
>