Published on: 2020-10-14T08:52:24+00:00
The conversation between Bastien and Olaoluwa Osuntokun revolves around the proposal of adding TLV records to commitment_signed in order to inform channel peers about changing values for certain fields. This proposal aligns with the "parameter re-negotiation" aspect of the loose Dynamic commitments proposal. The goal is to allow both sides to propose, accept, or deny updates to flow control parameters, which can enhance channel security and facilitate a "slow start" protocol for new peers. By gradually adjusting a peer's access to resources based on successful payments, this mechanism can mitigate various types of attacks and give forwarding nodes greater control over their allocated bandwidth. It is noted that while partial implementation of this idea exists today, using an implicit value lower than negotiated values does not effectively communicate the reason for rejecting an HTLC, potentially leading to unusual re-send loops. Additionally, the proposal suggests making the dust limit dynamic to provide protection against future changes.The discussion highlights a potential routing scheme for Lightning Network payments that combines onion routing between intermediate nodes with openly displaying the next destination node in HTLC packets. Once all parts reach the destination node, they are decoded and revealed as an onion to be sent to the subsequent destination node. This approach aims to replace the current Trampoline system, which also utilizes onion routing between intermediate nodes. To address concerns about the receiver's confidence in the input end of the trampoline node being closer to the payer, the suggestion is to include a few nodes that are geographically close to the receiver (or a partial route) in the invoice. The concept of the onions-per-channel model currently used in the network is challenged, drawing inspiration from Tor's two-layer structure where an open lower-level TCP/IP layer is responsible for directing packets to specific network nodes, while a higher layer employs onion routing between nodes. While this alternative approach has its drawbacks, it could offer valuable benefits.The impact of raising the minimum payment size on MPP-split is discussed, with the suggestion that it may not have a significant effect. It is proposed that MPP may only be necessary at the edges of the network rather than the backbone, and if Trampoline is implemented, MPP would be required to reach the first routing node. The current utilization of onions-per-channel is questioned, and the idea of openly displaying the next destination node in HTLC packets is introduced. However, this proposal could be more expensive than source-based routing and potentially result in longer payment latency. Concerns are raised about the receiver's confidence in the input end of the trampoline node being closer to the payer.The conversation between t-bast and ZmnSCPxj centers around the dynamic nature of channel parameters and the potential impact on MPP-split success rates when raising the minimum payment size. While t-bast argues that raising the minimum payment size introduces complexity, ZmnSCPxj suggests that it may negatively affect MPP success rates. As an alternative, asymmetric splits and using big payments as an aggregation method are proposed. T-bast also expresses the viewpoint that MPP is not necessary on the network's backbone but should only be utilized at the edges. They propose that as the network matures, channels between "serious" routing nodes will be significantly larger than individual payment sizes, allowing MPP routes to be computed on a smaller subset of the network, thereby increasing success rates. Despite differing opinions, t-bast believes that live channel parameter updates should not be restricted.In a separate email exchange, Bastien expresses the desire to raise `htlc_minimum_msat` on large channels without needing to close and open new channels. They suggest that updating these parameters unilaterally does not require halting channel operations and that even if some HTLCs fail due to stricter policies, it is a minor inconvenience that would not trigger channel closures. Bastien asks if other implementations besides eclair face challenges or have specific characteristics that make implementing this feature difficult or undesirable. In response, ZmnSCPxj discusses the complexities of an upfront payment system and suggests exploring a web-of-trust approach based on reputation. However, this approach presents risks of centralization around existing long-lived nodes.In their email conversation, Bastien discusses the idea of dynamically adjusting channel parameters such as `htlc_minimum_msat` on large channels without the need to close and open new channels. They suggest that these parameters can be updated unilaterally without interrupting channel operations. The only inconvenience would be some failed HTLCs if policies become stricter, but this would not necessitate channel closures. Bastien specifically asks about the feasibility and desirability of this feature in other implementations apart from eclair. In response, ZmnSCPxj explores the challenges of an upfront payment system and proposes the concept of a web-of-trust based on reputation. However, this introduces the risk of centralization around long-lived nodes.The idea of using an upfront payment system instead of relying solely on reputation for accepting HTLC issuers is proposed.
Updated on: 2023-07-31T23:04:20.283471+00:00