Setting to_self_delay and cltv_expiry prior to channel opening

Original Postby Michael Folkson

The discussion revolves around the necessity for a standardized approach to negotiating configuration options for channel openings within the Lightning network, focusing on timelocks such as to_self_delay and cltv_expiry.

These settings represent a balance between security against fraudulent actions and the undesirable locking of capital for extended periods. The importance of these timelocks becomes especially pronounced during times of high onchain fees, where their settings significantly affect transaction costs and confirmations.

Questions have been raised about the current default timelock settings across different Lightning implementations, the ease with which node operators can adjust these defaults, and whether there should be an established protocol for negotiation of these settings before channel establishment. A particular concern is whether differences in timelock preferences should be made transparent during the negotiation process, ensuring that a clear understanding exists if a channel opening is rejected due to mismatched timelock settings.

Additionally, it's questioned whether the negotiation of timelock settings should occur within the peer-to-peer protocol itself or through separate, out-of-band communications prior to agreeing to utilize the Lightning protocol for channel creation. This inquiry into the flexibility and communication of timelock settings is essential to adapt to varying operator preferences and the dynamic fee environment on the blockchain.

For further insights and understanding of Bitcoin, the email includes a link to educational resources available at portofbitcoin. Michael Folkson's contact information is provided along with his GPG key for secure communication.