lightning-dev

Combined summary - RFC: simplifications and suggestions on open/accept limits.

Combined summary - RFC: simplifications and suggestions on open/accept limits.

In an email exchange, a user named Alexis Petropoulos asked for help in unsubscribing from an email list.

Conner responded and directed Alexis to the unsubscribe link in the footer of the Linux list. The conversation then shifted to a discussion about simplifications and suggestions for open/accept limits in lightning-dev.Gert-Jaap Glasbergen expressed his thoughts on allowing the freedom to choose between satoshis and millisatoshis as the smallest fraction in the Lightning Network. He acknowledged that there would be trade-offs, such as overpaying fees in whole satoshis if someone routes your payment. Gert-Jaap offered to further analyze the consequences of this choice and propose a specification to address it.Another topic of discussion was the minimum and maximum standards set by the Lightning Network protocol. Different implementations have varying requirements and limitations for aspects such as funding_satoshi, dust_limit_satoshis, max_htlc_value_in_flight_msat, channel_reserve_satoshis, and minimum_depth. The author suggested changes and improvements to these variables based on their current values.A conversation between Anthony Towns and Gert-Jaap Glasbergen touched upon the enforceability on the blockchain as fees increase. Individuals can define the minimum size of payments or channel balances they are willing to accept. However, there is a need for nodes to be aware of these requirements to prevent futile attempts to route payments through channels that do not adhere to the specified limits. The complexity of open-source software configuration was also discussed, with Gert-Jaap emphasizing the importance of finding the right configuration options while acknowledging the potential increase in complexity.Christian Decker and Gert-Jaap Glasbergen debated the use of dust limit as an atomic unit on Bitcoin. Decker argued that the 546 satoshis dust limit is no longer a tiny amount compared to current minimum fees and values transferred. Gert-Jaap disagreed, stating that not every transferred value must be multiples of the dust limit. The discussion revolved around finding the right balance between enforceability on-chain and trustless payments.The debate about allowing sub-satoshi units in Bitcoin was discussed between Rusty Russell and Gert-Jaap Glasbergen. Russell expressed concerns about the inoperability of the network if fees are often sub-satoshi and questioned the compromise on security. Glasbergen argued for user choice, even if it meant sacrificing some level of trust. Further analysis and a concrete proposal were suggested to gauge potential support for including this choice in the specification.Gert-Jaap Glasbergen shared his opinion on the removal of htlc_minimum_msat, highlighting its importance as a protection measure against trimmed HTLCs. He recommended setting a safe default above the dust limit to prevent unenforceable trusted in-flight payments. The discussion also touched upon other variables such as transaction_min_msat_multiple, accept_subsatoshi, and minimum_depth, with differing opinions on their inclusion or modification.The conversation addressed negotiation values in the Lightning Network protocol, specifically discussing the ability to negotiate sub-satoshi payments. Suggestions were made to add variables like transaction_min_msat_multiple or accept_subsatoshi to allow users to opt out of sub-satoshi payments. Other negotiation values, such as funding_satoshis, dust_limit_satoshis, max_htlc_value_in_flight_msat, channel_reserve_satoshis, and minimum_depth, were also discussed with proposed improvements.The message emphasized the need to re-examine values in the protocol and simplify or refine them based on experience. It provided suggestions for variables such as funding_satoshis, dust_limit_satoshis, max_htlc_value_in_flight_msat, channel_reserve_satoshis, and minimum_depth. The proposed changes aimed to improve the current values accepted by different implementations and ensure better functionality and security of the Lightning Network.

Discussion History

0
Rusty RussellOriginal Post
October 17, 2018 03:22 UTC
1
October 30, 2018 10:56 UTC
2
November 1, 2018 01:03 UTC
3
November 5, 2018 08:48 UTC
4
November 6, 2018 03:40 UTC
5
November 6, 2018 22:22 UTC
6
November 7, 2018 01:31 UTC
7
November 7, 2018 02:26 UTC
8
November 7, 2018 04:51 UTC
9
November 7, 2018 09:39 UTC
10
November 9, 2018 06:47 UTC
11
November 9, 2018 06:53 UTC