xpay: limit maximal number of payment parts

[michael1011]

In some scenarios, it is desirable to limit the maximal number of parts (eg Phoenix on the fly channel funding: This payment has been split in two many parts by the sender: 31 parts vs max 6 parts allowed for on-the-fly funding.) when paying an invoice

[Lagrang3]

If a payment was split in so many parts it is likely that it was going to fail anyways.
Many parts indicates that the main routes are almost saturated and usually as we get closer
to those saturation points the theoretical probability of success approaches very quickly to 0.

Anyways, this request is interesting. I think we can write some adhoc modification of the payment routes
to accommodate everything into a small set of routes or fail trying.

Thanks for reporting.

[rustyrussell]

We added a "dev_maxparts" parameter to xpay for now. We should do something more sophisticated for next release.

[rustyrussell]

If a payment was split in so many parts it is likely that it was going to fail anyways. Many parts indicates that the main routes are almost saturated and usually as we get closer to those saturation points the theoretical probability of success approaches very quickly to 0.

Actually, this one was going to succeed as far as I can tell: I am assuming that the ACINQ node gathered all the parts before rejecting them. Otherwise, how would it know there were 31?

The heuristic to detect this would look like so:

1. Was the failure at the last hop?
2. Is there no other route possible?
3. Did we use more than 6 parts?

If this is true, xpay should:

1. Wait for all current parts to finish.
2. Try one more time, but limit ourselves to 6 parts.

This is going to be awkward to test though!

[rustyrussell]

Note: I have not been able to find this string (or similar) anywhere in ACINQ source code. What form was the error in?

[michael1011]

What form was the error in?

Logs of the Phoenix wallet. Seems like they refatored that logic a little. But AI to the rescue:

• the log: https://github.com/ACINQ/lightning-kmp/blob/d11677774396ef5cc221897fcc96cbaef4aa43fc/modules/core/src/commonMain/kotlin/fr/acinq/lightning/payment/IncomingPaymentHandler.kt#L207
• the default value for maxAcceptedHtlcs (I think): https://github.com/ACINQ/lightning-kmp/blob/d11677774396ef5cc221897fcc96cbaef4aa43fc/modules/core/src/commonMain/kotlin/fr/acinq/lightning/NodeParams.kt#L230