p2p: implement sender-initiated package relay

ishaanam commented at 4:47 pm on September 29, 2025: contributor

BIP 331 implements receiver-initiated package relay, where receivers can request missing information about packages. However, this requires excessive round trips. If the sender knows that it is giving the receiver a transaction for which it doesn’t have the ancestors, it should be able to just send a package (containing the transaction and the unknown ancestor(s)) instead.

This PR could potentially reduce some bandwidth, and could also reduce the number of transactions in the orphanage. However, if a node is sending packages that the receiver already knows about, this could increase significant bandwidth. As a result, this PR needs more testing. I did some initial testing between two nodes with sendpackages enabled, and it showed that no redundant packages were sent, which indicates that this may be a useful feature.

This PR implements the following:

signaling support for sendpackages and the corresponding negotiation logic
a node will send a pkgtxns message to the receiver node if the ancestor of a transaction that has been requested is not in the receiver node’s m_tx_inventory_known_filter
nodes can process pkgtxns messages
the maximum number of transactions that can be sent through sender-initialized package relay has been set to 2, although this can be changed in the future
adds logging, functional tests, and fuzzing (for ReceivedPackage)

Thank you to glozow for her help with this PR!

[p2p] sendpackages negotiation logic

Co-authored-by: glozow <gloriajzhao@gmail.com>

63cf2b28b0

[p2p] signal support for package relay

Co-authored-by: glozow <gloriajzhao@gmail.com>

16b5a586e9

[rpc] expose package relay on rpc b12cc0bc96

[functional test] test package relay messages

Co-authored-by: glozow <gloriajzhao@gmail.com>

3cd35ef5d1

[p2p] add constants for PKGTXNS message 6c643bcbab

[p2p] allow using PackageToValidate for sender-init package relay c98bdab3c1

[p2p] add `ReceivedPackage` functions for pkgtxns 2d2335e7b5

[p2p] process PGTXNS message 1d299b2979

[p2p] send a package instead of a tx when needed 27325bf9d3

[functional test] test sender init package relay 8c23f765be

[logging] add logging for pkgtxns c5223f2084

[fuzz] add fuzzing for ReceivedPackage 4ec9d9230e

DrahtBot added the label P2P on Sep 29, 2025

DrahtBot commented at 4:48 pm on September 29, 2025: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33500.

Reviews

See the guideline for information on the review process. A summary of reviews will appear here.

LLM Linter (✨ experimental)

Possible typos and grammar issues:

“Whether this node enable package relay and enforces package-related protocol” -> “Whether this node enables package relay and enforces package-related protocol” [subject-verb agreement: “node” -> “enables”]
“sender-initalized” -> “sender-initialized” [spelling: “initalized” -> “initialized”] (occurs in comments above MAX_SENDER_INIT_PKG_SIZE and elsewhere)
“sender-inital” -> “sender-initial” [spelling: “inital” -> “initial”] (in the comment line that begins “Maximum number of transactions that can be in a sender-inital…”)
“We may remove certain transaction from the package that we already” -> “We may remove certain transactions from the package that we already” [number agreement: “transaction” -> “transactions”]
“List versions of each sendpackages received” -> “List of versions of each sendpackages message received” [clarity: make it a proper noun phrase and clarify “sendpackages” refers to messages]

If you want, I can produce a patch with these exact comment/text replacements.

drahtbot_id_5_m

DrahtBot added the label Needs rebase on Sep 29, 2025

DrahtBot commented at 6:55 pm on September 29, 2025: contributor

🐙 This pull request conflicts with the target branch and needs rebase.

in src/net_processing.cpp:2473 in 27325bf9d3 outdated

2466@@ -2458,7 +2467,16 @@ void PeerManagerImpl::ProcessGetData(CNode& pfrom, Peer& peer, const std::atomic
2467         if (auto tx{FindTxForGetData(*tx_relay, ToGenTxid(inv))}) {
2468             // WTX and WITNESS_TX imply we serialize with witness
2469             const auto maybe_with_witness = (inv.IsMsgTx() ? TX_NO_WITNESS : TX_WITH_WITNESS);
2470-            MakeAndPushMessage(pfrom, NetMsgType::TX, maybe_with_witness(*tx));
2471+            // construct a package here if package relay supported
2472+            if (supports_package_relay) {
2473+                if (auto package{GetSenderInitPackage(tx_relay, tx)}) {
2474+                    MakeAndPushMessage(pfrom, NetMsgType::PKGTXNS, package.value());

instagibbs commented at 2:42 pm on October 6, 2025:

wer’re sending the parent here, I don’t think we’re marking the parent as in the known inventory, which means we will keep sending it even if it’s just new children, if f.e. the parent is 0-fee.

instagibbs commented at 8:43 am on October 21, 2025: member

just dropping this before I forget

DrahtBot commented at 1:16 am on January 18, 2026: contributor

⌛ There hasn’t been much activity lately and the patch still needs rebase. What is the status here?

Is it still relevant? ➡️ Please solve the conflicts to make it ready for review and to ensure the CI passes.
Is it no longer relevant? ➡️ Please close.
Did the author lose interest or time to work on this? ➡️ Please close it and mark it with one of the labels ‘Up for grabs’ or ‘Insufficient Review’, so that it can be picked up in the future.

fanquake commented at 1:47 pm on March 3, 2026: member

@ishaanam are you actively working on this?

instagibbs commented at 2:03 pm on March 3, 2026: member

a node will send a pkgtxns message to the receiver node if the ancestor of a transaction that has been requested is not in the receiver node’s m_tx_inventory_known_filter

For note taking, the main critique I had for this is that if an aattacker is replacement cycling the cpfp, then the defender “falls back” to using orphanage to accomplish their package relay. Ideally the defender could keep using the same faster resolution path.

I haven’t thought deeply if that’s a deal breaker, or if we should just eat the extra bandwidth instead. (maybe only if parent is small ala TRUC size?)

p2p: implement sender-initiated package relay #33500

Code Coverage & Benchmarks

Reviews

LLM Linter (✨ experimental)