My current understanding of the need for, and functioning of, LN

Limitations of the blockchain:

The Bitcoin (BTC) blockchain, also called "layer 1," is secure but relatively slow.  It can handle about 3 - 7 transactions per second.  By comparison, Visa and MC can handle thousands of transactions per second.  When BTCs layer 1 has many transactions pending, the costs to entice a miner to record your transaction can become expensive.  As I write this, I see that some transactions are costing $12, $17, or even more.  Others, though they might have lower fees, can take hours to process.

"You can't buy a cup of coffee with Bitcoin":

So, the two problems that keep people from buying a cup of coffee with BTC are:  (1) the fee could cost several times more than the purchase and (2) if the fee is lower, your transaction might not clear for tens of minutes or even an hour or more.  To save money, people aren't going to sit in the coffee shop for half an hour waiting on the cheaper transaction to record before the barista gives them their coffee.

So, the common complaint about BTC is that it is a store of value more than a currency to use day-to-day.  "Nobody is going to buy a coffee with Bitcoin" is a common saying.

A potential solution in layer 2, or the Lightning Network:

Lightning Network (LN) offers a solution to both of the numbered problems above.  (1), regarding fees, LN transactions are often fractions of a penny.  (2), regarding speed, LN transactions usually take only a few seconds.  I myself bought a Panda Express gift card using LN.  It was free (because I bought it through my own node) and took about one second between the time I authorized the payment from my phone and the time that the website registered that I had successfully paid for the gift card.

LN also seems to solve the problem with BTC's limited number of transactions per second by allowing this to scale up with the number of nodes and channels on the network.

How Lightning Network works:

At the most basic description, LN is a network or web of nodes and the channels between them.  If I have 1,000,000 sats (0.01 BTC) unused on my node, for example, I can make a channel of that size or two of half that size, and so on.  The creation of that channel is a transaction that must be recorded on the blockchain.  So, the fee and speed limitations are potential problems with only the opening of the channel.

Once the channel is in place, it can remain open indefinitely, processing transactions "off-chain" in its own layer, layer 2, the network of nodes and channels that make up LN.

A good way to a channel is as one row on an abacus.

In the image above, imagine that the abacus represents five channels (red, orange, yellow, green, and blue).  When your node opens a channel, all the beads are on your side of the channel; all the sats are yours.  The on-chain transaction basically tells the blockchain that such a row of beads exists between your node and the other node, the remote or inbound side.

A node ideally has many channels that have the potential to route inbound and outbound traffic.  If each bead above was 100,000 sats, the red and blue channels can route 700,000 sats of payments from your node to the other side.  After such a thing happened, all the beads would be on the remote side, ready to come back to you of a payment were routed from that remote node back to yours.

Similarly, the green channel could route 200,000 sats to your node or 800,000 sats from your node.

In such a manner, any one channel might route millions, tens of millions, or more sats over its lifetime.  Your node earns sats only on forwarding transactions (that is, sending them to the other node from yours).

If both nodes are happy with the channel, each may choose to never close it.

Once a channel is closed, the opener pays the on-chain fee for the blockchain to see the current state of the abacus/channel, record it on the chain, and distribute it to the two nodes.

If the yellow channel were closed, for example, your node would get 500,000 sats, and so would the remote node.  Whoever opened the channel would pay the on-chain fee from those 500,000 sats.

May write more later, but wanted to publish this for now.

Node Operational for One Week

Downloading the BTC blockchain to the node took about three days.  Last weekend, I was able to install and open the app Thunderhub to run my node.  The first step was to send BTC to the node's BTC wallet.  That is the source of BTC that is used to open channels.  The node also has a Lightning wallet address.

I used LightningNetwork.Plus to open most of my 22 current channels.  They have several services, but one is that two others and I form a "liquidity triangle."  A opens a channel to B.  B opens and channel to C, and C opens one back to A.  They are useful to quickly give my node two channels for the price of opening just one.  Also, one of the channels, the one opened to me, is fully funded on the inbound side to give me inbound liquidity.

