Replies: 2 comments
-
This is called "HODL invoices" and is not supported in phoenixd, because locking liquidity is a bad practice for the network (it is not only locked in your own channel, but in all channels in the payment route) and not sustainable at scale. On top of that, forgetting to fail/fulfill a payment, due to bugs etc. will cause a force closure of your local channel. Best we could do is allow a very short hold period (~10 seconds), with a configurable fallback behavior to fulfill/fail in case the backend doesn't reply in time. In your case you would probably default with a fulfill, meaning that if your backend is slow to respond and loses the race against the timer, you probably want to have accepted the btc payment and handle a refund in support if the fiat payment failed, as opposed to having made the fiat payment and not received the btc. |
Beta Was this translation helpful? Give feedback.
-
Yes, that describes exactly how we would like to use it, including the default to fulfill. The 10 seconds should be more than enough time to determine the settlement status. |
Beta Was this translation helpful? Give feedback.
-
Not sure if this is possible with the current API, but for our use case, it would be really helpful to hold onto an incoming lightning payment and not release the preimage until after some server-side event happens. We have a BTC-in -> FIAT-out app that acts as an easy offramp to spend sats IRL. On occasion, the fiat side of the transaction can't be fulfilled. We can detect this failure case on the server, and in that case we would like to 'reject' the lightning settlement -- effectively returning the sats back to sender. By doing so we could make the entire transaction atomic.
Any ideas if/how that might be possible?
Beta Was this translation helpful? Give feedback.
All reactions