Adventures in Running a Bitcoin Lightning Node — Part 1: The Awakening…

10 min readMay 13, 2022

Photo by Nick Owuor (astro.nic.visuals) on Unsplash

Running a Bitcoin Lightning Node... I am flirting with this idea since 2019 but discarded it for various reasons multiple times. Until End of March 2022, when the lightning strike finally caught me!

In the following article (and potentially more to come), I want to share learning’s, insights and experiences. And belief me what I can tell you after the first couple of weeks: operating a lightning node is another whole new rabbit hole!

But first things first: a couple of disclaimers

These are all my personal views!
This is absolutely no investment advice! Do your own research and only invest what you can effort to lose in lightning! This technology is still in early days and experimental.
I assume you have a basic understanding of Bitcoin and the Lightning network. There is plenty of good material out there. Research it!
There is a multitude of different objectives to operate a lightning node and depending on the goal, certain facets might be more interesting than others. Bare that in mind during reading.

Five reasons why I decided to mess around with a lightning node?

The Lightning network as second layer technology on top of Bitcoin fascinates me from day one: the potentials to improve scalability & privacy, the elegant game theory behind payment channels and the emerging effects of a network of payment channels. All ingredients for a magic soup, a math, optimization & payments nerd longs for!
The research paper Optimally Reliable & Cheap Payment Flows on the Lightning Network by Rene Pickhardt and Stefan Richter showed me that solving challenging network flow problems can lead to more reliable payments and motivated me to better understand payment flows on the lightning network.
Having a somewhat good crasp of the theory behind lightning, until up to a few weeks ago, I followed the actual realization in code and implementation very loosely. Following and engaging in the discussions on lightning dev mailing list showed me, that I barely understood lightning in practice. That needed to be changed!
I am a huge fan of the Raspberry Pi and play around and operate them since many years and for various use cases. Running a lightning node on it seems a perfect fit! And having a Raspiblitz on a web shop shelf only a few clicks away, was just to tempting…
And finally, of course…I am also curious to find out whether running a lightning node can be profitable (at least after hardware costs, electricity, learning and maintenance hours).

OK, enough intro…lets get to the nitty gritty!

1. Installation

It went much smoother than I thought and was a matter of a couple of hours! Yeah ok, I already had some experience with Pis and with a Raspiblitz the setup is an absolutely easy one, especially because the hardware is ready to go and the SDD came with a presynced blockchain (otherwise plan with days/weeks to sync up…).

The installation went pretty much along the line of the official Raspiblitz guidelines. For German speakers I also strongly recommend the following two Raspiblitz setup videos (part 1 and 2):

The usual but important reminder: Make sure to store the seed phrase of the lightning wallet and the passwords for administrating your lightning node and Raspberry Pi securely!

2. Configuration

Configuring is rather straight forward and also a matter of a few hours. It took me some time to get acquainted with the Raspiblitz menu and available options. The essential components are:

The bitcoin node: does not need specific configurations, the default settings should work fine.
The lightning node: running with the lightning network daemon lnd definitely deserves some attention and configuration. Defining your alias, maybe redefining the color of your node, setting default fee settings, etc is all done in the file /mnt/hdd/lnd/lnd.conf
Tor: Very handy if you do not have a static IP address where your lightning node is reachable. Also, good advice in general for OpSec. Did not do any custom settings, just rolled with the defaults.

Raspiblitz comes with a bunch of useful tools that can be installed additionally and are worth exploring and will become essential later:

ThunderHub: This app became my favorite management and monitoring tool for my lightning node. Especially for observing channel states, manage channel fees manually and for analyzing routed forwards and earned sats. Only annoying thing: it does only show Short Channel IDs, at least I did not find a way yet to show full Channel IDs (need for another rebalancing tool below).
Ride the Lightning (RTL): Another useful app for managing and monitoring but feels more clunky compared to ThunderHub. But there you can find full Channel IDs.
Mempool: A bitcoin explorer directly attached to your Bitcoin full node! Very handy to observe on-chain transaction fees for funding transactions of new lightning channels without relying on an external source on the internet.
Balance of Satoshis (BOS): Very useful command-line too manage lnd and rebalance your channels. Also very useful for opening a dual-funded channel with another node (not yet tried).
And before you kick-start, of course, make sure to backup your channels and secure your liquidity deployed to them! A very nice feature of the Raspiblitz is that you can activate automatic encrypted LND StaticChannelBackup on a nextcloud, it will secure your channel.backup of lnd, which is needed beside your seed phrase to recover your funds of your channels. As I have a nextcloud running on another Raspberry Pi, this configuration was a breeze!

3. Baby steps with the new-borne node and the first channels

So, now it gets really interesting. I originally thought installation and configuration will be the heavy lift, but I was totally wrong! Once I was done with the installation and configuration setup, I realized, I had no real clue how to bootstrap my lightning node and bring it to my desired purpose: to route lightning payments!

Now I did a step that I regret in hindsight: I discovered the lnd autopilot feature and activated it without properly checking relevant configuration parameters for it within lnd.conf. It immediately took action and opened up a few large channels that allocated a significant portion of my available outbound liquidity. So, I advice you to check the configuration of autopilot properly first, before playing around with it! I intend to revisit that feature later, but for now I discarded it.

After that I opened up some channels to nodes of individuals and businesses that I support and I wanted to transact with. However, nothing happened after that for 2–3 days and I realized a rather obvious learning but whose significance you only experience in practice: without any inbound liquidity (or you paying via it) nothing ever will happen on your channels!

Ok, now it was time to do more detailed research on how to bring a lightning node into action!

4. Explore the lightning universe for inbound liquidity and how to interconnect

