I have just raised the fees significantly on some channels \ stacker news ~lightning

pull down to refresh

I have just raised the fees significantly on some channels

9938 sats \ 22 comments \ @C_Otto 13 Jan lightning

Inspired, or rather reminded, by The Wall's post (https://twitter.com/hi__im__dave/status/1746149064867979418) I just raised some fees on my routing node c-otto.de.

For some selected peers like bfx-lnd0/1 and Binance, whenever I have lots of liquidity in a single channel (meaning I could route a very large transaction), from now on I charge much more than usual (2000+ ppm). The fee rate is adjusted frequently, and lowered if the configured liquidity is NOT available anymore.

I hope that this information/signal is interpreted accordingly, so that my node actually serves large transactions to those peers. I don't have any concrete information, but I believe that some operators deliberately skip cheap channels to avoid routing failures, and prefer more expensive channels for larger transactions. This matches the observation described in The Wall's post.

Raising fees when there's a lot of liquidity on my side of the channel seems counter-intuitive, as I'd like to incentivize the rest of the network to route through that channel. Usually, making stuff cheaper helps increasing demand. This might not be the case in the lightning network, and I'm curious to see how this pans out in the long run!

I hope that consistently providing a great routing experience is rewarded, and that high fee aren't that bad. As a positive side effect, rebalancing (topping up) high fee rate channels gets much easier.

view all related items

1631 sats \ 5 replies \ @zapomatic 13 Jan

lowering the fee back down when the liquidity lowers is also unintuitive. Wouldn't it be better to adjust htlc_max_msat for that channel and just leave the fee static?

1000 sats \ 3 replies \ @C_Otto OP 13 Jan

I just tweaked my code thanks to this idea. For large channels, I set htlc_max_msat to the current balance (rounded down to 5M sats, minimum 5M sats). This might help attract semi-large payment requests, avoiding too-large requests.

0 sats \ 2 replies \ @zapomatic 14 Jan

awesome. Is this an update to rebalance-lnd or are you writing a new script? Seems that this setup would make rebalance-lnd think that we are making a rate that we might not get. If we set these higher rates and then try to rebalance channels, we could be massively overpaying.

10 sats \ 0 replies \ @C_Otto OP 14 Jan

This is unrelated to rebalance-lnd, it isn't even about rebalancing. But yes, if you rebalance (or, using lnd-manageJ, top-up) these channels, you might end up with lots of expensive liquidity that never moves.

0 sats \ 0 replies \ @nikotsla 14 Jan

I think he has a personal/public software to manage nodes, this seems not related with rebalance-lnd.

0 sats \ 0 replies \ @C_Otto OP 13 Jan

Yeah, I'll have to think about that!

100 sats \ 0 replies \ @C_Otto OP 24 Jan

I hereby declare this experiment a failure. I didn't se as many failed attempts (for high amounts), but I also didn't se any successful forward. As such, I believe the high fee rates are not attractive enough (duh...).

20 sats \ 3 replies \ @C_Otto OP 15 Jan

Short update: it's very quiet on my node. I might be too impatient. Or maybe my channels are too expensive now :)

0 sats \ 2 replies \ @zapomatic 16 Jan

my node has slowed over the weekend as well--but I did not raise my fees super high (except for 2 channels that are sinks). The trouble with the opacity of the network is that we can't know if it's just a slow day in general for the network, or for our particular channels...

10 sats \ 1 reply \ @C_Otto OP 16 Jan

Yesterday was MLK day in the US, so maybe nobody bothered to use the LN. Let's give it a week or so...

0 sats \ 0 replies \ @zapomatic 16 Jan

Some day I think we will have a publication source where node runners upload anonymous stats so we can see general wide angle trends like 24 activity from Germany to Kenya. That would help node runners see where demand is and make decisions about creating new connections, and it would allow us to see if the network as a whole was slow on a prior day, which might help in automating fee adjustments (not changing them if the network as a whole is the reason for the lower throughput).

22 sats \ 1 reply \ @Wumbo 13 Jan freebie

I look forward to hearing your result.

"Low fee channel avoidance" is a term I have never heard before and I agree with you it seems counter-intuitive.

I have personally seen a significant drop in forwards on my node over the past couple months. Which seem odd with on chain fees being significant. I have in-turn lowered the fee recently and now forwarding has become none existence.

I might have to consider "Low fee channel avoidance" an actual dynamic.

10 sats \ 0 replies \ @megaptera 13 Jan

I think there is a lot of rebalancing going on in the ln network. If the om chain fees are high, lesser channels get opened and lesser rebalance is needed. This is what I observed as well but of course cannot prove.

100 sats \ 2 replies \ @C_Otto OP 13 Jan

As a side note, I believe that transaction splitting (MPP) isn't done often enough, yet. I often see failed transactions worth 0.5 BTC or much more. Some of these fail, even though I might have enough liquidity spread over two or three channels.

Using #PickhardtPayments (which cleverly splits (large) transactions into several pieces) seems to be a much better idea, but we're not there, yet.

1 sat \ 1 reply \ @nikotsla 13 Jan

MPP could solve a lot of issues with liquidity, I see much more MPP in CLN nodes than LND.

10 sats \ 0 replies \ @C_Otto OP 13 Jan

Could be because of renepay: https://docs.corelightning.org/reference/lightning-renepay

I implemented #PickhardtPayments in lnd-manageJ, but I understand that using my crude Java voodoo magic isn't as attractive as using an official CLN plugin.

0 sats \ 0 replies \ @thewall 17 Jan

It has been quiet here too. I did get some really nice forwards at high ppm, so I pinned those channels.

I dont signal liquidity with fees or max_htlc, and interestingly I have seen zero failed payments due to lack of local liquidity.

0 sats \ 0 replies \ @chungkingexpress 14 Jan

Pray that I do not raise it any further.

0 sats \ 1 reply \ @fred 14 Jan

The channel is yours, you can do with it whatever you pleased

0 sats \ 0 replies \ @nikotsla 14 Jan

The market at his best!

0 sats \ 0 replies \ @bigrouter 13 Jan

Be careful though, if you have a mixed fee structure (serving both cheap rebalance txs and high priority/time_pref txs) then it's hard for your peers to price you and your volume might suffer.

0 sats \ 0 replies \ @frbitten 13 Jan freebie

All these doubts generated are due to us not being able to identify which channels do not have sufficient balances for our transaction and which do not. Therefore, we need to use other means to try to ensure greater accuracy.

I know that the balance is not disclosed for privacy and security. But can you tell me what risks a node runs when publishing its balances on each channel so that users can be more certain that the transaction will be completed?