Liquidity Ads: Updated Spec Posted, please review

The recent correspondence reveals a discussion focused on the specifications of Replace-By-Fee (RBF) and its implications for API flexibility. The idea to renegotiate leases is proposed as a means to allow equivalency between open, splice, and RBF operations. However, an additional potential downside identified is the increased likelihood of RBF attempts being rejected by remote peers.

There's also contemplation over the possibility of incorporating an additional CheckLockTimeVerify (CLTV) constraint directly within the output, thereby eliminating the need for a secondary transaction. Unfortunately, the current protocol does not support requiring a signature from a peer for their commitment transaction, which negates this as a viable option.

With the existing protocols in place, several alternative strategies are considered. One option is to leave the vulnerability unaddressed, advising lessors to limit their HTLC (Hashed Time-Locked Contracts) inflight value. Another suggestion is to extend the payment HTLC through the channel by the duration of the lease. Lastly, rearchitecting the commitment flow is discussed as a long-term solution. This could be coordinated with future upgrades that might simplify the process or necessitate changes for other reasons, such as synchronous commitment flows, Point Time-Locked Contracts (PTLCs), or the eltoo model.

The ongoing dialogue reflects a thoughtful examination of the challenges and potential solutions associated with improving transaction flexibility and security within the network, acknowledging that while immediate fixes may be limited, future architectural changes hold promise for closing current gaps.