Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8ED2DC002A for ; Tue, 18 Apr 2023 06:47:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 6EE82415E5 for ; Tue, 18 Apr 2023 06:47:53 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 6EE82415E5 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=256k1.dev header.i=@256k1.dev header.a=rsa-sha256 header.s=MBO0001 header.b=vvE4xg7V X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1AdfUn9IVYZ for ; Tue, 18 Apr 2023 06:47:52 +0000 (UTC) X-Greylist: delayed 00:09:59 by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 19A40415E2 Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [80.241.56.171]) by smtp4.osuosl.org (Postfix) with ESMTPS id 19A40415E2 for ; Tue, 18 Apr 2023 06:47:51 +0000 (UTC) Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:b231:465::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4Q0vP90WNYz9sRC for ; Tue, 18 Apr 2023 08:37:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=256k1.dev; s=MBO0001; t=1681799869; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=tRk1fZRq2E4hoAorCey7hvYcEPnh8HkAVeOgl9PPhic=; b=vvE4xg7V32wXx3hPqOC6JkZ2yOpoKtnCPFqcEQNtE/iQ8NkIfE5F3kTSJFv277GzxkBPk1 jYgydifF5GNNLK4HYKlSbJcAzPYx0UpDzh3HohGV9spynF+8w6xDyd1HxfuOsmXjJ7tfF7 M7WofY/Vjx6IPsuVfpEdCyS6eXbMNjVtfQtqWT0gRQ4cTtOMcIFFv58EAx4es3cIQmbCol N0D8E+IvpD+bauwx1OUpeuobNbs+d3q2TJdCbctKkZ5tOgkxQpQ727x7PiDS5EF2ONwg/k Zz5FpZ/v7jzQtKj3MohVGj9L3r5FkAAAjJC8Nx8J4v7aIZmucwyas6qKIUtSXA== Date: Tue, 18 Apr 2023 06:37:45 +0000 From: Will Clark To: bitcoin-dev@lists.linuxfoundation.org Message-ID: Mail-Followup-To: bitcoin-dev@lists.linuxfoundation.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline X-Rspamd-Queue-Id: 4Q0vP90WNYz9sRC X-Mailman-Approved-At: Tue, 18 Apr 2023 10:10:30 +0000 Subject: [bitcoin-dev] Proposal to Remove BIP35 P2P 'mempool' Message X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2023 06:47:53 -0000 I'd like to discuss potential removal of the BIP35 P2P `mempool` message. Supporting the BIP35 `mempool` message for arbitrary peers is bad for privacy while being relatively inefficient for trusted peers. Its original intention was to be publicly callable, but it is now (in Bitcoin Core) gated behind stricter Net Permissions which make it accessible to trusted peers only. When serving trusted clients one alternative might be to use the `savemempool` RPC, which can then be loaded directly (in whole) by the client. This does currently have some shortcomings, namely that the client will lose the contents of their mempool in the process, so if they have different policies some transactions may be lost. Currently there is no way to load and de-duplicate a mempool dumped by this RPC into an existing mempool, although a PR has been opened to Bitcoin Core enabling this functionality so it may be available in the not-too-distant future: https://github.com/bitcoin/bitcoin/pull/27460 In my view dumping and loading a dumped mempool to sync two trusted nodes (or bootstrap one node) makes more sense via RPC as more transaction data can be included in the sync (e.g. transaction expiry time), but there is an argument to be made that syncing via P2P message would be more convenient. N.B. that two (un-patched) bitcoin nodes cannot currently sync from each other using the `mempool` P2P message as there is no functionality to _send_ these messages, only to service them. Removing this message would also provide an (albeit small) clean-up to the P2P codebase, bringing with it the usual benefits in terms of maintainability etc. I have a draft PR open for the removal of the mempool message here: https://github.com/bitcoin/bitcoin/pull/27426 However, before moving forward, I want to ensure that there are no active use cases or technical opposition to its removal from readers of this list. To that end, I kindly request your input on the following questions: 1. Are there any parties who still directly rely on the BIP35 P2P `mempool` message? If so, please share your use case and any potential impact that the removal might have on your operations. 2. Do you foresee any issues or negative consequences resulting from the removal of the `mempool` message? If so, please elaborate on the potential problems and their severity. From a quick search of node implementations I can see `btcd`, `libbitcoin` and `BitcoinJ` all have BIP35 messages specified, but I have not checked more deeply to see if they are using/servicing/ignoring them, and it's difficult to gauge upstream usage by other projects without outreach like this... I look forward to hearing your thoughts. -- Cheers, Will