As I was doing this, I also opened two channels to merchants that sell gift cards for BTC and other crypto.  The hope is that these channels will be "fee farms" as people use them to buy gift cards by routing Lightning payments through my node.

I've had two people open channels to me, unsolicited.  That may be a good sign that my node is showing up on searches as "good," that it is well-connected, or that its name and description are attractive to people.

Regarding channels, I'm finding that evenings in my time zone and weekends tend to have lower on-chain fees.  Because the only way to earn BTC is by a channel forwarding Satoshis, or Sats (*1), the lower the opening cost, the sooner the channel will be in the positive.

Another tactic here seems to focus on larger channels.  If it costs me 1,000 Sats to open a channel and that channel is only 50,000 Sats, it will have to do a lot of work back and forth before it pays for its opening cost.  If it costs the same to open a 5,000,000 channel, it can more quickly pay for itself via its fees.

Going forward, I'm going to set a target of 4 to 5 million Sats for channels I open.

For channels that are opened to me, since they are "free" from my point-of-view, I'll let them be any size.  Also, I might as well keep them open as long as the other person wants them to be open, for they'll only feed me liquidity and increase my routing capacity.

*1 = A Satoshi is 1/100,000,000th of a BTC or 0.00000001 BTC.

Lightning Network Channel Strategies

As I await my Raspberry Pi and other components, I am preparing for opening channels.  Sounds like there are a lot of strategical considerations here.  I'll put the questions roughly in the order I thought about them.

• "How many Satoshis should I put in each channel?"  The range that most podcasts, sites, and videos mention is 500,000 to 1,000,000 Sats (0.005 to 0.01 Bitcoin).  I believe that the idea is to make the on-chain transfer (and its fee) relatively small compared to the funds sent to the channel.  If I open a channel with a size of just 10,000 Sats and the fee to create it is an additional 5,000 Sats, that channel has to earn 50% before it has paid for itself.  Remember, also, that the channel's closing will create an on-chain transfer with another fee.  So, a smaller channel may make no income once you account for the cost of its opening and closure.

• "How many channels should I open?"  There seems to be good return on the first 20 channels.  By that, I mean that each new channel brings your node closer to the center.  After that, the returns--the movement toward the center, toward being a key node--diminish.  It seems that 20 to 40 is a good number to help your node be more central and connected while being enough that a person could still manage them (see bullet point below or a later post).

• "What makes a quality node (yours and one with which to open a channel)?"  There are several factors.  It seems that the two big ones are up time (time the node is running, connected to the network, and ready to do work) and centrality.  Also consider what their fees are, to whom they are connected, channel age, node funding, and channel balance.
• Centrality:  There are different measures of centrality, but it seems to be whether your node is more likely to be chosen to complete transfers.  If I'm only connected to Frank and Sue, and none of us are connected to anyone else, we are entirely useless to the network as a whole.  And, so, I expect our centrality score would be bad.  If I am a potential path between people that want to buy merchandise from a retailer, and I can keep that channel funded well, that may cause my node to have a better centrality score.
• Up time:  A key here is to have your node running and connected as much as you can.  Once the blockchain is downloaded, I am considering getting a mobile hotspot and a back-up power supply (something like this).  The hotspot and the node should not take much energy, so even a smaller backup should keep them both running for many hours during an outage.
• Fees:  You can see the fees that other nodes are charging for their traffic.  Is it very out-of-whack compared to peers?  That might be a red flag.
• A node's connections:  The node that you are considering, to whom is it connected?  I'm still learning the importance of this, but I believe that you are looking for a node that will give you access to areas of the network that are not very connected to you yet.
• A node's channel's ages:  Channels that are lucrative or otherwise helpful (gives one access to new areas or other nodes) are less likely to be closed by the nodes on either side of the channel.  You can find the age of channels that have been opened by the node you are considering.
• Node funding/balance and channel balance:  These are related somewhat.  First, if a node as a whole is funded with only 10,000 Sats, it isn't going to be able to do much on the network.  If you connect to it, it can only route through you transaction(s) less than or equal to 10,000 Sats before it has run out of funds in that direction.  If a node only has a few channels and they're all funded in only one direction, it may not be as helpful as one that has the same number of channels that are better funded in both directions.

