1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
|
Return-Path: <dave@dtrt.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id B18FBC002A
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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" <dave@dtrt.org>
To: bitcoin-dev@lists.linuxfoundation.org
In-Reply-To: <u2v2u2tpzcuyi7mkwmt3wwco6f54v5ys5nk6fdrx4d5ucy4unx@vpaz4n65lyqu>
References: <u2v2u2tpzcuyi7mkwmt3wwco6f54v5ys5nk6fdrx4d5ucy4unx@vpaz4n65lyqu>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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).
|
