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?
pull down to refresh
235 sats \ 2 replies \ @aftermath 23h
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.
reply
24 sats \ 1 reply \ @DarthCoin 18h
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.
reply
100 sats \ 0 replies \ @aftermath 12h
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.
reply
155 sats \ 1 reply \ @nikotsla 21h
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
reply
212 sats \ 0 replies \ @DarthCoin 18h
Yes, that "valve method" by Rene Pickhardt works pretty nice. Also is forcing users to use MPP.
reply
100 sats \ 6 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.
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...
reply
61 sats \ 1 reply \ @DarthCoin 17h
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 10h
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 \ 2 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 \ 0 replies \ @aftermath 23h
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 \ @nikotsla 21h
static fee ++
reply
0 sats \ 0 replies \ @south_korea_ln 5 Apr
Unable*
reply
200 sats \ 0 replies \ @endothermicdev 23h
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.
reply
25 sats \ 0 replies \ @odium 17h
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
reply
0 sats \ 1 reply \ @StackerJack 16h
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.
reply
0 sats \ 0 replies \ @nikotsla 15h
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.
reply
0 sats \ 0 replies \ @BallLightning 10h
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
reply