policy: allow <minrelay txns in package context if paid for by cpfp #33892

1. 
   instagibbs commented at 8:24 pm on November 17, 2025: member

   Prior to cluster mempool, a policy was in place that disallowed non-TRUC transactions from being TX_RECONSIDERABLE in a package setting if it was below minrelay. This was meant to simplify reasoning about mempool trimming requirements with non-trivial transaction topologies in the mempool. This is no longer a concern post-cluster mempool, so this is relaxed.

   In effect, this makes 0-value parent transactions relayable through the network without the TRUC restrictions and thus the anti-pinning protections.

2. DrahtBot added the label TX fees and policy on Nov 17, 2025
3. 
   DrahtBot commented at 8:24 pm on November 17, 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/33892.

   Reviews

   See the guideline for information on the review process.

   Type	Reviewers
   ACK	ajtowns, ismaelsadeeq

   If your review is incorrectly listed, please copy-paste <!–meta-tag:bot-skip–> into the comment that the bot should ignore.

   Conflicts

   No conflicts as of last run.

4. DrahtBot added the label Needs rebase on Nov 25, 2025
5. instagibbs force-pushed on Nov 25, 2025
6. instagibbs marked this as ready for review on Nov 25, 2025
7. DrahtBot removed the label Needs rebase on Nov 25, 2025
8. policy: Allow any transaction version with < minrelay

   Prior to cluster mempool, a policy was in place that
   disallowed non-TRUC transactions from being
   TX_RECONSIDERABLE in a package setting if it was below
   minrelay. This was meant to simplify reasoning about mempool
   trimming requirements with non-trivial transaction
   topologies in the mempool. This is no longer a concern
   post-cluster mempool, so this is relaxed.
   
   In effect, this makes 0-value parent transactions relayable
   through the network without the TRUC restrictions and
   thus the anti-pinning protections.

   1488315d76
9. instagibbs force-pushed on Nov 26, 2025
10. in doc/release-notes-33892.md:4 in fda7a16c02

    0@@ -0,0 +1,5 @@
    1+P2P and network changes
    2+-----------------------
    3+
    4+- All transaction versions includeing anon-TRUC can now be relayed when below minrelay,
    

    ---

    ---

    

    fanquake commented at 2:38 pm on November 26, 2025:

    LLM: s/includeing/including/
11. instagibbs force-pushed on Nov 26, 2025
12. in test/functional/mempool_ephemeral_dust.py:210 in 1488315d76 outdated

    206@@ -207,18 +207,16 @@ def test_nonzero_dust(self):
    207         self.connect_nodes(0, 1)
    208         assert_mempool_contents(self, self.nodes[0], expected=[])
    209 
    210-    # N.B. If individual minrelay requirement is dropped, this test can be dropped
    

    ---

    ---

    

    kevkevinpal commented at 6:29 pm on November 26, 2025:

    why not drop the whole test as per this comment?

    ---

    

    instagibbs commented at 4:26 pm on December 1, 2025:

    changed my mind; it’s good to have v2 ephemeral dust coverage since we don’t have much/any?
