Featured Post

Showing posts with label channels. Show all posts
Showing posts with label channels. Show all posts

Saturday, October 14, 2023

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.

Friday, September 29, 2023

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.