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
A payment can be pending for up to 2 weeks (or more?) on Lightning.
This causes two potential problems:
When someone clicks "pay" on LNbits an HTTP request is made and doesn't return until the payment is finished -- but that could be 2 weeks. And it could be that the server will wait for that payment to complete for 2 weeks, meanwhile blocking all other actions from all other users.
If LNbits goes down or the connection is dropped in the meantime the payment will still be pending on the funding source, but LNbits won't be able to ever check that because it doesn't have a checking_id for that payment, the checking_id is only saved after the funding source responds with a success message (thus making the checking_id mostly useless in this case).
What is the solution?
To dispatch payments asynchronously and return an HTTP response immediately to the client.
To grab a checking_id (that can be used to check the payment status later on the funding source) and store that.
Perform checks for previously pending outgoing payments. We already have this going on.
As an improvement over 3 for more responsiveness, create outgoing payment asynchronous listeners like the invoice listeners we have currently.
Funding source support
Spark and c-lightning use the payment hash as checking_id for outgoing payments, it can be easily checked later.
LND REST and gRPC use the payment hash as checking_id for outgoing payments, it can be easily checked later (I think).
LNPay.co uses the lnTx ID as checking_id. That is only returned after the payment is complete. This cannot work. Two possible solutions are:
a. Beg Tim to change LNPay.co so it returns the lnTx ID before the payment is completed, for example as an HTTP response header that gets flushed early. We can read that and close the connection and only check payment success later.
b. Mandate the setup of an webhook listener for LNPay.co outgoing payments, so we can check the webhook content and match it to the payment hash of our pending outgoing payments, therefore acknowledging its success.
OpenNode.co uses an order ID as checking_id. The situation is the same as with LNPay.co, or maybe not, it's not clear that they will return a response from the HTTP only when the payment is complete or if they will return it early.
The text was updated successfully, but these errors were encountered:
A payment can be pending for up to 2 weeks (or more?) on Lightning.
This causes two potential problems:
checking_id
for that payment, thechecking_id
is only saved after the funding source responds with a success message (thus making thechecking_id
mostly useless in this case).What is the solution?
checking_id
(that can be used to check the payment status later on the funding source) and store that.Funding source support
checking_id
for outgoing payments, it can be easily checked later.checking_id
for outgoing payments, it can be easily checked later (I think).checking_id
. That is only returned after the payment is complete. This cannot work. Two possible solutions are:a. Beg Tim to change LNPay.co so it returns the lnTx ID before the payment is completed, for example as an HTTP response header that gets flushed early. We can read that and close the connection and only check payment success later.
b. Mandate the setup of an webhook listener for LNPay.co outgoing payments, so we can check the webhook content and match it to the payment hash of our pending outgoing payments, therefore acknowledging its success.
checking_id
. The situation is the same as with LNPay.co, or maybe not, it's not clear that they will return a response from the HTTP only when the payment is complete or if they will return it early.The text was updated successfully, but these errors were encountered: