Apendix A: liquidity draining channelsApendix A: liquidity draining channels

It happened to many of us, specially at the begining of setting up a node, that we connect to liquidity draining nodes. These are nodes that suck all the liquidity you throw at them and never return it, or return it very vaguely, to then, in a few moments later, suck it again. These are channels usually related to services in which the managers do not take their time and efforts on rebalancing their channels because they are always getting new channels coming in, and don't feel any need to return the favor to the smaller nodes that are providing liquidity for free (or almost free). This is very unfortunate, and I think we should punish them.

Typical nodes in that situation in 2025 are Kraken, lnbig, bfx (bitfinex), ACINQ, coingate, etc. Some contact of me, which has this problem, has found that he is unable to properly route because of this and sent me an screenshot of his channels. Take a look at the list:

You can see, the problem is that all the liquidity are in normal channels, while most of the draining nodes are sucking it and never return it. So all his inbound channels are draining nodes, and all his good nodes are just stuck because the don't have proper inbound pairs. So, even if he may have a near 100% ratio (not the case now, but he may), he can't route because he has too many draining channels that never return liquidity.

To avoid this, it is better to just not connect to those known draining nodes, which is a form of punishment to them. Another solution is to configure charge-lnd so for those channels there is always high fees.

For example:

[known-one-way-drains]
node.id = 033d8656219478701227199cbd6f670335c8d408a92ae88b962c49d4dc0e83e025,
  03cde60a6323f7122d5178255766e38114b4722ede08f7c9e0c5df9b912cc201d6,
  021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d,
  03037dc08e9ac63b82581f79b662a4d0ceca8a8ca162b1af3551595b8f2d97b70a,
  030c3f19d742ca294a55c00376b3b355c3c90d61c6b6b39554dbc7ac19b141c14f,
  03d607f3e69fd032524a867b288216bfab263b6eaee4e07783799a6fe69bb84fac,
  02a04446caa81636d60d63b066f2814cbd3a6b5c258e3172cbdded7a16e2cfff4c,
02f1a8c87607f415c8f22c00593002775941dea48869ce23096af27b0cfdcc0b69,
0242a4ae0c5bef18048fbecf995094b74bfb0f7391418d71ed394784373f41e4f3

strategy = static
fee_ppm = 3500

Just substitute the fee for whatever you consider necessary, and the node ids for those that you know they are going to drain you. The list in the example is not exahustive, you may add the many nodes that LNBig has, and many others. In my experience, WalletOfSatoshi is doing well, TempleOfSats also doing well, so this is not a problem of being a service that always drains not matter what, there are services that demonstrate they can properly manage a node without draining their peers like hell!

But if you already have this problem, your only solution is to go to Lightning Plus and do as many swaps as possible to get inbound liquidity, and, at the same time, use boltz.exchange and/or LOOP to try to get as much inbound as possible, until you get a ratio close to 100% not including those draining channels.

Apendix B: how to obtain a public ipv4 clearnet address on a residential connectionApendix B: how to obtain a public ipv4 clearnet address on a residential connection

This is something that so many people has asked me over the years that I'm forced to do a mini guide here. There are many possible solutions, and if you do a search about it you will find many ways. One way that I know works perfectly is as follow:

• Step 1: rent a cheap VPS with a clearnet ipv4 address. You can find many for only $2 a month.
• Step 2: Configure access to ssh using keys, not requiring the introduction of a password to connect to it: https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server
• Step 3: Open ports in the VPS. If you have ufw, just execute ufw allow 9735. If you want rest access, also ufw allow 8080, or whatever port you use.
• Step 4: install autossh cli program on both your node and the VPS: apt install autossh.
• Step 5: create a systemd service under /etc/systemd/system/node-autossh.service with a similar content like this, please ensure you write a proper ExecPath line appropriate for your node, and your User:

[Unit]
Description=Autossh service
After=network-online.target

[Service]
User=javier
Type=simple
RestartSec=30
Environment=AUTOSSH_POLL=60
Restart=on-failure
ExecStart=/usr/bin/autossh -M 22000 -N -D 1080 -R MY_VPS_IP:9735:localhost:9735   root@MY_VPS_IP

[Install]
WantedBy=multi-user.target

Note: if you run lnd under docker, you will have to put your lnd container ip instead of localhost. Now enable it by running systemctl daemon-reload && systemctl enable node-autossh && systemctl start node-autossh.

• Step 6: configure your lnd.conf adding this:

externalip=MY_VPS_IP:9735
tor.skip-proxy-for-clearnet-targets=true

And that should work. You can route as many ports as you want just adding another -R option to autossh.

Hope it helps!!