Stuck payments represent a serious UX problem. Users can become confused, frustrated and potentially even lose their funds. Payments can get ‘stuck’ by something as simple as communication being lost between nodes on the route or something more sinister like a malicious node withholding a payment.
When payments are stuck it means that the sender needs to wait for the HTLCs to timeout for the funds to be reimbursed. It is also not advised to retry the payment as it may result in a double payment. As Hiroki Gondo notes in the Bitcoin dev mailing list: “The payer cannot obtain the information to prove he has paid twice (he has only a single preimage).”.
In the same email, Gondo goes on to propose a method to prevent stuck payments using PTLCs. By introducing a new phase that requires the receiving node to acknowledge a PTLC from the sending node once a route has been found. This signals to the sending node that the payment didn’t get stuck. For the payments that did get stuck, the sending node would never receive this acknowledgement message (the timeout could be set to a minute or so) and would know that it is safe to retry the payment with another invoice.
It’s useful to note that it doesn’t require all the nodes in the route to be upgraded to handle the update phase as it is only communicated between the sender and the receiver. The acknowledgement message can be stuffed into the ‘reason’ field of the bolt invoice that the nodes will pass on without having to deal with it. The details of this mechanism may be elaborated upon in a future article.