Instant Bitcoin: My First 30 Days On Lightning

Instant Bitcoin: My First 30 Days On Lightning

This is a journal of my experience with Lightning that will be useful to any newcomers to Bitcoin or Lightning. As a disclaimer, there are many more ways to do things than I have shown here. There are a range of products and solutions for getting started, some more complicated than others. While there are certain standards and best practices for using Bitcoin and Lightning, the only way to get better is to jump in wherever you feel comfortable and learn a lot as you go.

Before diving in, it’s good to have an understanding of the difference between Bitcoin Layer 1 and Lightning, i.e., why Lightning exists, its own trade-offs and special considerations. This post specifically pertains to operating Lightning channels. Effective channel management can be a rabbit hole of its own, but before we can make sense of it, let’s establish some key concepts.

• Read and contribute to the PlebNet resources and discussions.
• Being a node operator will come with an upfront investment but pays dividends in knowledge and experience. Think long term.
• For routing, focus on peer selection, uptime and liquidity management.

Note, you don’t have to be a large routing node in order to enjoy the benefits of using Lightning. Merchants can accept Lightning payments for their business, and as an end user, you can make Lightning fast payments on your own terms, and that alone is reason enough to run a node.

I’m using a Raspberry Pi along with one of the well-known node starter packages. One thing I didn’t know before joining PlebNet was the importance of having an uninterruptible power supply or battery backup — and this is a must for avoiding outages.

My primary Lightning tools thus far have been ThunderHub and Balance of Satoshis (BOS). I was also a complete noob to Linux, and so if you’re at all inclined, I recommend learning the basics of the Linux command line, as it really helps to understand what’s going on under the hood as you click around on a fancy UI.

My first channel was a small one with a capacity of 150,000 sats as I needed to first get on the network graph, and this helped to go through the motions of opening a channel and watching the funds move. My first Lightning payment felt like magic.

I proceeded to open larger channels and was careful to select peers who I trusted — trust in the sense that I took the time to qualify their reputation in the community. My peers have a track record of being honest Bitcoiners as well as competent node runners. Yes, Lightning is designed to be trust-minimized, so you should be able to connect with strangers. However, I want to reduce the chance of costly scenarios and downtime due to poor node management by unvetted peers.

A routing node requires both inbound and outbound liquidity. One way to acquire inbound is by doing what’s called a loop out. In the beginning, I was looping out channels one by one in order to balance the liquidity. I did so at my own cost so as not to inconvenience my channel partner.

I later learned after reading the Voltage series on routing nodes at blog.voltage.cloud that a better way to get started is to open as many outbound channels as you can and loop out multiple channels at the same time. Lightning terminal figures all this out for you. I did a loop of several million sats at once, and I will say that got my heart beating momentarily. In general, I try to move coins around in smaller quantities, that way all your funds aren’t tied up at the same time.

I also used my own Strike wallet to perform loop outs, but since the sats arrive as dollars on the Strike app I suffered exchange fees by having to convert back to bitcoin. In either case, the cost to loop out is still remarkably small — around 20–30 basis points.

Note that I chose to loop out channel funds in order to create a balanced liquidity profile of the node. This service comes at a cost, so going forward I plan to do free liquidity swaps and simply add or remove channels as needed. Looping out is useful in the beginning to bootstrap liquidity but otherwise not necessary to do for every channel. In addition, you can always just purchase inbound channels and avoid the technical details.

I had nine or 10 channels open when I saw my first forward go through and I was ecstatic. I set my fees to be fairly low but enough to potentially recoup channel costs if all the funds were forwarded at one time (see c-otto.de for a more detailed discussion on fees). While my goal is to achieve a low-maintenance node with organic flow, I certainly noticed the forwards were primarily one-way through a small number of routes. This is where rebalancing and fee adjustment matters.

For the first 30 days, the node had 26 forwarding events at an average of 144ppm, and this amounted to 60% of the node’s local liquidity. Earnings were only 1,300 sats — not very much, but hey, it’s satisfying nonetheless.

At a high level, the costs include chain fees, routing fees and Lightning-related service charges, and that’s not to mention the cost of hardware. The cost of chain fees includes not only channel opens/closes but also deposits and withdrawals to the Lightning wallet. The routing fees paid largely came from performing the loop outs, and routing fees can rack up the more sats you have to move. I also made two payments to a few friends from my node which incurred routing fees. I started a spreadsheet to help track expenses in each category. This helps to reconcile the balances that the node is showing on screen. Records indicate I’ve paid around 29,000 sats out of pocket after all the channel opens and loops. Specifically, BOS is telling me I’ve spent around 4,000 sats in chain fees and over 25,000 in routing fees.

It’s hard to be exact because I had to attempt to account for sats eaten up by exchange fees. There was also some initial confusion around commit fees and channel reserves which are funds you own but are not reflected in the available channel balance. It’s vital that you get used to doing accounting in bitcoin terms, although to what order of precision is a personal choice.

Comparatively, I paid a lot more sats to get my channels up and running than I have earned in routing fees. But keep in mind the cost to bootstrap liquidity should be a one-time cost. Not only that, but the funds in a channel can move back and forth endlessly allowing a channel to route many multiples of its capacity over the life of the channel. I would say 25,000 sats was well worth the investment in education.

My goal for next month is to increase node capacity by 20% and see positive net earnings. Looking ahead, these are some more areas of interest:

• Explore batched channel opening and channel funding from cold storage.
• How might using multiple Lightning Network wallets or nodes facilitate liquidity management?
• Experiment with automated channel management tools.
• Improve security, reliability and uptime.

For help, don’t hesitate to ask questions; the plebs and I will be happy to assist!

This is a guest post by Tyler Parks. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.

​​