-
Notifications
You must be signed in to change notification settings - Fork 895
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
Renepay: htlc limits on mcf #6905
Renepay: htlc limits on mcf #6905
Conversation
65fcc77
to
496301c
Compare
Thanks for prioritizing this! I think this will be a very important issue. Without having looked at the code I wonder what happens if the solution of a flow wants to allocate 10M sats on a channel (of a higher capacity) but the channel has for example an Thus I think it makes sense flow computation (before linearization) to set the capacity of channels at most to: On the long term I think for over all network reliability it makes sense to
I do understand that my proposal may tend to avoid channels for a second time even if that channel could potentially forward two concurrent htlcs. However I think that kind of default behavior has overall better properties for the semantics of |
yes
Agree.
We might allow for a second and a third HTLC on the same channel by using |
The magic number However one novel thought just came to my mind: One could choose the arcs in the piecewise linearization to have a capacity of Downsides: Even if a single arc is being used the disection of flow into onions could require to still have more than 1 htlc on the channel. Best way to mitigate such problems if in future the protocol would be more suitable to the flow like nature of payments. Eg including |
I see the case for using Also, would it make sense to apply the same constraint to local channels? |
Sorry for the meta comment: I see the problems that of course a remote channel could still have more than 1 HTLCs. Also not sure about local channels. I tend to say we could be a bit more relaxed about those as we don't pay base fee and have no uncertainty and actually are wiling to use our full liquidity. I was wondering weather this could be configurable. In this way we would not decide for the user. However I assume it would be very hard to create an API that users understand. Having parameters that people do not understand intuitively how to use is always a bit frustrating. |
There are 3 places in the code where we can enforce that the payment routes (aka flows) respect the
I would say, since point 1 is already being pushed in PR #6893, let's keep this PR as the implementation of point 2. |
6d18e6f
to
6e5a55d
Compare
Between this and #6893, which one do you think solves this issue best @renepickhardt and @Lagrang3 ? It is marked for the 24.02 milestone, and I'd like to merge one of the two solutions before the feature freeze. |
Hi @cdecker. Short answer: both are needed. They do different things, but they also happen to overlap on checking that the HTLC are within the given bounds. The current problems we want to solve in #6893 was meant to solve B. This is where #6905 comes in. |
The discussion with @renepickhardt was mainly because instead of limiting the |
9982677
to
0807bff
Compare
Rebased and fixed conflicts. |
Great, thanks for the explanation, that makes sense. If that's ok with you, I can shepherd this PR through CI, and get it merged asap :-) |
The flow routes returned by minflow are bounded by the htlc_min and htlc_max along the route whenever possible.
0807bff
to
aedb565
Compare
Rebased on top of |
Usually
minflow
would first compute a MCF solution and then construct routes based on that.Neither of these steps would take into account the limits
htlc_min
andhtlc_max
on channels.PR #6893 removes a portion of the amount committed to the routes if they exceed the
htlc_max
,but that PR assumes that that excess is small and it is due to the MCF not taking into account the
addition of fees to the flow. If the amount committed to a route exceeds the
htlc_max
in a greatamount, we would be better off to allocate that difference in other routes by recomputing MCF.
But we don't have a check for the size of that number and we just assume that the excess is small.
I think a better way to constraint the flow with respect to the
htlc_max
(andhtlc_min
) bounds isto do it at a lower level: either when computing MCF or when dissecting the solution into routes.
The easiest solution is the latter and this is what we do in the current PR.
Once the MCF is solved, we start constructing flow routes. On those routes we can compute the
smallest of the
htlc_max
and the biggest of thehtlc_min
and use those as limits to the amountwe can send. When these flow routes are passed to
flows_fit_amount
we will be assured that anyamount exceeding
htlc_max
would be because of the addition of fees.