13. fanquake added this to the milestone 31.0 on Dec 4, 2025
14. in doc/release-notes-33892.md:5 in 22b7a25c4a

    0@@ -0,0 +1,5 @@
    1+P2P and network changes
    2+-----------------------
    3+
    4+- All transaction versions including non-TRUC can now be relayed when below minrelay,
    5+    including 0 fee, as long as the package feerate is above the floating minfee (#33892)
    

    ---

    ---

    

    ajtowns commented at 2:41 am on December 18, 2025:

    I think package relay is still restricted to 1P1C, so this only means that a single child can CPFP a below-minfee parent even if the child is non-TRUC. Might be good to be clearer about that.

    I think the submitpackage RPC is slightly more general, in that it will accept n+1 transactions made up of a single child and n parents, and will now support parents below minfee. However, these will not relay if there is more than one parent that is below minfee. This might be something of a foot-gun.

    ---

    

    instagibbs commented at 2:15 pm on December 18, 2025:

    This is already the case if a transaction is >=minrelay but not reaching floating minfee, so it’s an existing footgun unfortunately.

    It started out as experimental support before 1P1C was the scaled down idea IIRC, so we probably should have come back and restricted it as soon as that direction was chosen.

    Willing to discuss this in an open issue somewhere to see what should be done if anything.

    ---

    

    instagibbs commented at 2:20 pm on December 18, 2025:

    re: the release note, something like:

     0diff --git a/doc/release-notes-33892.md b/doc/release-notes-33892.md
     1index 125ee4a51f..5f51336e5b 100644
     2--- a/doc/release-notes-33892.md
     3+++ b/doc/release-notes-33892.md
     4@@ -1,5 +1,6 @@
     5 P2P and network changes
     6 -----------------------
     7 
     8 - All transaction versions including non-TRUC can now be relayed when below minrelay,
     9-    including 0 fee, as long as the package feerate is above the floating minfee (#33892)
    10+    including 0 fee, as long as the package feerate is above the floating minfee and
    11+    the sponsoring CPFP transaction has no other less-than-floating minfee ancestors (#33892)
    

    ?

    ---

    

    ajtowns commented at 1:45 am on December 19, 2025:

    Maybe be more verbose still? Something like:

    Transactions participating in one-parent-one-child package relay (ie, a parent whose feerate is below the floating mempool minimum feerate, with a child that brings the combined feerate above the floating minimum feerate and has all other parents already accepted into the mempool) can now have the parent whose feerate is lower than the -minrelay feerate (and can be 0 fee). This expands the change from 28.0 to also cover packages of non-TRUC transactions.

    Otherwise, “no other ancestors with a feerate less than the floating minfee” reads a little better at least.

    ---

    

    ajtowns commented at 1:50 am on December 19, 2025:

    so we probably should have come back and restricted it as soon as that direction was chosen.

    Maybe; I’m not super concerned about footguns in RPCs that are documented as experimental and that document the footgunnyness. Spending the time on improving relay to match what the RPC can do seems superior to spending time to adding safety rails to the RPC to me.

    ---

    

    instagibbs commented at 2:17 pm on December 19, 2025:

    Took your text, tried to make it less parenthetical, starting with the important bits. Let me know what you think.

    ---

    

    ajtowns commented at 5:58 pm on December 19, 2025:

    Err, should be -minrelaytxfee :man_facepalming:

    ---

    

    instagibbs commented at 7:21 pm on December 19, 2025:

    pushed
15. 
    ajtowns commented at 2:45 am on December 18, 2025: contributor

    Subject is a bit confusing; this leaves the checks for individual transactions considered on their own, but removes the check for transactions within a package, where the transaction’s feerate is below minfee, even if its got a CPFP relationship that bumps the fee. We still check the overall package fee, and we require the package to be a child plus direct parents via IsChildWithParents, so shouldn’t end up with us adding garbage to the mempool that’s immediately discarded, and the cluster mempool logic should have us remove it if it eventually becomes garbage due to the child being replaced.

    I think this allows submitpackage to accept packages that we can’t relay (due to multiple parents being CPFP’ed), however that’s a documented flaw (see submitpackage’s help), so that seems acceptable.

16. instagibbs renamed this:
    policy: Remove individual transaction <minrelay restriction
    policy: allow <minrelay txns in package context if paid for by cpfp
    on Dec 18, 2025
17. instagibbs force-pushed on Dec 19, 2025
18. add release note about supporing non-TRUC <minrelay txns e44dec027c
19. instagibbs force-pushed on Dec 19, 2025
20. 
    ajtowns commented at 1:56 am on December 20, 2025: contributor

    ACK e44dec027ceec2a5f74b65636689a51833d78a94 - lgtm
21. 
    ismaelsadeeq commented at 3:13 pm on December 22, 2025: member

    ACK e44dec027ceec2a5f74b65636689a51833d78a94
22. fanquake merged this on Dec 27, 2025
23. fanquake closed this on Dec 27, 2025

    ---

24. in doc/policy/packages.md:102 in 1488315d76 outdated

    105-submitted as a package. Note that this rule does not apply to
    106-[TRUC transactions](https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki) as an individual
    107-TRUC transaction is permitted to be below the mempool min relay feerate, assuming it is considered within
    108-a package that meets the mempool's feerate requirements.
    109-
    110 *Rationale*: Avoid situations in which the mempool contains non-bumped transactions below min relay
    

    ---

    ---

    

    flack commented at 7:20 pm on December 27, 2025:

    There’s now two paragraphs called “Rationale” right next to each other. Does this one by any chance belong to the removed Note?

    ---

    

    instagibbs commented at 9:16 pm on December 27, 2025:

    think you’re right, do you want to open a follow-up with its removal?

    ---

    

    flack commented at 9:34 pm on December 27, 2025:

    @instagibbs done in #34160
25. flack referenced this in commit 337b4a2369 on Dec 27, 2025

Contributors
instagibbs DrahtBot fanquake kevkevinpal ajtowns ismaelsadeeq flack

Labels
TX fees and policy

Milestone
31.0