The problem arises when a liquidity provider (Alice) advertises that she is willing to commit a certain amount of funds (e.g., 10,000 sats) to a channel for a specified period (e.g., 28 days). To prevent Alice from closing the channel and using her funds for something else after receiving payment, a timelock is applied to the channel.

However, if the liquidity consumer (Bob) sends a significant amount of funds through the channel, Alice's balance in the channel can become much higher than the amount she received as a fee. If Bob is malicious, he can prevent Alice from moving her funds until the expiration of the timelock.

To mitigate this problem, it has been suggested to only apply the timelock to the liquidity contribution (i.e., only Alice's 10,000 sats). However, this introduces complexities and inefficiencies.

An alternative solution proposed by Bastien Teinturier is to simply drop the timelock (or make it optional) and let liquidity buyers take the risk that providers may close channels shortly after receiving their liquidity fees. If channels opened through liquidity ads typically generate significant forwarding fee income, there would be an incentive for providers to keep channels open.

By eliminating the timelock or making it optional, liquidity buyers would have the flexibility to decide whether or not they are willing to take the risk that a provider may close the channel prematurely. If the potential rewards from forwarding fees outweigh the risk, liquidity buyers may be willing to accept this risk.

Has anyone tried Zeus v0.8.0's embedded node?

Also does anyone know of any wallets that allow CPFP? You would think it would be more widely used over RBF given there's no special relay rules needed to broadcast them (noted by Pieter Wuille in the stack exchange thread listed in the optech)