Published on: 2018-11-07T00:18:08+00:00
During a conversation between Laolu and Fabrice, Pierre suggests that the use of HORNET could potentially address an issue raised by Fabrice. However, Pierre raises concerns about whether HORNET would fully solve the problem as it operates at a lower layer and may not be able to handle cases where a peer is unresponsive but still has a valid circuit. Additionally, Pierre brings up the possibility of peers not sending revocations but still responding to pings. While re-reading Fabrice's proposal, Pierre wonders if the 0-satoshi payment would require the commit_sig/revoke_and_ack dance and if implementing this would improve confidence in the availability of peers in the route.In the midst of the discussion, Pierre proposes disconnecting from nodes that take too long to send a revocation, which he believes would significantly improve the issue at hand. He suggests adding this suggestion to BOLT 2 as a "SHOULD" clause, noting that he previously suggested this in lnd but it was not implemented in eclair.Moving forward, the email conversation between Laolu and Fabrice revolves around a proposed solution to address pending payments on the Lightning Network. Laolu suggests using HORNET during the set-up phase to determine whether the route is "lively" or not. This allows the sender to gauge the responsiveness of the route. Additionally, each node can utilize a private "fee function" that takes into account channel congestion or other factors. This fee schedule does not need to be communicated to the wider network, only to those wishing to route across that particular link.Another benefit of the proposed solution is the ability to receive a protocol-level payment ACK, which would be useful when implementing AMP (Atomic Multi-Path Payments). The created circuits can be reused for multiple distinct payments, eliminating the need for each node to maintain per-circuit state.In contrast, Fabrice proposes using a "0 satoshi" payment request to check the responsiveness of all nodes on the route before sending the actual payment. This approach provides a faster indication of whether to proceed with the current route or try an alternative one. The proposed implementation involves generating a "0 satoshi" payment request alongside the real one. The sender would first attempt to "pay" the "0 satoshi" request using the computed route for the actual payment parameters. If the next node in the route fails to reply within the timeout period, the current node will immediately send back an error message.Pending payments are a significant challenge on the Lightning Network, often leading to user complaints. Investigating why payments remain pending can be challenging, as intermediate nodes may be stuck waiting for revocations and recipients may take a long time to reply with a payment preimage. To address this issue, one possible solution is to disconnect from nodes that are taking too long to send revocations and reconnect immediately. This allows pending downstream Hashed Time-Locked Contracts (HTLCs) to be forgotten, causing their corresponding upstream HTLCs to fail.Another potential solution involves using probing with short timeout requirements. Before sending the actual payment, a "blank" probe request could be sent along the same route. This request is similar to a payment request but includes additional requirements. If the next node in the route does not reply within the timeout period, the current node will promptly send back an error message. The probe request can include the same amounts and fee constraints as the actual payment request or exclude amount information, effectively "pinging" every node on the route.To implement this solution, a "0 satoshi" payment request can be generated by the receiving node alongside the real one. The sender would initially attempt to "pay" the "0 satoshi" request using the route computed with the actual payment parameters. By excluding the actual amount and fees, there is a possibility of the actual payment failing due to capacity issues. However, as long as this failure occurs quickly, it is still preferable to having payments remain stuck. It should be noted that while this solution does not address nodes behaving maliciously, it does not exacerbate the current situation either.
Updated on: 2023-07-31T20:35:57.793932+00:00