Published on: 2019-08-14T15:07:19+00:00
In a recent announcement on the bitcoin-dev mailing list, it was revealed that bloom filter serving will be turned off by default in the next Bitcoin Core release. This decision comes as bloom filter serving has been a known DoS vector for some time and closing this vulnerability is seen as low-hanging fruit. While some users have expressed concerns about the impact on SPV implementations and centralization, it is expected that there will still be a sufficient number of NODE_BLOOM-enabled nodes available. Clients relying on NODE_BLOOM-supporting nodes are encouraged to consider migrating to alternative options in the coming years.Another discussion on the mailing list focused on the BIP158 compact block filter implemented in Bitcoin Core 0.19. Concerns were raised about address re-use and how the server determines the filter and false positive rate. It was suggested that the hardcoded filter may lead to wallets with many addresses having to wrap their key chains back to the beginning. However, it was clarified that wallets only need to match outstanding addresses that haven't been paid, rather than every single address used. This provides clarity on the potential issue of address re-use and its impact on wallet functionality.The conversation also touched upon the use of NODE_BLOOM peers and BIP 37 wallets. The change in defaults to serve BIP 37 peers does not imply the removal of the code for those who still wish to use it. Historical upgrade cycles suggest that many nodes will continue to serve NODE_BLOOM for years. However, there is an argument that BIP 158 offers better privacy and DoS protection, although it may result in increased traffic. The discussion emphasizes the importance of developers being transparent about the implications of different filtering options and providing users with choices based on their needs.In regards to BIP 157/158, it was noted that these are not alternatives to BIP 37 but rather complementary to it. Both can be used by wallets to save deterministic GCS filters, allowing offline re-scanning if necessary. While BIP 158 may cause more traffic, it provides the ability to filter blocks without relying on serving peers that could compromise financial privacy.The discussions also touched upon other topics such as the Rust implementation of BIP 158 and the potential use of DNS seed infrastructure to direct wallets to specific nodes. The ongoing debates within the Bitcoin community regarding security, scalability, and decentralization were also highlighted.In conclusion, the recent discussions on the bitcoin-dev mailing list have shed light on various aspects of Bitcoin Core, including the decision to turn off bloom filter serving by default, concerns about the BIP 158 compact block filter, and debates surrounding the use of NODE_BLOOM peers and BIP 37 wallets. Developers are encouraged to be transparent about the implications of different filtering options and provide users with choices based on their needs for privacy and bandwidth availability.The Bitcoin-dev mailing list recently discussed the potential removal of the NODE_BLOOM feature from the Bitcoin network. Developers expressed concern about the impact on over 10 million wallets that rely on this feature for updates. While alternatives like Electrum's JSON-based protocol and Stratum have been suggested, there is a consensus that BIP37 (public server-based tx filtering) was a conceptual mistake and should not be extended. The Neutrino protocol was also deemed controversial and less trustworthy. Matt Corallo raised concerns about privacy-violating alternatives to Bitcoin and pointed out that mitigations for these issues have been presented in a paper that requires further exploration.Andreas Schildbach argued against disabling the NODE_BLOOM feature, citing its importance to millions of wallets and the lack of a suitable alternative. He highlighted the potential risk of denial-of-service attacks but clarified that the myth surrounding them has been debunked. Andreas recommended improving the current filtering for segwit and urged developers to postpone the removal until a viable alternative exists. It was noted that NODE_BLOOM was added in Core 0.12 and BIP111 in 2015, indicating that this change was anticipated by most developers.The discussion also touched on the bandwidth usage of Compact Filters (CFB) compared to bloom filters, raising concerns about accessibility in impoverished countries where data rates are expensive. The plan is for such users to rely on custodial services, but questions were raised about the exact increase in bandwidth required by CFB. The conventional wisdom regarding CFB as privacy-violating was established by a paper that proposed mitigations but received little exploration. Despite these concerns, there has been a push towards custodial solutions, including custodial Lightning Network and L-BTC altcoin.Overall, the debate revolves around the potential impact on network security, privacy, and trust in Bitcoin. Developers are examining alternatives and calling for careful consideration before implementing any changes.
Updated on: 2023-08-02T01:07:45.944093+00:00