The amount of people who tell me they have force close issues on LND is staggering. Starting to think there is something seriously broken with it. Try CLN, it is a much nicer experience. channels actually stay open! I had some open for years.
Discussion
Adding me and nostr:npub1xcrkgfqejzgqaxle4jhmuyp8g0xpjvsug4yt6ayxw8r7p02j3gjscl60yf as having had force close issues with LND :/
RIP my sats
Lost in the void forever 😆
this note punched me right in my liquidity
#m=image%2Fjpeg&dim=620x552&blurhash=%3BTLfzAxs03aKELIrWBX7s%3AAHR%2B%3FGWV%24*aeozs%3AkCyYRk%3D%5ER*M%7Bt5RkoLkV%7DmxZS2RQJ.W%3Ds%3ANbs%3A-.WERjbbV%40nijYbIbHM%5EWCNbof%251WUoJofR%2BNGkBnismf%2BWWR%2BWVf7NLj%3Fofj%5BWCf6WBoLj%5B&x=545bad914f98a82b4d692030a13c2420e33baf433dc91ce7123b3373741aa317
We also need to consider that CLN users are more technical.
Anyone can run an LND node on Umbrel. Experienced and noobs alike. So you end up with a lot of RasPi nodes runs by noobs like me.
Then I would guess LND dominates the lightning space. I wonder how many there are, but a safe bet is above 60% of nodes.
These metrics add up.
I bet this has a lot to do with it. I’ve run a few different LND nodes over the years and have not experienced many force closures. If you have shitty channel partners, you’re bound to get force closed on.
This was happening so often that I was wondering if LND was doing force closes automatically for some reason
Maybe nostr:npub1e0z776cpe0gllgktjk54fuzv8pdfxmq6smsmh8xd7t8s7n474n9smk0txy knows more about this. I monitor my channel closes with core and walletnotify nostr messages, i just don’t see closes that often on CLN unless they are manually done.
Does LND close channels if the other node is offline for too long or something? Stricter validation checks? Why would this happen?
My raspi node crashes once a month if it doesn't restart correctly best I can do is ask for a forced close to recover my funds
Backups?
That kind of backup is precarious on lightning. Most backups will result in force-closed channels. Recovering channel state is scary due to risk of having not the most recent state and thus triggering a justice TX.
Wen APO
idk, people want CTV + stuff. Everyone pushing for it is trying to thwart anti-spam initiatives though so my social heuristics are screaming at me that it's a bad idea and I haven't figured out why yet.
I guess that puts me in camp APO.
Raspis are fun toys, not enterprise grade machines. The future of money deserves better.
I want to learn how to run a business on LN and utilize the new features but I'm still not comfortable in how it works.
I'd invest in enterprise grade machine if I have back ups and/or watchtowers.
The redundancy of on chain funds makes total sense, but lightning is still confusing. I even made $40 from someone using an old channel state no way I'd risk a lot of my own funds and especially other people's funds on it.
Am I missing something or are all the implementations still sketchy?
Is this is due to the way backups are saved on each implementation?
LND is static channel backups which can only tell your counterparty to close.
While CLN has a way to save the latest state right?
What's the best way to have redundancy and prevent channels closing? CLN and reference a watchtower so you don't get accused of cheating with an old state?
I have both nodes... CLN has less force close by "far".
I want to try CLN, but I'm kinda pot committed with LND now. I can't afford the onchain fees to close current LND channels and re open on a CLN node.
Wish there was a way to swap the backend.
as someone who has tried to push 2 PRs on LND for really elementary things and deep experience with the code of involved developers
the sooner you fund me to refactor and fix BTCD and LND the better
i've been wanting to do it for years, and btcd is bad, but LND is worse
just basic things hit you in the face right as you walk into the door... configurations on both servers don't properly sync with what you put in the files, commandline options don't actually work as documented, the chain sync on btcd is woefully out of date compared to core, as everyone knows, but doesn't know in detail, there was a witness data size limit coded into btcd that wasn't present in other implementations and broke the whole LND lightning node network
i have already proposed numerous changes to both codebases and none of them have been taken into the main branch and the problems they solved persist
i don't want to ever meet roasbeef in person because i probably will want to slap him i dunno about anyone else but there is zero quality to the management of btcd and lnd codebases
have you considered forking and proof your point ?
Most the Force Closures on my node were from a) The other node accepting the channel but then changing minimum channel values that then force close everything under it. b) Node is offline for too long or is not being used so they force close after a certain time of inactivity c) Human error from not understanding commands. Ill be 100% honest and say running a lightning node is a terrible experience on both CLN and LND for different reasons.
No issues for me using LND. Can't remember the last time I had a forced close. Must be 8 months or better.
People who talk about it seem to be surprised that it’s happening. It sounds like LND is doing it automatically without their consent? Thats why I suspected its a bug.
I was a CLN maxi but switched to LND because I need anchor outs...
CLN can easily handle anchor channels. You just add experimental-anchors to the config. They should probably pull back on the "experimental" thing though. It's solid.
Totally. IMO Lightning Labs are in cahoots with miners…
LND definitely has an itchy trigger finger on the force close.
Eclair is also a great option for a lightning implementation.
CLN FTW
The codebase is literal garbage.
Force close with LND happens when there is an open HTLC and one of the nodes go offline for some time. Then in order to clear the transation force closing happens. The problem can be the internet connection or tor, but also some bug in LND that does not deal well with HTLC in some situations.