Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generalized pending outgoing payments issue #118

Closed
fiatjaf opened this issue Oct 17, 2020 · 1 comment
Closed

Generalized pending outgoing payments issue #118

fiatjaf opened this issue Oct 17, 2020 · 1 comment

Comments

@fiatjaf
Copy link
Collaborator

fiatjaf commented Oct 17, 2020

A payment can be pending for up to 2 weeks (or more?) on Lightning.

This causes two potential problems:

  1. 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.
  2. 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?

  1. To dispatch payments asynchronously and return an HTTP response immediately to the client.
  2. To grab a checking_id (that can be used to check the payment status later on the funding source) and store that.
  3. Perform checks for previously pending outgoing payments. We already have this going on.
  4. As an improvement over 3 for more responsiveness, create outgoing payment asynchronous listeners like the invoice listeners we have currently.

Funding source support

  1. Spark and c-lightning use the payment hash as checking_id for outgoing payments, it can be easily checked later.
  2. LND REST and gRPC use the payment hash as checking_id for outgoing payments, it can be easily checked later (I think).
  3. 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.
  4. 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.
@callebtc
Copy link
Collaborator

Fixed 😎

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants