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

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

Closed
devastgh opened this issue Jul 13, 2022 · 11 comments

Comments

@devastgh
Copy link

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.

@devastgh devastgh changed the title Impossible to pay an invoice bigger than 4294967295msat to a direct peer using our own channel Impossible to pay an invoice bigger than 4294967295msat to a direct peer using our own direct channel Jul 13, 2022
@kristapsk
Copy link
Contributor

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
Copy link
Contributor

grubles commented Jul 14, 2022

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

@wtogami
Copy link
Contributor

wtogami commented Jul 15, 2022

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
Copy link
Contributor

IIRC I was trying to do something around 0.08 BTC.

@wtogami
Copy link
Contributor

wtogami commented Jul 15, 2022

10 million sats is 0.1 BTC.

@devastgh
Copy link
Author

devastgh commented Jul 15, 2022

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
Copy link
Collaborator

nepet commented Jul 17, 2022

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
Copy link
Author

devastgh commented Aug 11, 2022

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
Copy link
Contributor

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
Copy link
Contributor

urza commented Nov 23, 2022

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
Copy link
Contributor

urza commented Nov 23, 2022

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

rustyrussell added a commit to rustyrussell/lightning that referenced this issue Nov 29, 2022
If we both support large channels, we can actually send giant HTLCs.

This, in turn, fixes pay (which relies on this field!).

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Plugins: `pay` now knows it can use locally-connected wumbo channels for large payments.
Fixes: ElementsProject#5250
Fixes: ElementsProject#5417
rustyrussell added a commit to rustyrussell/lightning that referenced this issue Nov 29, 2022
If we both support large channels, we can actually send giant HTLCs.

This, in turn, fixes pay (which relies on this field!).

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Plugins: `pay` now knows it can use locally-connected wumbo channels for large payments.
Fixes: ElementsProject#5250
Fixes: ElementsProject#5417
cdecker pushed a commit to rustyrussell/lightning that referenced this issue Nov 30, 2022
If we both support large channels, we can actually send giant HTLCs.

This, in turn, fixes pay (which relies on this field!).

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Plugins: `pay` now knows it can use locally-connected wumbo channels for large payments.
Fixes: ElementsProject#5250
Fixes: ElementsProject#5417
cdecker pushed a commit to rustyrussell/lightning that referenced this issue Nov 30, 2022
If we both support large channels, we can actually send giant HTLCs.

This, in turn, fixes pay (which relies on this field!).

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Plugins: `pay` now knows it can use locally-connected wumbo channels for large payments.
Fixes: ElementsProject#5250
Fixes: ElementsProject#5417
ddustin pushed a commit to ddustin/lightning that referenced this issue Apr 11, 2023
If we both support large channels, we can actually send giant HTLCs.

This, in turn, fixes pay (which relies on this field!).

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Plugins: `pay` now knows it can use locally-connected wumbo channels for large payments.
Fixes: ElementsProject#5250
Fixes: ElementsProject#5417
ddustin pushed a commit to ddustin/lightning that referenced this issue May 12, 2023
If we both support large channels, we can actually send giant HTLCs.

This, in turn, fixes pay (which relies on this field!).

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Plugins: `pay` now knows it can use locally-connected wumbo channels for large payments.
Fixes: ElementsProject#5250
Fixes: ElementsProject#5417
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

7 participants