Also, I think this could be a minor issue for LN implementation. If some of your counterparties have not upgraded their software to support V3 transactions you might have a subset of your channel transaction still under V2 during the transition period. If you have a common child for batched fee-bumping shared between a V2 commitment transaction and V3 commitment transaction, the whole operation is likely to fail. Of course, batch fee-bumping should be considered harmful for time-sensitive commitment transactions (i.e ones with HTLC outputs) though we might have further silent issues even when it's not time-sensitive. In my opinion, this is a potential issue LN devs should be aware of, processing between V2 and V3 channels should be well isolated.

If we would like to add more rational to the design of the rules, we could explain why a scorched earth approach would solve the Lightning case really imperfectly (discussed recently here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021176.html). Indeed, Lightning implementation could just blindly replace-by-fee the pinning transactions, paying up to the channel value. This wouldn't work at all against an attacker pinning with one single malicious transaction multiple channel from different parties where the malicious transaction fee is above the value of each channel. E.g channel A 10000 sats, channel B 25000 sats and channel C 8000 sats. If the malicious pinning transactions fee equals 26000 sats, none of the honest party will rationally fee-bump more than their own channel value. Feerate-only replacement rules scales up to the maximum package size and worst historical mempool reduce consideraly the fee-bumping reserves requirement for a LN node, which is a notable advantage I think.

This should precise if the mempool conflicts are required to be V3 themselves. From my memory of the mailing list discussions and elsewhere, I think the current state of thinking, directly conflicting transactions versions number are not considered. For the Lightning use-case, this is a significant security advantage as the ~80k of public channels, with all pre-signed revoked commitment transactions V2 can be replaced with newer version=3 package. Revoked commitment transactions, even if the honest counterparty is in knowledge of the revocation secret, are still consensus and policy valid transactions, and as such can be leveraged as pinning means. On the other hand, I think allowing V3 to replace V2 chain of transactions lead to the consequence than V2 users are implicitly subscribing to this new replacement regime. A receiver of a V2 transaction could apply the BIP125 rules to estimate the replacement odd of the transaction, and the application logic be broken when the actual rule 3 of minimum between package feerate and ancestor feerate is applied. I don't know if we're significantly interfering with any Bitcoin application here.

Maybe this is a naive question, but is there a way we can make that value configurable instead of using a protocol hard-coded value? Informally, any v3 transaction would include a _descendant_max_weight_ somewhere (handwave, handwave), covered by signatures. This lets L2 contracts decide what values are acceptable for each tx type. For example, in the anchor outputs LN-penalty case, we know that commit txs only need an anchor child that can be constrained to be quite small, so commit txs could use a low value here, that can take into account the maximum weight of a commit tx. Or would this be adding too much complexity for only a marginal improvement? If so, we should probably bikeshed the protocol hard-coded value and use the lowest value we can to minimize the harm a malicious child tx can do.

Since we are introducing a new form of RBF that doesn't currently exist, now might be the best time to at least improve the BIP 125 rules to be incentive compatible in all situations (though this comes at the cost of making replacements potentially more expensive). In particular what I have in mind is that we require the ancestor feerate of the child transaction to be higher than the actual feerate of all transactions that would be evicted. This is conservative but I think would ensure that we don't have any situations where there are transactions being replaced that might appear in the next block, while the new transactions do not. Would this be too conservative for the use cases that we have in mind?

My head hurts :laughing: I'm not 100% sure I'm understanding this rule correctly, can you let me know if the following example makes sense? Let's imagine we have `{commitTxAlice, anchorTxAlice}` in the mempool that we want to replace. What we really want to do is to replace `commitTxAlice` by `commitTxBob` (the child is just a tool to achieve that). We ask `bitcoind` to `fundrawtransaction` to ensure our `anchorTxBob` adds enough funds. `bitcoind` adds an unconfirmed (but safe) wallet input: ``` +-------------+ | commitTxBob |---------+ +-------------+ | +-------------+ | | | +------------------+ +----->| anchorTxBob | | previousWalletTx |---------->| | +------------------+ +-------------+ ``` If we include `previousWalletTx` in the package, this package-rbf would work, right? But if we don't include `previousWalletTx` in the package, this would be rejected? But what if `previousWalletTx` itself has an unconfirmed parent? We cannot include this grand-parent in the package (since packages are only parents-with-single-child). This isn't directly bringing an unconfirmed input, but it is indirectly bringing one. Is that ok? If that's ok, why wouldn't it be ok to just allow adding new unconfirmed inputs in the first place?

Can we relax the `replacement_ancestor_feerate` for v3 transactions? What would be ideal would be to simply ignore unconfirmed v3 ancestors from this calculation (some kind of `replacement_non_v3_ancestor_feerate`), which I believe is ok from an incentives' point of view given the other restrictions on v3 packages. Otherwise we will have the following issue: - a commitment transaction pays 0 fees and weighs 19,000 vbytes (it has many HTLCs) - an attacker publishes a CPFP v3 child that weighs 1,000 vbytes and has an individual feerate of e.g. 100 sat/byte - the package feerate ends up being 5 sat/byte, and the package doesn't confirm - if a feerate of 20 sat/byte for the package was enough to get the package confirmed, the honest participant would target that and thus create a CPFP v3 child with a feerate of 400 sat/byte - but that would be rejected under the current rules, and the honest participant is forced to make the _package feerate_ be 100 sat/byte, which is extremely expensive I'm realizing now that this is actually just another way of formulating @instagibbs's proposal to evict v3 siblings: when the direct conflict is a v3 transaction with an unconfirmed v3 parent, it would be great to only compare their individual feerates.

Maybe an unrelated question, but currently bitcoind doesn't let us create a transaction that has no outputs. In the context of CPFP, transactions with no outputs can be very useful: if you have inputs that let you reach the desired package feerate without creating any change, that's what you want to do. But currently we can't, so we have to overshoot the input amount and add a change output. Is there a consensus rule that disallows transactions with no outputs in blocks? If not, it would be quite useful to allow v3 transactions that have no outputs, introducing that new version is a good opportunity to do that.

This rule startled me a bit at first, it may be worth mentioning that if you want to update the package's child, you should do a normal RBF of just that child. What you mean is that package-rbf applies for the case where we want for example to replace `{commitTxAlice, anchorAlice}` by `{commitTxBob, anchorBob}` where `commitTxAlice` and `commitTxBob` conflict, but we cannot use package-rbf to replace `{commitTxAlice, anchorAlice1}` by `{commitTxAlice, anchorAlice2}` where `anchorAlice2` pays more fees than `anchorAlice1`. In that case we should submit `anchorAlice2` alone and it will go through the usual RBF rules. Is that correct? Also you don't want to mix up package-rbf and normal rbf, so a child tx cannot create conflicts "outside of the package" IIUC.

I think it could be a limitation for second-layer package issuers, where a child-with-parents package aims to replace more than 5 LN commitment transactions at the same time. A counterparty could extend the 5 non-related commitment transactions descendants until reaching max in-mempool limits, thus interfering with their potential package-RBF. Am I correct ? That said, I remember we've already said that child-with-parents to replace multiple LN commitment transactions open the door to malicious interferences.