Oof. This really needs to be fixed.
If I’m understanding correctly, the new requirement would apply to the situation where a local node has offered an HTLC output, said output included in a remote commitment transaction. If this offered HTLC is not included in the latest commitment transaction, it is proposed to fail the corresponding received HTLC on the incoming pair of commitment transactions.
My proposed spec change is to require that nodes should not fail back HTLCs for which a preimage is known.
If my memory is correct, this new mechanism has been already discussed in the past with few LN maintainers and devs in considering some other class of attacks. However, implementing this mechanism comes with the effect that now a LN node force-closes of the incoming channel, even if there is an economic disproportion between the HTLC at risk and the on-chain fee cost to force-close the channel. There is no guarantee on the interactivity of the backward peer. E.g the HTLC might be worth 1000 sats and the force-close absolute fee cost might be 10_000 sats. As far as I remember, there was no convergence among the LN maintainers of each implementation at the time, what should be the best in this situation and if the fall-back shouldn’t be an implementation policy or a node settings detail.
That is an orthogonal problem. The decision of whether to claim an HTLC on chain or not (because it would be uneconomical) is independent of the decision to fail back off-chain .