📅 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
>
Matt Corallo [ARCHIVE] /
npub1e4…jxmcu
2023-06-07 18:28:10
in reply to nevent1q…xj8e
Author Public Key
npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuPublished at
2023-06-07 18:28:10Event JSON
{
"id": "75d2a7cddcce4102aa83cfd636fca46dbe2cc8736bcd848ff83936b900c7f241",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686162490,
"kind": 1,
"tags": [
[
"e",
"842200f2a94332c7e94662e315d234fceeefa9b88dd12cef0790ef063659ea38",
"",
"root"
],
[
"e",
"06bf74c5e074ade043ae55e6147c0c776fe4615e19201cbbcdc0e5c9b05d5e92",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "📅 Original date posted:2021-01-14\n📝 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.\n\nMatt\n\n\u003e On Jan 14, 2021, at 00:33, Anthony Towns \u003caj at erisian.com.au\u003e wrote:\n\u003e \n\u003e On Wed, Jan 13, 2021 at 01:40:03AM -0500, Matt Corallo via bitcoin-dev wrote:\n\u003e\u003e Out of curiosity, was the interaction between fRelay and bloom disabling ever\n\u003e\u003e specified? ie if you aren’t allowed to enable bloom filters on a connection due\n\u003e\u003e to resource constraints/new limits, is it ever possible to “set” fRelay later?\n\u003e \n\u003e (Maybe I'm missing something, but...)\n\u003e \n\u003e In the current bitcoin implementation, no -- you either set\n\u003e m_tx_relay-\u003efRelayTxes to true via the VERSION message (either explicitly\n\u003e or by not setting fRelay), or you enable it later with FILTERLOAD or\n\u003e FILTERCLEAR, both of which will cause a disconnect if bloom filters\n\u003e aren't supported. Bloom filter support is (optionally?) indicated via\n\u003e a service bit (BIP 111), so you could assume you know whether they're\n\u003e supported as soon as you receive the VERSION line.\n\u003e \n\u003e fRelay is specified in BIP 37 as:\n\u003e \n\u003e | 1 byte || fRelay || bool || If false then broadcast transactions will\n\u003e not be announced until a filter{load,add,clear} command is received. If\n\u003e missing or true, no change in protocol behaviour occurs.\n\u003e \n\u003e BIP 60 defines the field as \"relay\" and references BIP 37. Don't think\n\u003e it's referenced in any other bips.\n\u003e \n\u003e Cheers,\n\u003e aj\n\u003e",
"sig": "4ae5d2e08b60d57dfe12dfeae50e5af8c37048a66291baa2c8cea9e1967ab9dd7752e886954a61c4fdf0f6918590d3dc45df9b419333ef30b5e156f1f3f85d2a"
}