Bitcoin Core to disable Bloom-based Filtering by default

Summary:

In this context, Andreas is discussing the denial of service (DoS) vectors in NODE_BLOOM, which are not a myth. He argues that while an attacker can cause useless traffic by setting an overly blurry filter, it never exceeds just drinking from the full firehose. However, the concern is about asking a peer for extensive CPU and disk work, which NODE_BLOOM peers provide for free but is not directly beneficial for the Bitcoin Network. Andreas anticipates that this change will reduce the number of nodes usable by a large enough amount so that the feature will become unstable.He further speculates that in the long run, we cannot expect nodes to provide disk/CPU intense services for free to clients not contributing back to the network. He recommends that clients relying on the availability of NODE_BLOOM-supporting nodes on the P2P network should consider the process of migrating to a more modern alternative over the coming years. However, he notes that there is no such alternative yet, and he strongly recommends postponing this change until an alternative exists and then giving developers enough time to implement, test, and roll out.Andreas suggests that as long as there is no alternative, we should improve the current filtering for segwit. The consensus among protocol developers is that BIP37 (public server-based tx filtering) was a conceptual mistake, and extending it further may be the wrong step, especially when promising alternatives like BIP158 (neutrino) are around. Finally, he emphasizes that NODE_BLOOM was added in Core 0.12, and BIP111 is from 2015, indicating that defaulting NODE_BLOOM to off was something anticipated by most developers. Possible alternatives include BIP158 (though BIP157 is not widely available on the network yet), and client-side filtering works also by collecting the filter form a centralized service by the wallet provider(s) or a CDN.

Updated on: 2023-06-13T20:15:00.582842+00:00