Improving payment UX with low-latency route probing
Pending payments are a common UX problem for LN that users often complain about. While the cause of this problem is not easily unraveled, there have been several issues involving stuck intermediate nodes awaiting revocation and recipients who can’t give timely preimage replies.
Fabrice Drouin proposed a change to address the issue using a faster
“proceed/try another route” answer using a probe with a short timeout requirement.
The system sends the blank
probe request prior to sending the actual payment,
via the same route.
Although the probe request will have the same requirements as the actual payment, it will have an additional requirement that the current node will instantly send back an error message if the next node in the route does not reply within the short timeout of a few hundred milliseconds.
The probe requests could include the same amount and fee constraints as the actual payment or it could have no amount information attached.
Laolu thinks HORNET1 is a better option at addressing this issue, first because during the set up phase, a user can actually tell if the route is lively or not because the circuit cannot be finalized if all the nodes are not available, which removes the need to send a “probe request”.
Fabrice Drouin Wed, 31 Oct 2018 10:42:41 -0700 Context ====== Sent payments that remain pending, i.e. payments which have not yet been failed or fulfilled, are currently a major UX challenge for LN and a common source of complaints from end-users. Why payments are not fulfilled quickly is not always easy to investigate, but we've seen problems caused by intermediate nodes which were stuck waiting for a revocation, and recipients who could take a very long time to reply with a payment preimage. It is already possible to partially mitigate this by disconnecting from a node that is taking too long to send a revocation (after 30 seconds for example) and reconnecting immediately to the same node. This way pending downstream HTLCs can be forgotten and the corresponding upstream HTLCs failed. Proposed changes =============== It should be possible to provide a faster "proceed/try another route" answer to the sending node using probing with short timeout requirements: before sending the actual payment it would first send a "blank" probe request, along the same route. This request would be similar to a payment request, with the same onion packet formatting and processing, with the additional requirements that if the next node in the route has not replied within the timeout period (typically a few hundred milliseconds) then the current node will immediately send back an error message. There could be several options for the probe request: - include the same amounts and fee constraints than the actual payment request. - include no amount information, in which case we're just trying to "ping" every node on the route. Implementation ============ I would like to discuss the possibility of implementing this with a "0 satoshi" payment request that the receiving node would generate along with the real one. The sender would first try to "pay" the "0 satoshi" request using the route it computed with the actual payment parameters. I think that it would not require many changes to the existing protocol and implementations. Not using the actual amount and fees means that the actual payment could fail because of capacity issues but as long as this happens quickly, and it should since we checked first that all nodes on the route are alive and responsive, it still is much better than “stuck” payments. And it would not help if a node decides to misbehave, but would not make things worse than they are now (?) Cheers, Fabrice
Support us and the authors of this article by donating to the following address:35rFUtgSAHyoycgsfHRqxW7Sv7taPkJCir
Comments powered by Talkyard.