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 <[email protected]> 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 > _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
