pull down to refresh
100 sats \ 8 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.
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...
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
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
reply
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).
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
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
Well, you could theoretically set positive inbound fees in that channel to disincentivize routing (in LND, enabling the experimental configuration accept-positive-inbound-fees).
However, this seems to be causing some issues because peers that do not support inbound fees may be unaware of the added cost and will therefore fail to route through that channel without ever noticing why.
Another thing you could do is use the HtlcInterceptor RPC to intercept the HTLC and let it through only if you are happy with the fees you will earn from the outgoing channel.
reply
Unable*
reply