diff options
author | glozow <gloriajzhao@gmail.com> | 2023-01-17 11:01:13 +0000 |
---|---|---|
committer | glozow <gloriajzhao@gmail.com> | 2023-04-17 09:53:59 +0100 |
commit | 563a2ee4f564c8ea5f8313d711b196e260568c04 (patch) | |
tree | 5e4c10d2a89e4a7254670b6565585c451c8803ab /doc/policy | |
parent | c4554fe894d7af8e666f5d424deccddf516713ef (diff) |
[policy] disallow transactions under min relay fee, even in packages
Avoid adding transactions below min relay feerate because, even if they
were bumped through CPFP when entering the mempool, we do not have a
DoS-resistant way of ensuring they always remain bumped. In the future,
this rule can be relaxed (e.g. to allow packages to bump 0-fee
transactions) if we find a way to do so.
Diffstat (limited to 'doc/policy')
-rw-r--r-- | doc/policy/packages.md | 37 |
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 |