Reconsider package transactions that are immediately trimmed #36328

instagibbs commented at 4:26 PM on September 24, 2026: member

In-master, if a package is entered into mempool at the lowerst chunk feerate, pushing the mempool oversize, this causes that transaction (package) to be trimmed immediately. This is fine and expected, but the returned validation result TX_MEMPOOL_POLICY precludes the now-evicted parent from being considered again (i.e. fetched / processed as package) until after another block is found.

This is not a major issue, but would result in unneeded censorship of someone low-balling package feerates.

The already-in-mempool case needs a bit more logic due to the FeeFailure's requirement of package feerate knowledge, so I opted to use the "would have used" value even though it was never directly submitted in the same-txid-different-wtxid case. Alternatively, we could simply get rid of the FeeFailure value as IIUC it's not used in non-testing code. This may be a larger code change but could make the resulting code more maintainable going forward. This could also be future work.

Related to finding made by Loupe, and subsequently Red Team.

validation: make package transactions trimmed after submission reconsiderable

A transaction evicted by LimitMempoolSize() right after being accepted
by itself is TX_RECONSIDERABLE: a package with a higher feerate may
still get it in. Transactions submitted together as a package and
evicted by the final trim in AcceptPackage() were TX_MEMPOOL_POLICY
instead, as that code predates TX_RECONSIDERABLE.

For 1p1c relay this put an evicted parent and child in the reject
filter until the next block, so a new child could not bump the parent
back in.

47c9070b9d

test: 1p1c package evicted after submission can be bumped by a new child before a new block 7235f02718

validation: make every package transaction evicted by the final trim reconsiderable

Package transactions can also be in the mempool before the final trim
by having been accepted by themselves earlier in the same call, or by
being there already, possibly with a different witness. Make them
TX_RECONSIDERABLE too when evicted: they are evicted for their feerate
like the others and may still be accepted in a package.

7a30d53ca9

DrahtBot commented at 4:26 PM on September 24, 2026: 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/36328.

Reviews

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

test: every package transaction evicted by the final trim is reconsiderable 3c6cd0c00a

instagibbs force-pushed on Sep 24, 2026

DrahtBot added the label CI failed on Sep 24, 2026

DrahtBot commented at 4:40 PM on September 24, 2026: contributor

🚧 At least one of the CI tasks failed. <sub>Task ASan + LSan + UBSan + integer: https://github.com/bitcoin/bitcoin/actions/runs/36027432164/job/107727417441</sub> <sub>LLM reason (✨ experimental): CI failed to compile test_bitcoin because Clang -Wthread-safety (treated as -Werror) reported an exclusive cs_main lock is missing when calling ProcessNewPackage in txpackage_tests.cpp.</sub>

<details><summary>Hints</summary>

Try to run the tests locally, according to the documentation. However, a CI failure may still happen due to a number of reasons, for example:

Possibly due to a silent merge conflict (the changes in this pull request being incompatible with the current code in the target branch). If so, make sure to rebase on the latest commit of the target branch.
A sanitizer issue, which can only be found by compiling with the sanitizer and running the affected test.
An intermittent issue.

Leave a comment here, if you need help tracking down a confusing failure.

</details>

DrahtBot removed the label CI failed on Sep 24, 2026