@@ -72,3 +72,48 @@ test accepts):
7272 a competing package or transaction with a mutated witness, even though the two
7373 same-txid-different-witness transactions are conflicting and cannot replace each other, the
7474 honest package should still be considered for acceptance.
75+
76+ ### Package Fees and Feerate
77+
78+ * Package Feerate* is the total modified fees (base fees + any fee delta from
79+ ` prioritisetransaction ` ) divided by the total virtual size of all transactions in the package.
80+ If any transactions in the package are already in the mempool, they are not submitted again
81+ ("deduplicated") and are thus excluded from this calculation.
82+
83+ To meet the two feerate requirements of a mempool, i.e., the pre-configured minimum relay feerate
84+ (` minRelayTxFee ` ) and the dynamic mempool minimum feerate, the total package feerate is used instead
85+ of the individual feerate. The individual transactions are allowed to be below the feerate
86+ requirements if the package meets the feerate requirements. For example, the parent(s) in the
87+ package can pay no fees but be paid for by the child.
88+
89+ * Rationale* : This can be thought of as "CPFP within a package," solving the issue of a parent not
90+ meeting minimum fees on its own. This would allow contracting applications to adjust their fees at
91+ broadcast time instead of overshooting or risking becoming stuck or pinned.
92+
93+ * Rationale* : It would be incorrect to use the fees of transactions that are already in the mempool, as
94+ we do not want a transaction's fees to be double-counted.
95+
96+ Implementation Note: Transactions within a package are always validated individually first, and
97+ package validation is used for the transactions that failed. Since package feerate is only
98+ calculated using transactions that are not in the mempool, this implementation detail affects the
99+ outcome of package validation.
100+
101+ * Rationale* : Packages are intended for incentive-compatible fee-bumping: transaction B is a
102+ "legitimate" fee-bump for transaction A only if B is a descendant of A and has a * higher* feerate
103+ than A. We want to prevent "parents pay for children" behavior; fees of parents should not help
104+ their children, since the parents can be mined without the child. More generally, if transaction A
105+ is not needed in order for transaction B to be mined, A's fees cannot help B. In a
106+ child-with-parents package, simply excluding any parent transactions that meet feerate requirements
107+ individually is sufficient to ensure this.
108+
109+ * Rationale* : We must not allow a low-feerate child to prevent its parent from being accepted; fees
110+ of children should not negatively impact their parents, since they are not necessary for the parents
111+ to be mined. More generally, if transaction B is not needed in order for transaction A to be mined,
112+ B's fees cannot harm A. In a child-with-parents package, simply validating parents individually
113+ first is sufficient to ensure this.
114+
115+ * Rationale* : As a principle, we want to avoid accidentally restricting policy in order to be
116+ backward-compatible for users and applications that rely on p2p transaction relay. Concretely,
117+ package validation should not prevent the acceptance of a transaction that would otherwise be
118+ policy-valid on its own. By always accepting a transaction that passes individual validation before
119+ trying package validation, we prevent any unintentional restriction of policy.
0 commit comments