-
Notifications
You must be signed in to change notification settings - Fork 906
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
Comments
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. |
It does appear that MPP is a requirement for large invoices. #4606 |
Is |
IIRC I was trying to do something around 0.08 BTC. |
10 million sats is 0.1 BTC. |
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 . This is probably the same issue as #5250 . |
A possible workaround/solution would be to use |
Probably true, that you can do this with |
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:
|
I have the same issue. The generated invoice for amount over 4294967295msat contains this message: |
Trying to look into code and it looks like this method: |
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
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
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
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
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
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
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
output0.11.2, large-channels enabled.
The text was updated successfully, but these errors were encountered: