Liquidity squeezing from your node \ stacker news ~lightning

pull down to refresh

Liquidity squeezing from your node fuckedbitcoin.com/2025/04/01/liquidity-squeezing-from-your-node/

644 sats \ 20 comments \ @k00b 5 Apr lightning

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.

Are there any routing operators on here with a solution they like?

view all related items

235 sats \ 2 replies \ @aftermath 6 Apr

I think they are taking advantage of the low on-chain fees to relocate their liquidity and arbitrage with routing fees. They could be probing the victim's channels and detecting that there is liquidity available to do so.

They might have so much of demand from some of their peers that it is profitable to open a new channel and use it purely to rebalance others.

However, I do not think this attack makes economical sense in a different fee environment or to medium-sized nodes, as you would need to open a channel with the almost the same liquidity as the entire node.

As far as the fees goes, they are probably setting a high fee rate to avoid having the liquidity locked in their side of the new channel. Given that the victim node is considerably smaller, this is quite possible.

To overcome this, I think the best approach is to set initial fee rate to something like 500ppm and then gradually lower it as you see the channel is not routing, this will make the operation longer or more expensive, and will give you some sats to relocate your liquidity after the "attack".

Another option, as the post says, is to block incoming channels based on some policies. I have created acceptlnd specifically for this, there are multiple parameters that you can use to decide whether you are happy with the new channel or not.

I don't think it is bad to have a defined set of requirements for accepting new peers, your liquidity and time are limited, so you may not have it with certain peers that you know or consider they won't perform as well based on their metrics.

24 sats \ 1 reply \ @DarthCoin 6 Apr

Acceptlnd plugin is nice. Can you add also the valve system, as described by Rene Pickhardt ? I've tested it in my old guide here and is also a good protection against drainage.

100 sats \ 0 replies \ @aftermath 6 Apr

Can you add also the valve system, as described by Rene Pickhardt ?

Interesting posts!

AcceptLND is just a gate for new incoming channels, it doesn't modify any policies or take any actions of that kind.

However, I have another project called Hydrus that does something similar. I didn't implement the algorithm Rene proposes, but I took a more simplistic approach, which is updating the max HTLC value to 80% the local balance to avoid routing failures and to leave some room until the next update.

I would say higher fees is a better protection against drainage though, the other node could still drain all your liquidity with smaller payments.

155 sats \ 2 replies \ @nikotsla 6 Apr

Just to add more info, this strategy get my attention: https://github.com/zapomatic/zap_lnd_tools?tab=readme-ov-file#cooperative-fee-strategy by @zapomatic

With time you can identify this type of node and act accordingly:

Blacklist
Only open big channels so you can close the channel without losing sats once the liquidity is in the other side (capital intensive).
Set max_htlc so low that the drain take a lot of time an effort

100 sats \ 0 replies \ @zapomatic 7 Apr

Static HTLC max is good. The dynamic HTLC setting has proven to be a bad idea with current tech--as balances in flight mess with liquidity observation--a solvable problem but not one that is currently solved.

Currently, it's better to leave HTLC max static. Using inbound fee discounts and setting fee buckets has proven to be a nice way to not need to manually rebalance and allow flow to be more natural.

212 sats \ 0 replies \ @DarthCoin 6 Apr

Set max_htlc so low that the drain take a lot of time an effort

Yes, that "valve method" by Rene Pickhardt works pretty nice. Also is forcing users to use MPP.

200 sats \ 0 replies \ @endothermicdev 6 Apr

I'm not sure raising the outbound fee of that channel would prevent any of this from happening. It sounds like the node operator should have set fees higher to cover the actual cost of draining their channels' liquidity.

One strategy is to open up large enough (and probably fewer) channels and set the fees such that if they're entirely depleted, opening and closing costs will be recouped. If the channel is depleted, it's done it's job, just open another.

Another is to dynamically adjust fees such that as liquidity becomes more scare in a channel, the fee rate (ppm) goes up. This naturally balances supply and demand. There are many plugins or node managers that will do this in an automated fashion, i.e. CLBoss.

There does seem to be a general equilibrium problem, where you can find the stables effective fees for your channels only to gain a peer (or even just liquidity with an existing peer) who has much greater demand for outbound liquidity and then your channels get saturated/depleted. Again, I think the only viable solutions are to completely automate channel fee management, or to set fees very conservatively.

100 sats \ 8 replies \ @south_korea_ln 5 Apr

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.

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.

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

2 sats \ 4 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.

205 sats \ 2 replies \ @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.

10 sats \ 1 reply \ @SimpleStacker 7 Apr

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

134 sats \ 0 replies \ @aftermath 13 Apr

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.

0 sats \ 0 replies \ @nikotsla 6 Apr

static fee ++

0 sats \ 0 replies \ @south_korea_ln 5 Apr

Unable*

25 sats \ 0 replies \ @odium 6 Apr

There is another "solution", albeit not possible for everyone: get mining rewards via LN. That naturally rebalances/refills your drained channel, and since you jacked up the fee on the channels that get constantly drained (you did, right??) you'll at least earn nice fees next time the malicious nodes drains your channel

0 sats \ 0 replies \ @BallLightning 6 Apr

I don't have a lightning node running, but won't the following strategy work:

Set a fee rate for a new channel that will cover the cost of closing this channel and rebalance the other channels should the other party just drains your liquidity?
After a while if you see payments actual going the other direction, lower the fee rate to an appropriate level and adjust it periodically

0 sats \ 1 reply \ @StackerJack 6 Apr

One thing that hasn’t really been touched on is that, even with all the focus on liquidity and routing, the Lightning Network thrives when everyone starts playing the long game.

Trying to squeeze profits from fees or hopping between channels for short-term gains might work for now, but it won’t scale as well if everyone’s just looking out for themselves like a bunch of assholes.

Real value comes from building a stronger network where liquidity is more evenly distributed, so the system can grow. When you keep focusing on optimizing channels and fees, you miss the bigger picture - helping the whole network grow benefits everyone in the long run.

0 sats \ 0 replies \ @nikotsla 6 Apr

MPP will solve most of this issues, but it is not use too much by wallets, I agree with the rebalance madness, at the end of the day, even with everyone just looking out for themselves it should work.