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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
