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 HORNET¹ 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”.

Resources

• Discussion
• Privacy-Preserving Decentralized Micorpayments Onion Routing in Lightning

Full Proposal

 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