Merge bitcoin/bitcoin#26933: mempool: disallow txns under min relay fee, even in packages

bf77fc9cb45209b9c560208c65abc94209cd7919 [test] mempool full in package accept (glozow)
b51ebccc28e66c1822ab22d2d178be55c6618196 [validation] set PackageValidationState when mempool full (glozow)
563a2ee4f564c8ea5f8313d711b196e260568c04 [policy] disallow transactions under min relay fee, even in packages (glozow)
c4554fe894d7af8e666f5d424deccddf516713ef [test] package cpfp bumps parents <mempoolminfee but >=minrelaytxfee (glozow)
ac463e87df728689701810c3961155c49fdc5b31 [test util] mock mempool minimum feerate (glozow)

Pull request description:

  Part of package relay, see #27463.

  Note that this still allows packages to bump transactions that are below the dynamic mempool minimum feerate, which means this still solves the "mempool is congested and my presigned 1sat/vB tx is screwed" problem for all transactions.

  On master, the package policy (only accessible through regtest-only RPC submitpackage) allows 0-fee (or otherwise below min relay feerate) transactions if they are bumped by a child. However, with default package limits, we don't yet have a DoS-resistant way of ensuring these transactions remain bumped throughout their time in the mempool. Primarily, the fee-bumping child may later be replaced by another transaction that doesn't bump the parent(s). The parent(s) could potentially stay bumped by other transactions, but not enough to ever be selected by the `BlockAssembler` (due to `blockmintxfee`).

  For example, (tested [here](https://github.com/glozow/bitcoin/commits/26933-motivation)):
  - The mempool accepts 24 below-minrelayfeerate transactions ("0-fee parents"), all bumped by a single high-fee transaction ("the fee-bumping child"). The fee-bumping child also spends a confirmed UTXO.
  - Two additional children are added to each 0-fee parent. These children each pay a feerate slightly above the minimum relay feerate (e.g. 1.9sat/vB) such that, for each 0-fee parent, the total fees of its two children divided by the total size of the children and parent is above the minimum relay feerate.
  - If a block template is built now, all transactions would be selected.
  - A transaction replaces the the fee-bumping child, spending only the confirmed UTXO and not any of the outputs from the 0-fee parents.
   - The 0-fee parents now each have 2 children. Their descendant feerates are above minrelayfeerate, which means that they remain in the mempool, even if the mempool evicts all below-minrelayfeerate packages.
   - If a block template is built now, none of the 0-fee parents or their children would be selected.
   - Even more low-feerate descendants can be added to these below-minrelayfeerate packages and they will not be evicted until they expire or the mempool reaches capacity.

  Unless we have a DoS-resistant way of ensuring package CPFP-bumped transactions are always bumped, allowing package CPFP to bump below-minrelayfeerate transactions can result in these problematic situations. See #27018 which proposes a partial solution with some limitations, and contains discussion about potential improvements to eviction strategy. While no adequate solution exists, for now, avoid these situations by requiring all transactions to meet min relay feerate.

ACKs for top commit:
  ajtowns:
    reACK bf77fc9cb45209b9c560208c65abc94209cd7919
  instagibbs:
    re-ACK https://github.com/bitcoin/bitcoin/pull/26933/commits/bf77fc9cb45209b9c560208c65abc94209cd7919

Tree-SHA512: 28940f41493a9e280b010284316fb8caf1ed7b2090ba9a4ef8a3b2eafc5933601074b142f4f7d4e3c6c4cce99d3146f5c8e1393d9406c6f2070dd41c817985c9

1 files changed, 25 insertions, 12 deletions

diff --git a/doc/policy/packages.md b/doc/policy/packages.md
index 274854ddf9..2a5758318a 100644
--- a/doc/policy/packages.md
+++ b/doc/policy/packages.md
@@ -80,24 +80,37 @@ test accepts):
 If any transactions in the package are already in the mempool, they are not submitted again
 ("deduplicated") and are thus excluded from this calculation.
 
-To meet the two feerate requirements of a mempool, i.e., the pre-configured minimum relay feerate
-(`-minrelaytxfee`) and the dynamic mempool minimum feerate, the total package feerate is used instead
-of the individual feerate. The individual transactions are allowed to be below the feerate
-requirements if the package meets the feerate requirements. For example, the parent(s) in the
-package can pay no fees but be paid for by the child.
-
-*Rationale*: This can be thought of as "CPFP within a package," solving the issue of a parent not
-meeting minimum fees on its own. This would allow contracting applications to adjust their fees at
-broadcast time instead of overshooting or risking becoming stuck or pinned.
-
-*Rationale*: It would be incorrect to use the fees of transactions that are already in the mempool, as
-we do not want a transaction's fees to be double-counted.
+To meet the dynamic mempool minimum feerate, i.e., the feerate determined by the transactions
+evicted when the mempool reaches capacity (not the static minimum relay feerate), the total package
+feerate instead of individual feerate can be used. For example, if the mempool minimum feerate is
+5sat/vB and a 1sat/vB parent transaction has a high-feerate child, it may be accepted if
+submitted as a package.
+
+*Rationale*: This can be thought of as "CPFP within a package," solving the issue of a presigned
+transaction (i.e. in which a replacement transaction with a higher fee cannot be signed) being
+rejected from the mempool when transaction volume is high and the mempool minimum feerate rises.
+
+Note: Package feerate cannot be used to meet the minimum relay feerate (`-minrelaytxfee`)
+requirement. For example, if the mempool minimum feerate is 5sat/vB and the minimum relay feerate is
+set to 5satvB, a 1sat/vB parent transaction with a high-feerate child will not be accepted, even if
+submitted as a package.
+
+*Rationale*: Avoid situations in which the mempool contains non-bumped transactions below min relay
+feerate (which we consider to have pay 0 fees and thus receiving free relay). While package
+submission would ensure these transactions are bumped at the time of entry, it is not guaranteed
+that the transaction will always be bumped. For example, a later transaction could replace the
+fee-bumping child without still bumping the parent. These no-longer-bumped transactions should be
+removed during a replacement, but we do not have a DoS-resistant way of removing them or enforcing a
+limit on their quantity. Instead, prevent their entry into the mempool.
 
 Implementation Note: Transactions within a package are always validated individually first, and
 package validation is used for the transactions that failed. Since package feerate is only
 calculated using transactions that are not in the mempool, this implementation detail affects the
 outcome of package validation.
 
+*Rationale*: It would be incorrect to use the fees of transactions that are already in the mempool, as
+we do not want a transaction's fees to be double-counted.
+
 *Rationale*: Packages are intended for incentive-compatible fee-bumping: transaction B is a
 "legitimate" fee-bump for transaction A only if B is a descendant of A and has a *higher* feerate
 than A. We want to prevent "parents pay for children" behavior; fees of parents should not help