pull down to refresh

100 sats \ 7 replies \ @south_korea_ln 5 Apr \ on: Liquidity squeezing from your node lightning
The article discusses several solutions at the end, but i agree that they don't seem to address the problem properly.
I like this analogy the author gives, with the additional constraint that, once you are accepting this rich customer (channel) to do business with you, you are enable to charge him more than you'd charge other customers. Indeed, you set the fees to your outbound channels, not your inbound ones.
This whole scenario can be compared to opening a store with cheap products, stocking it up, only to have a rich customer buy everything and resell it in his store at higher prices.
Or, you could say Node M is squeezing you out of the routing and fee market. After their tactics, your node becomes effectively disconnected from the network’s economic flow, while M continues to earn fees via its redistributed liquidity across high-fee channels.
I'm not sure how your solution would work. Is one able to change the outbound fees based on who is the inbound partner? I thought that was a constant value per outbound channel...
Afaict most professional node operators deal with this by using reciprocal tariffs, ie setting their ppm dynamically based on the fee rate of the opener.
write
preview
61 sats \ 1 reply \ @DarthCoin 6 Apr
The big problem that cause this situation is:
  • most of the people are using LN to buy from exchanges like robosats and others supporting LN withdraw. That makes huge liquidity movements from one side to another.
  • then these same users are swaping out from LN into cold wallets. Again a huge liquidity movement on the other side.
This is not a normal use of LN, so the routing nodes MUST find quickly liquidity and make a lot of rebalancing. This will create a snowball of actions forcing one into another node to do the same, like a race who can rebalance quickly.
If LN will be used a just a normal PAYMENT NETWORK (as it is), just to buy groceries and stuff like that, sporadically day to day use, will not be any of these problems.
But Bitcoin and LN will be continuously challenged with such cases and we have to adapt or find solutions, plugins, tools etc.
reply
0 sats \ 0 replies \ @BallLightning 6 Apr
I think even in the ideal world that you see, the situation will be the same. Imagine a works where most people work jobs and get monthly salary and everything is in bitcoin. These people will get their salaries via lightning, they will go to buy some stuff, but they will also save some of the sats. That means that they will still be a liquidity sink for the network. Even in the circlularest of the all circular economies ⭕⭕⭕.
reply
2 sats \ 3 replies \ @k00b OP 5 Apr
I think you can create your own channel acceptance logic and change your fee rates dynamically when your peer does. I might be wrong though.
I just have static fees so I’ve never done this.
reply
205 sats \ 1 reply \ @aftermath 6 Apr
Yes to both.
You can reject or accept channels based on any conditions you want (in LND you can do this with the ChannelAcceptor RPC).
Like I mentioned in the other comment, acceptlnd is quite handy to set this up.
On the fees side, you could theoretically mirror the fees of any node of the network in almost real-time. This can be achieved by subscribing to the channel graph events (in LND, using the SubscribeChannelGraph RPC) and updating your local channels fees based on the updates you see.
To give you another example of dynamic fees, in Hydrus, fee rates are set based on the forwards amount ratio. If the amount of incoming forwards is higher than the outgoing, the fee rate is decreased to incentivize routing. If it is the other way around, the fee rate is increased to disincentivize routing.
reply
0 sats \ 0 replies \ @SimpleStacker 9h
However, one thing you can't do is set higher fees for routing payments coming from a specific channel.
Like a fee map for every i,j, incoming channel i, on outbound channel j, set the fee to c_{ij}
I always wanted to do this because funnily enough when my routing node was connected to Stacker.News, they were the ones liquidity squeezing me! Unintentionally I'm sure, but it happened haha
reply
0 sats \ 0 replies \ @nikotsla 6 Apr
static fee ++
reply
0 sats \ 0 replies \ @south_korea_ln 5 Apr
Unable*
reply