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

Askrene query reserve #7701

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

Lagrang3
Copy link
Collaborator

Adds a new RPC to query the reserves on a given channel.
It is necessary to know the total amount in-flight on a channel to be
able to estimate the channel's liquidity after a failed routing attempt.

For example if a routing request for 1000sat fails in channel "1x1x1:0" and there are no other in-flight
HTLCs in that channel that we know of, we can assume that channel's liquidity is a number below 1000sat.
However, in a similar situation when a routing request for 1000sat fails in channel "1x1x1:0" but we know that
there are two pending HTLCs: one for 1000sat and another for 4500sat, then we may assume that the
channel's liquidity is some number below 1000sat+4500sat=5500sat.

In order to effectively make use of askrene-inform-channel in those situations we need to know the total
value of the reserves combined.

@Lagrang3 Lagrang3 requested review from rustyrussell and removed request for cdecker September 26, 2024 13:15
@Lagrang3 Lagrang3 added this to the v24.11 milestone Sep 26, 2024
Adds a new RPC to query the reserves on a given channel.
It is necessary to know the total amount in-flight on a channel to be
able to estimate the channel's liquidity after a failed routing attempt.

Changelog-EXPERIMENTAL: askrene: add RPC askrene-query-reserve

Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
@rustyrussell
Copy link
Contributor

This is racy (well, everything is, but this seems worse than taking reserves into account internally).

Reserves are not guaranteed usage. So, worst case, we should take them into account for maximum, ignore them for minimum?

Which also implies you should clear your own reservations before calling inform, for best results.

Currently in xpay (UNTESTED!) I use inform for failures/successes only. So we can assume this is how it will be used, and so it's sensible to account for reserves internallly?

I also have listreserves implemented, so we can find reserve leaks, but I don't think we should use it for this?

Sorry that I've been piling up stuff in my tree. It's because I've been trying to get xpay to the point where I can test the APIs to assess them properly.

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

Successfully merging this pull request may close these issues.

2 participants