Package Relay Draft 1 (Single In-Flight Approach) #8
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -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 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`) | ||
|
There was a problem hiding this comment. What is the state of the discussion about modifying or removing From my understanding, With current So I’m thinking if a “wildcard” could be granted to nversion=3 transactions where the parent transaction can be any feeerate and this compensated by the CPFP ? There was a problem hiding this comment. I don't think we are planning to remove Yes, the plan is to allow v3 transactions to be 0 fee when they are cpfp'd |
||
| 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 | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this new “CPFP within a package” ability might alter pinning considerations on legacy channels (i.e before
option_anchor_outputsis still the default on CLN iirc and at least on LDK).The
to_remoteoutput format on legacy commitment transaction is a P2WPKH. There is no 1 CSV as with anchor output. As soon as the local commitment transaction is broadcast on the transaction-relay network, the counterparty can attach a CPFP to amplify the propagation probabilities of the local commitment transaction. This CPFP attachment might be not be seen by the broadcaster of the local commitment transaction. This CPFP can be used as a pinning child vector (e.g rule 3 on absolute fee). The broadcast of a local commitment transaction can be be trigger by a malicious counterparty by refusing anupdate_feeeven in the lack of pending HTLC outputs.So from my understanding the deployment of a “CPFP within a package” might enable some new pinning scenarios against legacy channels (even when there is no pending HTLC outputs) ? I think in term of severity those scenarios are equivalent where the pinnings are trigger by a counterparty and there are pending HTLC outputs. Note there is no currently standardized or deplyed channel upgrade mechanism to uplift legacy channel types to newer anchor output.
Independently of pinnings, I wonder if those low-feerate commitment transactions carried on by a “CPFP within a package” could be leveraged to open the way to some miner fee-harvesting attacks ?
We might have to swallow the bullet after all. Though if we have do it, I prefer to do it in knowledge of the opening attack surface, at least if we can land some easy mitigations on the Lightning-side.