Specifically, we added a rule to Bitcoin Core which allows for transactions which have a narrow structure to be CPFP’d trivially by either counterparty, irrespective of what the other counterparty does! While the original RBF Carve-Out was a little awkward, its structure was sufficiently generic that other off-chain protocols could reasonably (need to) take advantage of it, however a rule to address this issue seems like it would need to be highly tailored to lightning, which doesn’t seem acceptable (there appears to be a way to shoehorn the existing carve-out, but it results in a ton of extra on-chain volume). For those from bitcoin-dev still reading who are thinking “blah, you clearly don’t need anything else, you have a solution!” we’re talking about extra outputs out the wazoo for hopefully-unnecessary edge cases involving transactions entering the mempool which a user wants to avoid confirming! SINGLE, we clearly need to go the other direction – all HTLC output spends need to be pre-signed. As Bitcoin has no covanents, this must occur using pre-signed transactions – namely “HTLC-Success” and “HTLC-Timeout” transactions, which finalize the resolution of an HTLC, but have a sequence-lock for some time during which the funds may be taken if they had previously been revoked.
All the pre-signed transactions above are constructed with this fee-rate in mind, and, given they are all pre-signed, adding additional fee to them is not generally an option. This of course doesn’t even account for the possibility of similar issues given rely policy differences. I’ll note that while it is a “severe issue”, given the general issues with fee-prediction described in background 3, its pretty hard to argue its really in the scope of the security model of lightning today. You’ll note that B would be just fine if they had a way to safely monitor the global mempool, and while this seems like a prudent mitigation for lightning implementations to deploy today, it is itself a quagmire of complexity, especially when you consider differences in relay policy during an upgrade cycle and how those may effect propagation through the P2P network. This could be accomplished by locking down the transaction types in (3) and (4) by pre-signing them (just, like (1) and (2)) and then using some kind of policy rule to allow only the addition of additional confirmed inputs and one (small) output.
Bitcoin Core’s general policy on RBF transactions is that if a counterparty (either to the transaction, eg in lightning, or not, eg a P2P node which sees the transaction early) can modify a transaction, especially if they can add an input or output, they can prevent it from confirming in a world where there exists a mempool (ie in a world where Bitcoin works). Strategies involving full-RBF for transactions not at the top of the mempool, (slow-)full-mempool-sync allowing mempool-total-fee decreases and relaxations of the RBF rules would be welcome, but without a ton of legwork to include things like package relay I’m not convinced they would suffice. Sadly, and this really hurts from an on-chain-tx-size perspective, we have to include anchor outputs in the HTLC transactions (intuitively I think all of them, but at least HTLC-fulfilling transactions definitely). HTLC transactions which spend the relevant commitment transaction HTLC outputs. This somewhat awkward third layer of transactions is required to allow HTLC timeouts to be significantly lower than the time window during which a counterparty may be punished for broadcasting a revoked state.
This is obviously a very maddening prediction game, especially when the security consequences for negotiating a value which is wrong may allow your counterparty to broadcast and time out HTLCs which you otherwise have the preimage for. To remove this quirk, we came up with an idea a year or two back now called “anchor outputs” (aka the RBF carve-out for those in Bitcoin-land) – a neat trick to allow both counterparties to add fees to a transaction which is being broadcast without getting into the quagmire that is RBF pinning. That is to say, you want to “lock-in” the resolution of an HTLC output (ie by providing the hash lock preimage on-chain) by a fixed block height (likely a few hours from the HTLC creation), but the punishment mechanism needs to occur based on a sequence height (possibly a day or more after transaction broadcast). In order to meet this structure, the commitment transaction (b) must have two (potentially-)additional outputs, each which only one side can spend, and every other output must have a CSV lock associated with it. This is fine as B already knows the txid, and just wants to learn whats in the witness (assuming there is one).
