I see many people that want to "fix Bitcoin" with all kind of mental gymnastic "solutions" that are NOT Bitcoin, but nobody is looking to fix what is obviously not working well: force closing channels.
Right now, Bitcoin and LN works as is supposed to be. It is not a real problem opening channels in high fee environment. You can fix that with batch opening channels and consolidate the fees.
The problem is when you get a force close channel, because on the path you got a shity Tor node, with shity maintenance and your HTLC got stuck on the way, then triggered the force closing. Or whatever other reason for that force closing that can cost you a fortune.
We can transact very well and fairly cheap over LN if we do not have all these crazy force closures in high fee env.
I can live with opening channels in high fee env. Is a cost that node runners could asume it and can be manageable.
But I cannot live with the threat that some day, some payment got stuck for reasons that I cannot control and for that my channel got closed.
Spend and replace works perfectly fine on LN to refill your emptied channels.
Please STOP looking into bullshit solutions and fix the damn force closing channels. Then we will have another 10+ years of smooth adoption, meanwhile we can build more robust solutions for billions.

I agree that force closures are frustrating, and IMO each of these signals a failure of this protocol. I'm willing to bet 99% of the time it is not because a node turned off and stayed off while a payment was being routed. That's the only acceptable reason I have for a force closure. People can say "well what if this, what if that" etc. But it's the protocol that enabled all of the "what ifs". I just care about the fundamental time lock on top of Bitcoin and making sure that's not violated.
The lightning protocol is incredibly complex with a ton of room for bugs that result in force closes and funds "lost" in fees. I think at this stage, there's no fixing that and the only parties that should partake in LN are the entities that accept it as the cost of doing business.
So I'd disagree with the original statement of "stop looking into [alternative] solutions". If you think "just fix force closes bro it's easy bro", then that's an incredibly misguided reaction from someone that doesn't understand LN.
reply
Did you considered to be sincere open and fair and reveal how much you are paid to push fedimint into Mutiny?
reply
Many of my difficulties running a LN node is connecting it over TOR. Any suggestions for ensuring privacy over clear net?
reply
I have never understood this. My Tor middle-node throttles nothing and has 1 Gigabit up and down. When I use Tor it fuckin hangs when loading text-only websites.
Any suggestions for ensuring privacy over clear net?
It's not "ensured" but VPNs are the disappointing second best option with trust only one entity.
reply
One could do a hosted server option (has drawbacks).
Find a server provider that accepts BTC for payment and connect to it via vpn or Tor to do maintenance.
The node it self would get benefit of clear net but you the user can hide behind VPN or Tor
reply
We also have to make running dedicated hardware nodes easy for people!! This is over looked.
We need something people can buy right away with no fuss (no need to install anything) and it is robust, stable, and easy to update. Most all current linux OS are complex to set up and complex to run bitcoind and lnd or cln. This applies to some sovereign node implementations, as well.
That is why I love NixOS as it can be crafted by a tech person, but used easily by a non-tech person. As a vast vast majority of folks will never run any Linux OS, let alone, to serve software system like bitcoind or lnd. They will not know what hardware to use nor the software to download.
That is why I have put my time and energy in trying to create a "set it and forget it" node system. I think this is piece of the puzzle to help fight poor node implementations, unmaintained nodes, etc. It will create a more quality sovereign infrastructure for Bitcoin and Lighting.
reply
Agree strongly. Well said.
We also need to stop dissing Umbrel.
reply
Batching does not solve the problem of paying high fees in a high fee environment. It helps, but not nearly as much as you seem to think.
reply
21 sats \ 0 replies \ @OT 9 Jan
High priority problem IMO
Would you rather lose 100 sats zapping the wrong person, or 500k closing the channel over 100 sats?
reply
21 sats \ 7 replies \ @fm 9 Jan
Bring @DarthCoin back!!
reply
reply
0 sats \ 0 replies \ @fm 9 Jan
Just saw it.. I was away for the holidays as well and noticed he hadnt post since 13.. Guess he woke up today from the celebrations :p
reply
Wanna start a movement? Maybe a manhunt? I'd go with the manhunt.
reply
0 sats \ 3 replies \ @fm 9 Jan
seams he posted 6h ago.. So no manhunt for now.. SN is not the same without him :p
reply
There already was a time that he posted 6 hrs ago, never to be heard of again, look at it as a preemptive measure... :)
reply
0 sats \ 1 reply \ @fm 9 Jan
manhunt it is then :)
reply
PARA BELLUM!!
reply
For Eclair, it was once just some configuration parameters + remote Core node that were causing a series of force closings. Like 5 simultaneously.
So yes, I fully agree. But maybe it is just a protocol flaw so developers of major clients couldnt' converge to reliable solutions.
reply
Is channel closings solvable? What solutions are being worked on? I keep going closer to the idea that Lightning will never be directly for the masses. It works for geeks, those who care about sovereignity, businesses, etc. At the moment, there's too much friction for regular users. Maybe lightning can be the glue that connects many other protocols, which the user doesn't even have to know about.
reply
agreed, each fee spike weaknesses in implementations is made bare
eg: none of them really do fee bumping
linked this in another thread, but looks like the lnd devs have some stuff they're working on in this area: https://groups.google.com/u/1/a/lightning.engineering/g/lnd/c/gz25tikv_3g
IMO we don't need any of this super fancy protocol stuff added to LN until the experience of operating a node is made much smoother, and handling fees better is a big part of that
reply