Please help me understand uneconomical forwards \ stacker news ~lightning

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?

view all related items

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.

31 sats \ 0 replies \ @SwapMarket 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.

10 sats \ 1 reply \ @C_Otto OP 7 May

Interesting. Is paying 6x the price worth it, though?

0 sats \ 0 replies \ @anon 7 May

Lightning txs are usually so cheap that I think it's worth it

10 sats \ 3 replies \ @random_ 7 May freebie

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.

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

0 sats \ 1 reply \ @random_ 7 May

curiouser and curiouser

0 sats \ 0 replies \ @random_ 7 May

different graph from the payee's POV? unsupported required features?

151 sats \ 1 reply \ @DarthCoin 7 May

We need René Pickhardt on SN :)

50 sats \ 0 replies \ @C_Otto OP 7 May

I'll ask him :)

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.

10 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.

10 sats \ 1 reply \ @SwapMarket 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.

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.