From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id B18FBC002A for ; Tue, 18 Apr 2023 16:57:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 8C98260D59 for ; Tue, 18 Apr 2023 16:57:44 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 8C98260D59 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGVHy2dyt6aJ for ; Tue, 18 Apr 2023 16:57:43 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 9A2E260D58 Received: from smtpauth.rollernet.us (smtpauth.rollernet.us [IPv6:2607:fe70:0:3::d]) by smtp3.osuosl.org (Postfix) with ESMTPS id 9A2E260D58 for ; Tue, 18 Apr 2023 16:57:43 +0000 (UTC) Received: from smtpauth.rollernet.us (localhost [127.0.0.1]) by smtpauth.rollernet.us (Postfix) with ESMTP id 803AE2800083 for ; Tue, 18 Apr 2023 09:57:42 -0700 (PDT) Received: from webmail.rollernet.us (webmail.rollernet.us [IPv6:2607:fe70:0:14::a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by smtpauth.rollernet.us (Postfix) with ESMTPSA for ; Tue, 18 Apr 2023 09:57:41 -0700 (PDT) MIME-Version: 1.0 Date: Tue, 18 Apr 2023 06:57:41 -1000 From: "David A. Harding" To: bitcoin-dev@lists.linuxfoundation.org In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.10 Message-ID: <4aeb6a134be5d941fcc65cf512ce89e4@dtrt.org> X-Sender: dave@dtrt.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy: http://www.rollernet.us/policy X-Rollernet-Submit: Submit ID 1406.643ecc05.ee0a3.0 Subject: Re: [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 16:57:44 -0000 > When serving trusted clients one alternative might be to use the > `savemempool` RPC, which can then be loaded directly (in whole) by the > client. It was common in the past for lightweight clients to load a BIP37 filter and then send a `getdata` for requesting `mempool`. In that case, the node would filter the mempool transactions and only send transactions matching the filter to the client (plus false positives, which the client could choose to keep very low). The above approach minimized the amount of data that needed to be transferred, which can be very important for lite clients on metered or bandwidth-limited connections---especially considering that lite clients on poor connections (e.g. mobile) might get disconnected frequently and so need to re-request the filtered mempool every time they reconnect to acquire any new unconfirmed transactions that arrived while they were disconnected. By comparison, during a period of backlog (the natural state, we hope), the mempool contents in the `savemempool` format are about 300 MB. I think that's a bit much to potentially be sending to lite clients just so they can learn about any unconfirmed transactions which arrived since they last connected. Although I understand and support the desire to remove problematic public interfaces like BIP37 and BIP35, I think we should also be aiming to build interfaces which make it easier for people to use third-party wallets with their own trusted nodes. Right now, it's possible to use[*] `getheaders`, BIP157/8, and `getdata(block)` with your own node to learn about all confirmed transactions affecting your wallet. It's also possible now to use BIP37 and BIP35 to get unconfirmed transactions in a bandwidth-efficient manner, if your connection is allowlisted. I would personally like to see lite clients that use a trusted node receive a replacement for BIP35/7 support before those protocols are removed. (Of course, I'd also like to see support for BIP324 and for something like countersign so that authenticated and encrypted connections from a lite client to a trusted node are easy to setup.) Thanks, -Dave [*]: Requires an authenticated connection to be secure (and should ideally be encrypted).