• "Are there different 'kinds' of nodes?"  All nodes are basically doing the same thing:  routing Bitcoin through their channels.  However, I read about different channels:
• Heavy outbound new channel:  This can be a "fee-farm."  It could be a channel you open to an online merchandiser who accepts lightning payments.  You'll have to monitor such a channel, for it may be drained of outgoing funds.  If you fund it with 1 million Sats, for example, and that much Bitcoin is routed through you for purchases at that store, then your outgoing funds are empty; that 1 million Sats will be on the merchandiser's side because they received them as payments.  A way to balance this is to increase the fees that your node will take for that channel's traffic.  Increase it a bit to balance income versus traffic.  I have to read more about what to do when the channel is empty on your side.  Some sort of rebalancing?
• Heavy inbound new channel:  This may mean that others think that you have a quality node.  This did not cost you anything to open (the other node opened the channel to you and funded it).  There is really no need to close this, even if it is inactive.  It is just sitting there, for free, waiting to be used.  Speaking of balancing/rebalancing, such a node can be used to rebalance in a way I don't yet fully understand.
• 2-way channel:  This is a great thing to have.  You and the other node are earning Sats through this node, and it is good to keep it going.  A node only earns Sats on outbound traffic, so a 2-way channel is benefitting each of you about half the time.

Other thoughts...  A node's balance might be more important than the balance of specific channels.  That is, a node that overall has 10 channels with only inbound balance and 10 with only outbound balance will have some limitations on what it can route, but it still can do work in both directions, just through different channels.  Don't spend a lot of Sats rebalancing channels when you might not need to.  But, if your node, overall is > 70/30 or < 30/70 as outgoing/incoming ratio, you might need to do some re-balancing.

Analyze a channel during rebalancing.  If I have a channel that goes to Jim who has a channel to Mike, and it is very active; then, maybe I try opening a channel directly to Mike.  I might be able to charge a bit more because what had been two "hops" each with a 5 Sats charge could become one hop with a 7 or 8 Sats charge.  I'd make more, the sender would pay less, and the network would save one hop for each transaction that went that route.

I read something about "zero fee routing" and need to learn more about it.  It almost seems like a loss-leader of sorts.  Your node will get more traffic because the system will see that including it as a hop will be free to the sender.  I'm not sure what you do with this, though.  Maybe analyze what is going through the link and then use that information to decide whether you might open channels to any new or different nodes?

Learning More about Lightning Network

One of the first podcasts I found was very helpful:  this episode of "We Study Billionaires."  The host speaks with Ryan Gentry, who is in business development at Lightning Labs.  So long as you know some of the qualities and rules of Bitcoin, you should be able to get good information from the episode.  It's over an hour long.

A quicker one that was still helpful was this episode of "Upgrade the World."  It is only 10 minutes long and also assumes that you know some basics about Bitcoin.

The third helpful podcast was this 1/2-hour episode of "Who Is Satoshi."

Some of what I learned...  VISA and Mastercard can process thousands of payments per second.  If Bitcoin is ever to be widely used to buy day-to-day things, like lunch, it ought to have that kind of capacity.  But, the Bitcoin network can only process about seven transactions per second.  A reason for this is the limited number of transactions that can be included in each 10-minute block.  In addition to that limited capacity, the cost of each transaction can be relatively high.  To pay for a $8 lunch with Bitcoin, you might incur a $3 fee.  Lastly, I learned that Bitcoin transactions can take many minutes to even hours to be confirmed.  You might pay for your lunch but have to wait at the restaurant for 1/2-hour for the transaction to clear before they'll let you leave the building!

