Published on: 2018-03-04T22:18:56+00:00
In a recent discussion on the Lightning Network mailing list, the topic of preventing payment failures was addressed. Jim Posen suggested pinging a channel for capacity as a solution, but Rusty Russell disagreed, citing privacy concerns. Christian Decker also expressed agreement with Russell and warned against the privacy risks associated with pinging channels. Instead, Russell proposed using fees as a signaling mechanism when capacity gets low. Posen offered two possible solutions: making `temporary_channel_failure` return a `channel_update` with disabled flags or implementing fast failure to reduce latency.Posen also discussed the strategy for choosing a route to send funds over. He suggested determining all possible routes, ranking them by estimated fees based on channel announcements and number of hops, and trying them successively until one works. This approach aims to prevent payment failures caused by bandwidth being locked up in HTLCs that are about to fail anyway. However, others argued that failure is not common enough to warrant designing for it yet. The use of fees as a means of signaling low capacity and adjusting them accordingly was also suggested as a potential solution. Additionally, the `temporary_channel_failure` returns a `channel_update` that implies the disabled flag, which should be made true if the request asks for it. These solutions may prove sufficient for preventing payment failures caused by lack of capacity.Another topic of discussion was flood pinging and its potential solutions. One suggestion was to include a small proof-of-work with the ping, similar to BIP 154. However, some argued that this could counteract the purpose of the ping, which is meant to be a cheaper way to collect routing information. It was noted that there are better ways to disrupt the network than using the proposed ping mechanism. For example, someone can send payments along any circuit with a randomly generated payment hash and force a payment failure at the end of the route. The benefits of the ping mechanism include quicker payments due to lower latency and the ability to ping all possible routes in parallel. However, it is also faster and cheaper for someone to extract information about channel capacities on the network with a binary search.In a separate discussion on AMP (atomic multi-path), the issue of splitting a payment into multiple smaller payments was addressed. It was noted that only the source (payer) has the ability to split a payment, as intermediaries may decide to send it to a channel with high fees. One suggestion was to use IP-Fragmentation techniques to solve this problem. The idea was to encapsulate the second part of the fragmented payment in a new onion routed package that goes on a detour to the original "next" hop. However, concerns were raised about the impact on HTLC and the handling of timeouts.Overall, the discussions highlighted the importance of considering potential security risks and implementing effective safeguards in the Lightning Network to prevent payment failures and protect privacy. Jim Posen's proposal for pinging channels for capacity and determining the best route based on estimated fees received mixed responses, with some expressing concern over privacy and others suggesting alternative solutions like using fees as a signaling mechanism. The topic of flood pinging also raised questions about its effectiveness and potential for extracting channel capacity information. The discussion on AMP focused on the issue of splitting payments and proposed solutions involving IP-Fragmentation techniques, but concerns were raised about the impact on HTLC and timeouts.
Updated on: 2023-07-31T19:48:40.137983+00:00