OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely

The email discusses the concept of anchor channels and their relevance in the context of spendable HTLC outputs. The sender mentions that the distinction between pre-anchor and anchor channels is not significant for the discussion at hand. They explain that if they have one spendable HTLC output and gain knowledge of their counterparty commitment transaction from the network's mempools, the spend can be considered malleable and used as a Child Pays for Parent (CPFP).

In the case of anchor channels, where both parties have balance outputs or pending HTLCs, the counterparty commitment transaction needs to be attached with a fee under the minimum mempool fee for the replacement cycling to occur. This scenario assumes network congestion to be present. However, the sender highlights that the more interesting case is a future world with package relay deployed at the peer-to-peer level and an anchor output on the lightning-side.

In this scenario, the most advanced replacement, as illustrated in the provided test (where the commitment has an anchor output - see L125), can take place. The email concludes with a farewell from Antoine.