Stay up to date on all things crypto and blockchain

Indeed, we have to reserve some funds onchain for CPFPing anchors. Onchain fees remain a massive headache in Lightning design, and are probably *the* biggest headache. I'd argue they are the root cause of all the headaches in Lightning. * Every HTLC instantiated on the commitment transaction needs some blockspace allocation in case it ever has to be dropped onchain. That implies **onchain** fees. Lots of forwarding node operators wring their hands and weep every time a channel they opened is dropped onchain with a few HTLCs on it, it really hurts their forwarding business. If the current ***onchain*** feerates are high, the cost of having an HTLC on the commitment tx increases, limiting the number of HTLCs that a channel can transport at the same time. This remains true even post-anchor-commitments: HTLCs still take up blockspace and still cost *something* to instantiate onchain, so each channel will ***still*** have some limit on the number of HTLCs it can properly host, that changes dynamically depending on onchain feerates. Larger channels help avoid this, but larger channels means that if the peer you are large-channeled with goes offline that locks up more liquidity. * Some of the pinning attacks involve lowballing the commitment tx fee during a low-onchain-fee period, then going offline when the onchain fees go high so the victim has to drop them with a low feerate and is then unable to get it confirmed. Then when the victim drops it onchain, you take advantage of the fact that your own output is unencumbered with an `OP_CSV` and attach a bunch of even-lower-feerate txes to pin it on the mempool, unable to confirm. Anchor commitments at least helps with this. Jack Mallers proposed before an economic mechanism to help hedge against onchain fees changing, a derivatives market on onchain fee**rates**. This effectively allows a node to have an "insurance policy" to reduce its liability in case it has to do onchain fee changes (similar mechanisms exist already to provide insurance for farmers, they purchase put options on grain so if the cost of grain becomes lower than expected, they earn money from the put option to offset the reduction in income from the outright sale of grain). This tends to imply that channels have an ongoing cost to maintain, though, as if your channel is not closed, you have to continuously purchase more options that time out at later times when your channel *might* close.

`OP_CHECKLOCKTIMEVERIFY` can be CPFP'ed, but *not* `OP_CHECKSEQUENCEVERIFY`, which is what encumbers outputs of a unilateral commitment transaction without any HTLCs. The block counter starts ticking when the commitment transaction is confirmed, as I mentioned, so this does not work for the general case where there are no HTLCs on a commitment transaction. Since the point of CPFP is to get a parent transaction confirmed, and the `OP_CSV` counter starts ticking ***after*** confirmation, you can't use an output with `OP_CSV` to CPFP, so your proposal will simply not work, full stop. Secondly, if you hold a preimage for the hash in an HTLC, you need to get tranactions confirmed **before** the `OP_CLTV` timeout, else the counterparty might get the timelocked branch confirmed and (if you are a forwarding node) you can be liable for a payout without getting a payin. This cannot be trivially CPFPed either since the current Lightning needs a two-stage transaction system for HTLCs, which is described in detail in BOLT#3 (though you might need to do more digging for the rationales). So no, there is no current easy way to ***generally*** CPFP a unilateral close of a Lightning transaction.