Thread by @sethforprivacy

1/ Time to share some of my thoughts and experiences from getting this self-sovereign #LightningNetwork stack up and running.

tl;dr - not for the faint of heart/non-tech-savvy, but once configured and up and running it seems to be working quite well for me!

https://twitter.com/sethforprivacy/status/1526749422620745733

2/ For the Bitcoin node, I simply exposed the Dojo bitcoind node's RPC that I already had up, and was able to easily access it across my home's network:

code.samourai.io/dojo/samourai-…

Be sure to write down the ports used here if using a Dojo node externally, as they're non-standard.

3/ First off in the stack is @Core_LN:

github.com/ElementsProjec…

The installation process was solid, and I was able to leverage a modified version of their systemd script to get it to run on boot as a service:

github.com/ElementsProjec…

4/ I created a new, un-privileged user to run the stack as, lightningd, so you'll see that user referenced a lot.

I setup lightningd using the following customized systemd script (the stock one had lots of permissions and configuration flag issues):

paste.sethforprivacy.com/?3f127fe48b926…

5/ And here is my lightningd configuration, but we'll get to some of the things mentioned here later:

paste.sethforprivacy.com/?3e2080ae7cbf5…

Note that this is a Tor-only node, so that's why the addressing is localhost + statictor.

6/ Thankfully much of the process was simplified as I already had a Bitcoin node up and running and already had Tor configured with control port + cookie auth to handle the Tor-only configuration automatically via lightningd.

Started up without a hitch and synced up just fine!

7/ Next up was getting c-lightning-REST up and running:

github.com/Ride-The-Light…

This is a necessary step as @Core_LN does not have full API support yet, so things like @ZeusLN/@RTL_App require an API interface in order to be able to interact with your @Core_LN node.

8/ In theory this was supposed to be as easy as installing node/npm, installing the plugin, and enabling it in the lightningd config -- but that didn't work at all (will raise an issue on this error), as lightningd would crash with the plugin enabled.

9/ I was eventually able to get it up and running via another systemd script (also customized) following the instructions here:

github.com/Ride-The-Light…

My systemd script here:

paste.sethforprivacy.com/?4d1e35885e2ee…

10/ And here is my c-lightning-REST config file (used HTTP as I'm reverse-proxying + SSL via Traefik, domain redacted of course):

paste.sethforprivacy.com/?854b450a9d002…

Once configured this started up without a hitch and started working well!

11/ Next up was @RTL_App, the web front-end I wanted to use for managing the node:

github.com/Ride-The-Light…

Thankfully RTL worked like a charm, connected to c-lightning-REST instantly once configured, and the systemd script was easily modified to work:

paste.sethforprivacy.com/?ddd0e86a925b2…

12/ Next up was CLBOSS, one of the most interesting things to be built in the LN space in some time -- automated channel and liquidity management:

github.com/ZmnSCPxj/clboss

Downloaded, compiled, and installed CLBOSS, then easily enabled with a single line in the lightningd config

13/ Then I just sent in some post-mix (@SamouraiWallet, of course) sats to be used for opening channels and spending, and CLBOSS jumped in right away to start opening channels it viewed as favorable.

I also enabled #ZeroBaseFee for channel opens in CLBOSS.

14/ Last but not least, I found the docs for backing up @Core_LN and enabled the "backup" plugin, syncing a backup of the DB to my NAS (and backed up the HSM secret file as well separately) to ensure I could recover funds/channels in the event of an issue.

Not too painful.

15/ The easiest piece of all of this was @ZeusLN, which connected perfectly to my node via HTTPS and has been working flawlessly since then.

Zeus was one of the first LN wallets I tried a few years ago, and has come a long way w/ *excellent* UX today. Loving it so far.

16/ So now that the stack is up and running, what are my initial thoughts?

THE GOOD:

- RTL "just worked" once configured properly
- Easily proxied through Traefik using existing setup
- CLN easily connected to Dojo node
- CLBOSS is stupid easy to enable/use once built/installed

17/ THE GOOD, CONT.:

- Tor-only is very easy with control port properly setup
- Zeus easily connected to c-lightning-REST once proxied through Traefik
- CLBOSS has managed channels well so far, no in/outbound issues up to this point
- No uptime issues after a few days

18/ THE BAD:

- Lots of issues with the systemd scripts
- Could not use cln-rest plugin for some reason
- Keeping up to date will not be easy, no binaries available
- Backups are *absolutely necessary* but not prominent in docs and not prompted at all when running c-lightning

19/ THE BAD, CONT.:

- The tools all use differing installation methods, no binaries available via package managers etc.

WHAT'S NEEDED:

- Docker Compose or simplified packaging of these tools together (@runcitadel might solve this, have to test)
- More user-friendly docs

20/ So why did I choose to go through all of this? I wanted to get a better picture of the state of LN today, what it's like doing it *properly* in a self-sovereign manner, and what the pain points are.

Using LN custodially is totally uninteresting to me.

21/ Next up will be more thorough testing of payments and a deeper exploration of privacy implications of sending/receiving LN payments.

I'm also planning to open more Github issues for the problems I ran into and contribute simple documentation fixes where I can.

22/ Lastly, this node will be public (which has implications for receiving privacy, I know) and can be found here:

amboss.space/node/0219f7476…

It's currently being used for Podcasting 2.0 payments for @optoutpod and I plan to enable donations to it once BOLT12 is finalized.

23/ If you have any recommendations on things I could have done better, tips and tricks for managing the node moving forward, or just feedback on parts of this stack, I'd love to hear it!

24/ I am by no means an expert, but trying to be sure I fully understand a tech that I've been vocal about the downsides to in the past.

This has helped me learn where LN is at and has gotten me more optimistic than I expected to see some promising developments become reality.

25/25 I'm still very cautious about the ability for LN to strike a privacy/routing balance long-term, but things *have* improved from the self-sovereignty side which is encouraging.

Now is this worth the effort over just using @SamouraiWallet/#Monero? Not sure on that one...

P.S. -- a huge thank you and shoutout to the feedback and recommendations I got in this thread, gave me a *great* starting point for getting what might be the ideal tech stack up and running:

https://twitter.com/sethforprivacy/status/1526405868060819456

P.P.S - For those who don't want to go through this trouble, @runcitadel seems an excellent alternative that can even be run on existing x86_64 hardware, and I would likely just go that route if I did it all again -- but good to do this to get a better understanding of each tool!

P.P.P.S - Also posted to @stacker_news, my absolute favorite place for Bitcoin news/discussion and one of the best use-cases for LN I've seen so far:

stacker.news/items/29933

Huge fan of the approaches being taken with it, post/comment quality is much higher when it costs!