My research then first concentrated on how to establish channels, but I realized that there is a whole universe of tools and methods out there to structure the chaos and orient yourself. I was totally blank and blown away what is already out there:

First, I stumbled over Y’alls and that you can listen to some of the essential gossip signals that happens in the lightning universe.
Next I came across Lightning Terminal and used that as an orientation point of where center of the universe is, what kind of metrics are used to measure that, and where my node was located (far in the outer edge of the universe without any classification)
I observed the network visually with graphical rendering of LnRouter
And learned that there are awesome tools to get insights on your or other nodes: Amboss Space and 1ML.
And yes: a large variety of methods to get inbound liquidity:

Ask someone of your lightning community to connect
Buy something with your sats via your channels to transform outbound into inbound liquidity
Open channels to nodes that open channel back.
Buy channels and inbound liquidity from various sources: LNBig, Yalls, Amboss Magma etc…
Participate in circular channel setups with other nodes (triangular or larger “rings” e.g. A->B->C->A) on Lightning Network+ and Rings Of Fire communities. I really liked this idea to get inbound liquidity and get the “doubled” capacity.
Dual-fund channels with other nodes (also “doubles” the capacity of your node)

I tried most of that means above and with the newly collected knowledge assembled first strategies to establish meaningful interconnections:

Use Lightning Terminal and Amboss Space to identify whether a node is good node and of sink-/source-/router-type.
Use LNnodeinsight and its channel simulator to figure out whether the node is a good fit to your node.

5. Stay balanced

Again, one of the most important lessons with routing, channel balance and fee earnings for me were (and literally think of your sats being Homer’s donuts on a pendulum above):

You only earn sats for outgoing forwards!
So, for outgoing forwards you need to have enough sats liquidity on your side of the outgoing channel, and
enough liquidity on your peer’s side of the incoming channel.
Hence, to route payments in any possible direction, liquidity needs to be adequately balanced between the channel sides, e.g. 50:50.

Now given some time after the first channels are established (be patient!), first routings/forwards will eventually happen. Amazing moment when you get notified about your first forward within ThunderHub!

But latest then, a strategy to balance your channels needs to be developed. When you have developed an idea how your individual channels behave, how active they are and what the fee strategies of your peers are, a rebalancing tool like rebalance-lnd is a good way to balance your channels without paying for something but just paying back to yourself (minus transaction fee).

Carsten Otto (who operates one of top ten routing nodes) has developed rebalance-lnd, a sophisticated Python script to rebalance lightning channels that also considers the economic trade-off of a rebalance into account. It allows you to rebalance one of your channels A with high outbound liquidity to one of your channels B with high inbound liquidity and makes sure that it only executes the rebalance when you can expect a future net profit (meaning additional outbound liquidity on B when forwarded in the future earns more than the subtracted outbound liquidity on A minus transaction fees for the rebalance!). Be careful: this assumes that your set fees on the channels that you rebalance is realistic and you will not change them in the future, otherwise your rebalance can also cause you some loss.

After learning to use the rebalance script manually, you can easily automate its execution by defining a cronjob. Be careful: sometimes a rebalance tries a multitude of potential routes (in my case up to 200) which can take some time. So, apply the script automation with caution and not more than once a day for example!

6. What to charge for?

For your channels, you can charge the following:

You set the base fee for a transaction, independent of the amount of the forward. Usual base fees are 0–3 sats.
You set a proportional fee in ppm meaning parts per million. Usual is a zero fee up to 1000ppm. 1000 ppm means that for a transaction amount of 1 million satoshi, you would charge 1000 sats, i.e. 0.1%.

You can set the fees with lnd , in RTL or ThunderHub manually. Depending on how you intend to charge for your channels, that is totally enough.

However, if you want to adapt your fees depending on the channel balance, a tool like charge-lnd is very handy and that can be automated again. It allows you to define sophisticated channel fee policies depending on a variety of criteria.

I started off with a very simple policy for every channel, that proportionally charge depending on the channel balance and refined the strategy for specific channels when I got more insights in the channels behavior.

Caution: Your strategies of charge-lnd and of rebalance-lnd need to be aligned, otherwise you deteriorate the effectiveness of those tools and spoil the net profit feature of rebalance-lnd!

7. Side challenge accepted: Never loose power with an UPS!

When you run a routing node at best you are online 24/7 to forward lightning payments! That means your power supply should be as well. Especially when you run your node on a Raspberry Pi, who doesn’t like power interruptions very much. I experienced SD card failures with Pis in the past, so when “Sats are on the line”, I decided to play save and get my node hooked up to some uninterruptible power supply (UPS).

I can totally recommend the following video (in German), it guides you through all necessary steps:

8. And patience!!!

Now I try to practice patience and let the node evolve … and believe me this is another big challenge for me!

Conclusion

After the first couple of weeks, I can conclude the following:

Getting a lightning node up and running is easy. I overestimated the complexity there.
Getting the lightning node bootstrapped to really act as routing node in the network should not be underestimated. Define your intended potential strategy, research the strategy of successful routing nodes and plan it upfront. Align the tools you want to apply and that support your goals.
Lightning payments are fast but operating a lightning node needs a lot of observations & patience.
And don’t except real profitability when done in “hobby mode” as I did it so far: In the weeks so far, I routed about 30 million sats, earned back about 6% of the invested commitment fees of my 20 initiated channels. Given the current average channel age of 315.8 days, I am pretty confident that I will earn the channel initiation fees back, but real profit is not yet on the horizon.

Hope you got some insights from my experiences. Ping me if you have any questions!

Not enough??? Then directly read the follow-up article Adventures in Running a Bitcoin Lightning Node — Part 2: Growing up…