Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2021-01-14 📝 Original message:So we’d kill two birds ...
📅 Original date posted:2021-01-14
📝 Original message: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 at 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
>
📝 Original message: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 at 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
>