From: "David A. Harding" <dave@dtrt•org>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Proposal to Remove BIP35 P2P 'mempool' Message
Date: Tue, 18 Apr 2023 06:57:41 -1000 [thread overview]
Message-ID: <4aeb6a134be5d941fcc65cf512ce89e4@dtrt.org> (raw)
In-Reply-To: <u2v2u2tpzcuyi7mkwmt3wwco6f54v5ys5nk6fdrx4d5ucy4unx@vpaz4n65lyqu>
> 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).
next prev parent reply other threads:[~2023-04-18 16:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-18 6:37 Will Clark
2023-04-18 16:57 ` David A. Harding [this message]
2023-05-01 13:24 ` 0xB10C
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4aeb6a134be5d941fcc65cf512ce89e4@dtrt.org \
--to=dave@dtrt$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox