Impossible to pay an invoice bigger than 4294967295msat to a direct peer using our own direct channel

[devastgh]

Issue and Steps to Reproduce

Paying an invoice to your peer thats bigger than 4294967295msat (2^32 -1).
Set the max fee to 0, since you want to use your direct channel with him.
If amount is higher than 4294967295msat, MPP kicks in, and uses every random channel to fulfill the invoice, without any chance of success.
Paying to our own peers should be only attempted with our own direct channels, if it has enough liquidity to fulfill the payment.

getinfo output

0.11.2, large-channels enabled.

[kristapsk]

Don't remember precise numbers, but some time ago I also couldn't pay bigger invoice to peer with whom I have direct channel, where amount was less than outbound amount in that channel. My solution back then was to manually split into multiple invoices. v0.10.2, with large channels enabled. But not sure it was problem in my end or his end.

[grubles]

It does appear that MPP is a requirement for large invoices. #4606

[wtogami]

Is large-channels enabled on the direct peer as well? I know for a fact invoices larger than 10 million sats can work even as a single part.

[kristapsk]

IIRC I was trying to do something around 0.08 BTC.

[wtogami]

10 million sats is 0.1 BTC.

[devastgh]

Is large-channels enabled on the direct peer as well? I know for a fact invoices larger than 10 million sats can work even as a single part.

Yes, it's enabled. I routeinely forward bigger than 10mil htlcs. It's the pay logic that wants to split it over 2^32 -1 .
Just to demonstrate a test case:
100mil channel. I have 90mil liquidity on my side. My peer generates me a 20mil invoice. If i try to pay it (with 0 as max fee) mpp kicks in, and payment fails. If i get an invoice of 4mil, i can pay that over the direct channel with 0 fee.

This is probably the same issue as #5250 .

[nepet]

A possible workaround/solution would be to use sendpay directly, skipping the logic of the pay command.
On v0.11.2 (regtest) I can pay a single part invoice over 100000000000msat (1 btc) via a direct channel with a capacity of 10 btc.

[devastgh]

Probably true, that you can do this with sendpay. However, i shouldn't be using a low level command just to be able to pay an invoice. The "issue" is with the pay logic.
IMHO pay should check if we have direct channel(s) with the receiver, and if we have enough liquidity in those channel(s) and if both is true use just that/those for the payment.

[zerofeerouting]

I can confirm this very annoying bug. The node seems to start splitting up the payment after a certain size (tried to send 5M sats) resulting in unexpectedly high fees, especially if there is a direct channel with the required liquidity.

Solution proposal:

Before splitting larger payments, check if there is a direct channel with enough liquidity to the destination and just use that channel.

[urza]

I have the same issue.

The generated invoice for amount over 4294967295msat contains this message:
"warning_mpp": "The invoice is only payable by MPP-capable payers."
from that it looks like the payer needs to pay with MPP.. I dont know enough about MPP to understand whether this is necessity or the payer can check "oh we have direct channel and it is big enough" and ignore it..

[urza]

Trying to look into code and it looks like this method:
https://github.com/ElementsProject/lightning/blob/master/lightningd/invoice.c#L549
is used to create bolt11 invoice and should be able to see that there is channel with enough liquidity to get paid through it, but for some reason if the amount is over 4294967295msat (2^32 -1) it doesn't find and and fallback method for creating mpp invoice is used
https://github.com/ElementsProject/lightning/blob/master/lightningd/invoice.c#L641