I'm not 100% sure it "works this way" but it would be wonderful if we could define (i.e. increase) the routing budget when paying an invoice. Many larger payments (over 100K sats) fail for me frequently, and I would assume it would have a higher success rate if a higher routing fee were permitted.
My only question is whether it's actually the sender who defines the routing fee/budget, or if it's built into the receiver's invoice when the invoice is generated?
The only time I've seen this "controlled" before is when creating a payout invoice within swapping services like RoboSats, where the user can choose to submit a payout invoice for a slightly lesser amount, and increase the routing fee budget accordingly.
So, I'm not sure this feature request is actually an option for the payer of the invoice... But if it is, then it would be awesome, and I would be deeply satisfied if I'm someday able to pay invoices of 100K to 1M sats with a decent success rate.
Hi, it depends on the node implementation. If you use the default (LDK) the maximum fee is 1% + 50 sats. I believe this should be high enough to find a route. Which channel partners do you have currently?
Hey roland - thanks for the quick answer. I would agree, it sounds like a high-enough budget. And my Hub-cloud node is about as well-connected as I can get it, without opening additional channels to private individuals.
Without being too specific, I have numerous channels open with Alby's LSPs, in a range of size but all of them are larger than they payments I'm trying to send. I also have sufficient spending capacity on the Alby side, and plenty of receiving capacity on the other side, but larger payments still frequently fail. So it's got me pretty puzzled.
2 side notes... (if you'd prefer to take these questions offline/separately rom this feature request, just say the word).
Have you noticed that the Olympus/Zeus LSP has a hard time routing payments? I've found that when most of my spending capacity is in that channel, I seem to experience a higher failure rate than when my liquidity is stored in, say, a Kappa or ACINQ channel.
It also seems that payments fail more frequently when my spendable sats are split between multiple channel partners and need to be "combined" to pay out, rather than when it's all concentrated in a single channel. Not sure if that's expected, or coincidence).
consciousdruid your node scorer should learn from failed payments and get better over time, but it depends who you are trying to pay and how many hops there are. If the LSPs are not sufficiently connected to the node you're trying to pay to, this could definitely happen.
To avoid doing MPP payments, you should have a channel at least 4x the size of the payment you are trying to make (LDK will by default do MPP payments otherwise, but still might do MPP anyway if it thinks it is a better route).
I do not personally use Olympus because I run only public channels. But Olympus should work fine.
If you could email support@getalby.com and share the node you are trying to pay to, and your own pubkey if you're willing to share it, we can check with our LSPs if there is a good route to the destination.
Thanks for reporting the issue. Making sure payments are reliable is very important.
Thanks roland, I appreciate it. I think I've met these conditions – most of my attempted payments over 100K sats tend to fail, despite having abundant capacity. I'll reach out to support in the morning 🫡