Okay thanks, that is one side of the argument.

Are there any articles from the other side of the argument?

Did your node automatically force close the channels that led to the justice transaction?

I was always under the impression that if you start lnd with a stale state, you are at least safe for a while because the stale channel will just stay offline when the peer returned a higher number. Unless you manually force close them with a stale state, hmm.

Thank you!

Unfortunately, that IS the rational decision for a working class sat-stacker like me.

I run a node. I buy coffee from my local cafe with lightning. I eat force close sweep fees.

But I can't afford to act philanthropically. I'm here to stack sats, not to lose em.

And open yourself to risk of force closures amidst high fee environment? No thanks.

Even having high quality peers can't guarantee not having force closes that costs up to 200k sats in sweep fees, what more offering yourself to be the channel initiator to unreliable noobs.

That is the nature of IP networking. When your public IP changes that means all established incoming connections using the old IP gets terminated.

If everything is running correctly with your dynamic DNS, your bitcoin node will start advertising the new IP and after a while you will get new incoming connections.

No, it affects lnd nodes that uses bitcoind backend as well. The bug is in the transaction parser.

I find LND to be the easiest to set up and get it up running.

If you have little or no experience at all with deploying software on Linux via shell, I can recommend Zap Desktop. Basically it is just LND with a Neutrino back-end but with an easy 'click Next' installation, and can get you up and running lightning in no time.

More likely it was the ‎0.00660000BTC that was transferred and the rest were change.

I wonder what your dad thought about the tone of the book.

Personally, although I hope Bitcoin succeeds, I found the author's tone to be too condescending. I understand wanting to support Austrian Economics, but the vitriol against Keynes was too harsh and repeated too many times over many chapters that I felt like it was the rambling of a loud-mouthed, grumpy old man.

I go the technical route. I take the stance of "If you have any questions about how Bitcoin actually works, I'll be happy to answer them". I don't try to convince people to be on board because I myself am not certain of the future.

I did some digging, it looks like it is a known issue with Umbrel after upgrade 0.5.0.

Glad to hear it!

Yes your extra IPs and domains you provided in tlsextraip and tlsextradomain config entries should appear in the 'SAN' subject in the certificate. If they are not there, your app will not be able to perform the necessary SSL handshake.

You need to investigate why they are not getting picked up by lnd.

I don't use Umbrel so I do not know if they have hidden config files somewhere that overrides your manual lnd.conf entires. Maybe you can check with them Umbrel folks.

A telnet response is always better than a timeout. That means something is responding. But since you say you already did delete the tls.cert beforehand, I'm wondering what else can be wrong.

If you decode the contents of the tls.cert file using https://www.sslchecker.com/certdecoder for instance, do you see all your IPs and domains?

Another way to check if you can connect is, use Zap Wallet to connect to your node. Zap uses the gRPC interface to connect. It might even give you useful error messages if initially you run into trouble connecting.

I think this is the answer. Just restarting won't do the trick though. You need to delete the original tls.cert file before starting it back up again.

I suspect that the networking bit is not the problem. OP mentioned that they can telnet port 10009 from external networks. That means the port is successfully forwarded, it's the app that's not working.

How about sats lost through force closures?

I understand wanting to be philanthropic but setting fees to zero will make the risk of stuck HTLCs to increase significantly.

I agree the amount earned through setting fees might be negligible enough to be 'donated' for the greater good, but the amount lost via force closures actually annoys me to no end. It is one of the top reasons in my opinion that can turn people off of lightning.

VirtualBox is good for beginners to learn about virtualization, but it is not suitable for running your virtual servers 24/7.

If you are on Windows Pro, you can leverage on the built-in Hyper-V hypervisor. Unfortunately this is not available if you only have Windows Home.

If you are willing to move away from Windows, you can try VMWare's ESXi Hypervisor. However, using this method you will lose the ability to use the workstation as a desktop and will have to manage the server from another machine via your network.

I think you have most of it covered. All those factors are important. The most valuable ones are the ones that routes in both directions without our active participation (rebalance), and I guess this is covered by combining your first and second bullet points.

For me, as a small timer, a channel I would consider bad is one where the risk of force closing is high, as the costs of force closes is considerably large for me. Therefore, if I can catch this potential and pre-emptively perform a cooperative close it will be really helpful.

Maybe some factors that can lead to a higher chance of this include: