Hello everyone. I’d like to invite you to reflect on the following topic. To put it briefly, I have the impression that there are nodes whose goal is to use other nodes for rebalancing, while they themselves act somewhat like parasites. Now I’ll describe the approximate scheme of how I believe they operate. In short – the picture attached to this post illustrates the idea quite well.
To understand the mechanism that seems parasitic from the perspective of certain nodes, imagine the following.
You are the owner of a node, let’s call it Node A, and your goal is to participate in payment routing honestly. So you launch your node, deposit some bitcoin into it, and open channels, for example, to nodes B, C, D, E, and so on. For simplicity, let’s consider just four nodes with whom we establish channels. After opening these channels, you set your fee on your side, say, 100 ppm. For those unfamiliar, this means that you charge 100 parts per million of the payment amount for forwarding payments to the remote node. These are fees applied to the financial flow from your node to the remote node.
Let’s assume you opened four channels, and for this example, you deposited one million satoshis into each. Thus, your node’s capacity is 4 million satoshis, with four open channels of 1 million satoshis each. Naturally, in this configuration, payments won’t start flowing immediately because you lack inbound liquidity. Let’s say you purchased a channel or made an agreement with someone, and now three channels are opened to you, each with 1 million satoshis. We’ll call these nodes F, G, and H.
As a result, your node now has a capacity of 7 million satoshis: 3 million inbound and 4 million outbound. In this configuration, payments may begin to route through you if your node is attractive to sender wallets that select your node for optimal routing. All your outbound fees are set at 100 ppm, but the sender’s wallet also considers fees on other nodes along the path. Initially, these will be nodes F, G, and H, since their financial flows can be routed through your node at the beginning.
Assuming that nodes F, G, and H charge 200 ppm, then a path segment going from node F to your node A and then to node B, for example, would incur a fee of 200 ppm (F → A) plus 100 ppm from your node (A → B). After a few payments routed from nodes F, G, and H, some liquidity will move into your node in these channels, and some will be passed on to nodes B, C, D, and E. Imagine your node A as having tubes connected to these seven nodes, with containers on each side transferring liquid—similar to a hydraulic system. This analogy helps visualize the overall setup.
Everything seems great and appears to be working. But now let’s imagine the next stage. Say, a node M connects to you and opens a channel. For example, with 10 million satoshis.
Now imagine it quickly sends, say, 3 million satoshis through your node, which are then dispersed via your other channels to remote nodes, draining your liquidity.
Remember that we initially funded Node A with 4 million satoshis and opened four channels. So, through our node, liquidity cannot exceed this amount—we only control 4 million satoshis. Thus, Node M can push at most 4 million satoshis through its channel with us into our other channels. (We’re simplifying by ignoring small fees and reserves here.)
So now, after Node M has opened a channel and sent 3 million satoshis into it, these satoshis have flowed through to the other seven channels. Now, the channel between A and M has 3 million satoshis on our side, and the remaining seven channels collectively hold about 1 million satoshis (since 3 of the original 4 million were “pushed out” by M’s incoming liquidity).
Now consider that Node M has other channels with high fees—say, 1000 ppm.
Imagine a wallet in the network wants to send a payment via the path B → A → M → X. If the channel M → X has a 1000 ppm fee, then the sender must pay 200 ppm to B, 100 ppm to us (A), and 1000 ppm to M. Such a route likely won’t be chosen if cheaper alternatives exist. Our node won’t be selected, not because of our fee, but because M has excessive fees. Moreover, any attempt to use our other channels fails due to lack of liquidity (since it’s now concentrated in the channel with M). That liquidity is “locked”—it cannot easily be redistributed to other channels. To use it, you must go through M, and his high fees make that impractical. That’s when things become unpleasant…
What are the possible solutions?
Rebalancing?
Let’s consider our options. Rebalancing is not economically viable because it would require moving liquidity through M, paying him 1000 ppm, only to reuse it in our other channels at 100 ppm. We’d be operating at a loss.
Close the channel
We could close the channel with Node M, and we wouldn’t lose on closing fees since M initiated the channel and would bear the closing cost. However, it’s time-consuming—we’d have to wait for settlement, then open a new channel. Moreover, if M is aggressive, he could reconnect with even more liquidity and repeat the process.
Raise fees
Another option: raise fees on all our other channels so that nodes like M are discouraged from connecting and draining our liquidity. I’m quite sure the goal of such nodes isn’t to harm per se, but to exploit nodes like ours—with low outbound fees—for rebalancing, so they can earn more from their expensive outbound channels. For example, when Node M pushed 3 million satoshis into our node, it did so through many payments, routed via our channels to B, C, D, E, F, G, H, effectively redistributing liquidity to its own higher-fee channels. Good for M’s business. But not for us. As mentioned earlier, raising our fees harms the Lightning network by forcing us into a corner—pressured by nodes like M—and we contribute to overall fee inflation, which may spiral out of control.
Block inbound channels?
Another approach: prevent others from opening inbound channels, allowing it only via agreements or liquidity marketplaces. From my perspective, this is undesirable—it censors the network and doesn’t contribute to the growth of the Lightning ecosystem.
Conditional channel acceptance
A more nuanced version of the above is to implement an Observer-type algorithm—a script that decides whether to accept a new inbound channel based on certain conditions. For instance, we could check the connecting node’s existing channels and calculate their median outbound fee. If that median is lower or equal to ours (say, ≤100 ppm), we allow the channel. Such nodes would have no economic incentive to rebalance through us, which protects our liquidity.
Injecting fresh liquidity
Another option is to inject more of your own funds and open new channels to reliable peers. But this doesn’t prevent the scenario where Node M opens a new channel and again drains your fresh liquidity into its expensive routes.
What analogies come to mind?
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.
What could Node M do to avoid harming others?
One solution would be for Node M to open new channels to peers where it has depleted liquidity, rather than rebalancing via our node. This way, it maintains connectivity without draining others. The cost might be marginally higher, but not significantly so—especially considering the small fees it pays during rebalancing via us.
Since M chooses not to do this, I can’t help but feel it’s a deliberate strategy to push low-fee nodes like mine out of the Lightning routing market.
Conclusion
I haven’t come up with other solutions yet. If you have any suggestions or ideas, I’d love to hear them. This whole scenario is based on a real situation involving my node. Node M is “c=“. Yesterday, I closed a channel with them and used the liquidity to open a new one with a more efficient peer. Today, they reconnected and opened another channel, once again draining liquidity.
