Published on: 2023-05-01T13:24:26+00:00
In response to a query about the BIP35 P2P `mempool` message, it has been revealed that Bitcoin Core only gates processing of mempool messages on NetPermissionFlags::Mempool when bloom filters are disabled. Despite being disabled by default, over 20% of nodes on the network have bloom filters enabled and respond to mempool messages with INV messages. An individual has reportedly been receiving around 20 mempool messages per hour to a well-connected NODE_BLOOM Bitcoin Core node from various user agents such as /BitcoinKit:0.1.0/, /bitcoinj:0.*. */Bitcoin Wallet:*/, /WalletKit:0.1.0/, and /bread:2.1/. Moreover, the node responds to clients with INVs up to the maximum number of 50k entries and with smaller (bloom) filtered INVs.The conversation can be traced on a GitHub pull request comment [0] and the public key and signature of the commenter are also available as attachments. The `savemempool` RPC can be used to load the mempool directly into a client for trusted users. In the past, lightweight clients loaded a BIP37 filter and requested `mempool` using `getdata`. The node would then only send transactions matching the filter and false positives to the client. This approach reduced the amount of data transferred, which is crucial for lite clients with limited bandwidth or metered connections.During a backlog, the mempool contents in the `savemempool` format are about 300 MB, which is too much to transfer to lite clients. Although BIP37 and BIP35 interfaces are problematic, it's essential to build interfaces that enable people to use third-party wallets with their trusted nodes easily. It's possible to use `getheaders`, BIP157/8, and `getdata(block)` with their nodes to learn about all confirmed transactions affecting their wallet. Lite clients using a trusted node should receive a replacement for BIP35/7 support before those protocols are removed. Support for BIP324 and countersign should also be added to allow an authenticated and encrypted connection from a lite client to a trusted node. An authenticated connection is necessary to be secure, and it should ideally be encrypted.The author proposes the removal of BIP35 P2P `mempool` message, which is considered bad for privacy and relatively inefficient for trusted peers. The original intention of the message was to be publicly callable, but it is now gated behind stricter Net Permissions accessible to trusted peers only. An alternative for serving trusted clients could be using the `savemempool` RPC, although it currently has some shortcomings. Dumping and loading a dumped mempool to sync two trusted nodes or bootstrap one node makes more sense via RPC, but there is an argument to be made that syncing via P2P message would be more convenient.The author has a draft PR open for the removal of the mempool message, and before moving forward, they want to ensure that there are no active use cases or technical opposition to its removal. The author requests input on whether there are any parties who still directly rely on the BIP35 P2P `mempool` message and whether there will be any issues or negative consequences resulting from its removal. A quick search of node implementations shows that `btcd`, `libbitcoin`, and `BitcoinJ` all have BIP35 messages specified, but it's difficult to gauge upstream usage by other projects without outreach like this. The removal of the message would provide a small clean-up to the P2P codebase and bring the usual benefits in terms of maintainability.
Updated on: 2023-08-02T09:16:00.932771+00:00