From: Will Clark <will@256k1•dev>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] Proposal to Remove BIP35 P2P 'mempool' Message
Date: Tue, 18 Apr 2023 06:37:45 +0000 [thread overview]
Message-ID: <u2v2u2tpzcuyi7mkwmt3wwco6f54v5ys5nk6fdrx4d5ucy4unx@vpaz4n65lyqu> (raw)
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
next reply other threads:[~2023-04-18 6:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-18 6:37 Will Clark [this message]
2023-04-18 16:57 ` David A. Harding
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=u2v2u2tpzcuyi7mkwmt3wwco6f54v5ys5nk6fdrx4d5ucy4unx@vpaz4n65lyqu \
--to=will@256k1$(echo .)dev \
--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