You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
user has a channel with sufficient inbound liquidity to receive a swap payment.
user creates swap
Invoice is created with a route hint to the user's channel
User's channel closes (or node was unaware of the channel closure)
Now the swap is unpayable
Thinking about how we should be able to handle this scenario.
If we find out the channel for this invoice closed, maybe we should notify the user this swap has become unpayable, so the user shouldn't send onchain funds to it.
Ideally we would always regenerate the invoice for the swap for every redeem. That would ensure there is always a working route hint in the invoice. In this case, however, the new invoice would have to pay for a channel open, something the user didn't ask for.
I thought we are generating the invoice on every redeem
We're not. The problem is the invoice is persisted on the greenlight node and you can't add another one with the same preimage. A solution could be deleting the invoice and creating a new one. But his could run into race conditions. This is why we ensure there is always a route hint in the invoice now, and we're able to recover if the invoice is not in our local storage, but it's still the same invoice on the node.
@JssDWt as you mentioned I am not sure we should change the invoice from one that doesn't open a channel to one that does. From the reason you said the user didn't see the opening fees.
As for a case where there are channels with enough inbound capacity (after the closure) the lsp is free to choose them for the forward as long as they meet the route policy.
Problem statement:
Thinking about how we should be able to handle this scenario.
Issue for greenlight: Blockstream/greenlight#419
The text was updated successfully, but these errors were encountered: