Please help me understand uneconomical forwards
409 sats \ 14 comments \ @C_Otto 7 May lightning
As outlined in #527919, I started a test node using lnd v0.18.0-beta.rc1 so that I can play around with negative inbound fees. That's fine and a topic for another day.
On that new node I added a channel back to my main node (c-otto.de), and another channel to ACINQ just to get some connectivity. The fees are set up as follows:
  • c-otto.de to lnd v.0.18.0-beta.rc1: 2000ppm
  • lnd v.0.18.0-beta.rc1 to ACINQ: 1000ppm (the negative inbound fees are not relevant)
  • c-otto.de to ACINQ: 500ppm
Now, if you want to reach ACINQ (or go through that node) via c-otto.de, you can
  • pay 500ppm: x to c-otto.de to ACINQ
  • pay 2000ppm + 1000ppm: x to c-otto.de to lnd v0.18.0-beta.rc1 to ACINQ
Strangely, I see both kinds of transactions, with more (!) sats taking the expensive detour.
Why is that?
write
preview
related posts
1208 sats \ 7 replies \ @rahim1971 7 May
CLN does not always take the most economical route (default lightning-pay), doesn't it?
See: https://docs.corelightning.org/reference/lightning-pay#randomization
Route randomization means the payment algorithm does not always use the lowest-fee or shortest route. This prevents some highly-connected node from learning all of the user payments by reducing their fees below the network average.
reply
31 sats \ 0 replies \ @MiddleWay 7 May
Weird idea. How can a routing node learn user's payments when it cannot know where the payment originated and its final destination? Glad I am using LND.
reply
10 sats \ 1 reply \ @C_Otto OP 7 May
Interesting. Is paying 6x the price worth it, though?
reply
0 sats \ 0 replies \ @anon 7 May
Lightning txs are usually so cheap that I think it's worth it
reply
10 sats \ 3 replies \ @random_ 7 May
CLN also factors in risk based on the amount of liquidity locked up vs. lock time.
Wonder what the capacities and lock times are along both routes OP mentioned. And min/max htlcs.
reply
0 sats \ 2 replies \ @C_Otto OP 7 May
  • c-otto.de to ACINQ: 100M capacity, time lock delta 99
  • c-otto.de to lnd v0.18.0-beta.rc1: 2.5M capacity, time lock delta 99
  • lnd v0.18.0-beta.rc1 to ACINQ: 4M capacity, time lock delta 100
reply
0 sats \ 1 reply \ @random_ 7 May
curiouser and curiouser
reply
0 sats \ 0 replies \ @random_ 7 May
different graph from the payee's POV? unsupported required features?
reply
151 sats \ 1 reply \ @DarthCoin 7 May
We need René Pickhardt on SN :)
reply
50 sats \ 0 replies \ @C_Otto OP 7 May
I'll ask him :)
reply
10 sats \ 1 reply \ @zapomatic 7 May
I also see uneconomical forwards that seem incomprehensible. It seems that fees don't matter so much to real traffic. Only rebalancers seem to set fee limits in routing consistently. Many wallets like Alby appear to blindly send traffic, accepting whatever fees get the transaction to the destination with the most certainty according to their liveness metrics--but real traffic is fine paying higher fees.
This makes some sense, as Joe-Bob buying alligator jerky from Tom's Apocalypse Shack doesn't really care if he's paying 2-3% in lightning fees for the purchase.
reply
0 sats \ 0 replies \ @ProfSors 9 May
I also had the same "issue". I routed transactions between big (top 10) routing nodes, charging 2%+ on each transaction. These nodes have dozens of channels connecting, and for sure hundreds of paths more economical than mine.
reply
10 sats \ 1 reply \ @MiddleWay 7 May
Tor or clearnet? Seen that with my test nodes connected with Tor. Route discovery fails sometimes for no apparent reason. Use queryroutes before sending a payment and always limit maximum fee. You can try to reset mission control with resetmc.
reply
20 sats \ 0 replies \ @C_Otto OP 7 May
c-otto.de is both (tor, ipv4, ipv6), the other node is tor only. I'm not sending any payment, I'm forwarding payments.
reply