Making (some) channel limits dynamic



Summary:

The email exchange between Antoine and Bastien discusses the issue of channel jamming in Lightning Network and the need to approach channel parameters configurations carefully. Bastien proposes that certain parameters, such as max_htlc_value_in_flight_msat and max_accepted_htlcs, should be configurable throughout the lifetime of the channel to avoid closing channels when trying to reconfigure them. He suggests adding tlv records in `commitment_signed` to inform the channel peer about the limits being put in place. Antoine raises doubts on whether straighter channel parameters are the best solution for channel jamming, suggesting evaluating the packet forwarder instead of the packet itself through a web-of-trust/reputation system based on counterparty reputation. However, he acknowledges that this presents hurdles such as off-chain liquidity and on-chain fees trade-offs. Another alternative proposed by Antoine is an upfront payment system where a relay node doesn't have to account for a HTLC issuer reputation to decide acceptance and can just forward a HTLC as long it paid enough. Both parties agree that negotiating policies first before opening channels can help avoid overstaking liquidity more than what can be gained from it. They also suggest hybrid models where good behaving peers can be rewarded with a discount on upfront payment policy.


Updated on: 2023-06-03T02:16:23.754672+00:00