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

Implement EstimateRouteFee #167

Open
huumn opened this issue May 13, 2024 · 5 comments
Open

Implement EstimateRouteFee #167

huumn opened this issue May 13, 2024 · 5 comments

Comments

@huumn
Copy link

huumn commented May 13, 2024

It doesn't appear to be implemented. I'm pretty sure we can do this by probing using the library, but this would be nice to have.

The request/response are pretty simple so I imagine wrapping it is less of a lift than other things.

/*
EstimateRouteFee allows callers to obtain a lower bound w.r.t how much it
may cost to send an HTLC to the target end destination.
*/
rpc EstimateRouteFee (RouteFeeRequest) returns (RouteFeeResponse);

@alexbosworth
Copy link
Owner

Yes there is probeForRoute

@huumn
Copy link
Author

huumn commented May 14, 2024

If anyone wants a shim for this, something like this should work (untested):

async function estimateRouteFee ({ lnd, dest, amt_sat, request, timeout }) {
  return await new Promise((resolve, reject) => {
    lnd.router.estimateRouteFee({ dest: Buffer.from(dest, 'hex'), amt_sat, payment_request: request, timeout }, (err, res) => {
      if (err) {
        reject(err)
      } else {
        if (res.failure_reason) {
          reject(new Error(`Unable to estimate route: ${res.failure_reason}`))
        }

        resolve({
          routingFeeMsat: res.routing_fee_msat,
          timeLockDelay: res.time_lock_delay
        })
      }
    })
  })
}

@bnonni
Copy link
Contributor

bnonni commented Jan 2, 2025

Would love to help out on this issue if it hasn't already been completed. Any guidance in addition to the above commentary is welcomed.

@alexbosworth
Copy link
Owner

Sounds good, I would avoid the destination based arguments and stick to only the payment request argument

For the response i would interpret the error instead of returning the error in the success. Potentially just return the callback with an error if the PaymentFailureReason is not reason none

@bnonni
Copy link
Contributor

bnonni commented Jan 2, 2025

Thank you 🙏🏼 will follow up with any further questions etc. as I move along

bnonni added a commit to bnonni/lightning that referenced this issue Jan 4, 2025
bnonni added a commit to bnonni/lightning that referenced this issue Jan 4, 2025
bnonni added a commit to bnonni/lightning that referenced this issue Jan 4, 2025
bnonni added a commit to bnonni/lightning that referenced this issue Jan 4, 2025
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

3 participants