The Bitcoin blockchain is "layer 1," and Lightning Network is "layer 2."  They are interconnected and communicate with each other, but Lightning Network allows for faster and cheaper transactions that can scale up far above seven transactions per second.

My understanding now is that many Lightning Network nodes connect to each other to form that network.  A channel is opened between two nodes and funded with some amount of Bitcoin.  This is a transaction that requires the blockchain, layer 1, and will incur an on-chain fee.  Once the channel is funded, though, it can take part in Lightning transactions that are faster and cheaper.  With only two nodes connected to each other and funded in both directions, they are the only two that can send Bitcoin.  However, the network is now thousands of nodes large.  Many sites have graphic representations of the network,  Here is one.  A screenshot of its state on 9/29/2023 is below.

The podcasts above have nice examples of how the network functions.  Briefly, if my wife and I each have a Lightning Network node, we can open a channel between the two nodes.  It is a payment channel that has an ongoing balance and an incoming balance, from the point-of-view of your node; my outgoing balance is my wife's incoming balance on that channel.

Generally, if I were the one to open the channel, it would only be funded on "my" outgoing side.  Bitcoin could only be sent from my node to hers.  However, once such a transaction occurred, she would have some funds on her side of the channel, her outgoing side and my incoming side.  At that point, transactions can go in either direction, provided there is enough Bitcoin to fulfill the transfer.

To be more specific, if I open the channel between our two nodes and choose to fund it with 1 million Satoshis (0.01 Bitcoins), that transaction will be recorded on the blockchain.  Then, I have 1,000,000 Sats that I can send to her node or through her node.

For that second part, if my wife has a channel to Jane, but I don't, I can send money to Jane through my wife's node.  The only requirements seem to be that some path can be made through the network and that each step has enough outgoing Bitcoin in the channel to complete the transaction.  If my channel to my wife has the 1 million Sats available outgoing, but her channel to Jane has only 50,000, I can only send 50,000 Sats to Jane.

At the start of that example, assume Jane's outgoing to my wife is 0 and my wife's outgoing to me is also 0.  No funds can come to me from Jane or my wife.  However, once I send the 50,000 Sats to Jane through my wife, they each have 50,000 Sats on their side of the channel.

(My 50k went to my wife but stayed in our channel.  They are on "her side" of the channel and now owned by her.  My wife's node then sent 50k to Jane through their channel.  Jane now can see and use the 50k Sats, for they are hers; they are on her side of their channel.)

With many nodes interconnected, the network can find paths for Sats to be sent from one person to another through as many channels as are needed.

Next, I think I'll post about funding and channel strategy.

Making a Node with Raspberry Pi

The first video I found was by Red Beard Engineered.  It is brief, less than 9 minutes, but nicely shows how a person can simply set up a Bitcoin (BTC) Lightning Network (LN) node.

The kit that he bought was a package deal still available on Amazon.  I bought that this week.  The only thing that the package lacks is the hard drive.  It seems cheaper to get an internal drive and a case in which to put it compared to the cost of getting an external drive.

He recommended the 8 GB Raspberry Pi 4 (that package linked above).  He also recommended getting at least a 2 TB drive.  The node will download its own copy of the BTC blockchain (about 500 GB in August of 2023).  Also, the OS and other apps will take up some space.  I decided to get a 4 TB drive so that I would have plenty of space for other apps and for growth of the blockchain.

The OS that he used on his Raspberry Pi was Umbrel.  The process for installing it on the Raspberry Pi looked simple, and he goes over that in the video above, too.  This seemed to be something that I could easily do.

I ordered this drive and this case.  Except for maybe needing a USB cord if it doesn't come with those items, I should have all necessary parts by early next week.  In the meantime, I started listening to podcasts and watching videos about LN.