Monitoring Your Node with LNDG

Your node is now running, and it might feel like it took a lot of learning to get here, but really, you're just at the beginning.

We're now going to look at monitoring your node, using LNDG as our lens.

If you're not using LNDG, you should still be able to follow along wiht this, as any GUI like Ride The Lightning or Thunderhub should provide similar functionality.

Also, along the way, as we review the LNDG interface, we will look at lncli commands that provide the same data as LNDG. It's important to keep in mind that LNDG is just using the LND API, so anything you see on the LNDG interface you can also see on the command line with lncli.

To follow along at this point, you should have opened a channel and sent a first payment.

Basic node information

At the top of the main LNDG page, you see information about your node. Similar info can be found the lncli getinfo command.

Basic info about your node from LNDG

Let's look the important parts of this.

1. change-this-alias ... this area shows your node alias. You should have changed this alias to something else when we set up LNDG. But remember, you can change your alias at any time by modifying the alias= key in lnd.conf, and then restarting your node.

2. Below the alias is your unique node public key, in this case starting with 03477d11175faca273e27dab.... Remember that this key is determined by your wallet seed, and it will never change, unless you destroy and re-create your LND wallet.

3. We have only opened one channel of 5,000,000 Satoshis (0.05 BTC) in size, so our Public Capacity is 5,000,000

4. Peers are other nodes that we are exchanging gossip messages with. It's from these peers that we build our map of the Lightning Network. You don't need to worry about this or try to add more peers: One well-connected peer is enough, and as you add more channels, those channels you add will also be your peers.

5. DB Size is probably not something you will need to worry about. In some cases, like for nodes that are doing constant automated rebalancing, this size can get too big, and then whenever you restart your Node, there can be some short downtime while the database is optimized. The node runners who complain about huge database sizes and slow restarts seem mostly to be operating with low-end hardware, like a raspberry pi with a SD card instead of a hard drive. If you took my recommendation and are using 2TB SSDs and at least an 8x CPU, then you should never need to worry about your database size.

6. At this bottom of this screenshot we see the full node, beginning with 03477.... We learned about this already in understanding your URIs.

Looking at Active Channels

LNDG inbound and outbound channel liquidity

LNDG gets channel information from LND by querying LND's API. You can get the same information on the command line with the command lncli listchannels.

Understanding channel liquidity

The concept of "channel liquidity" can be confusing. I think I can simplify it for you.

You've now opened one channel, and sent one payment through the channel, so we can actually study this channel in its current state to help us understand. Let's take it one step at a time.

1. When you first start your node, you have no channels, and therefore no outbound or inbound liquidity.
2. You opened a channel for 5,000,000 Satoshi.
3. Opening a channel gives you outbound liquidity to the node you have opened a channel with.
4. You sent at a 1,521 Satoshi payment through the channel, and therefore 1,521 Satoshis accumulated on the other side of the channel.
5. The 1,521 Satoshis are now the inbound liquidity of the channel. (Look at the screenshot above again.)
6. More payments from your node to the other node will increase your inbound liquidity, as Satoshis accumulate on the other side.
7. Payments from the other node to your node will increase your outbound liquidity, as Satoshis accumulate on your side.

Why is the total liquidity less than the opening size of the channel?

You see in the screenshot above that LND is reporting 4,994,446 in outbound liquidity and 1,521 in inbound liquidity.

This equals a total liquidity of 4,995,967.

You opened a channel for 5,000,000 Satoshis... so why are there 4,033 missing Satoshis?

This is because of something called the "commit fee", which is an amount that LND holds in reserve to ensure that, if and when you close the channel, you will be able to pay the on-chain fees necessary to write the closing transaction to the blockchain.

Note that the "commit fee" is constantly changing! LND is continually watching Bitcoin's "fee weather", and adjusting the commit fee to match the expected cost of a channel closing.

This means that the actual spendable balance in a lightning channel will continually be changing by small amounts.

Inbound and outbound fee rates

LNDG active channels

The inbound fee rate is set by your channel partner. You can see in the iRate column in the screenshot above that The Megalith Node has set a fee rate of 2,016 PPM for this channel. You can refresh yourself on PPM if you're not sure what that means.

You can't change the inbound fee rate -- that is entirely decided by the node on the other side of the channel.

The outbound fee is charged to other nodes who are routing payments through your node. This is how routing nodes "make money". You can change the outbound fee rate at any time. It's shown in the oRate column in the screenshot above. It is also measured in PPM.

How you should set this fee depends your node purpose.

1. If your purpose is "Mostly Send", then your fee rate might not matter much. Critically, this fee rate is only charged on payments flowing through your node. If you send a payment through this channel, you don't pay the fee. Only "other nodes" pay the fee for utilizing this channel, not you.

2. If your purpose is "Mostly Receive", then this fee also might not matter much, as it is only collected on outbound payments.

3. If your purpose in "Routing Node": Buckle up, because as we'll see in The Gentleman's Guide To Routing Nodes, setting fees is complicated and variable problem that is still an area of active research.

Understanding the channel ID

The designers of the Lightning Network have developed a compact way to uniquely identify channels between nodes. Once you understand how it works, you'll realize it is quite elegant and clever.

In the above screenshot, we see that our node's one channel is identified by the ID 837428x1457x1. To break this down, let's look again at the channel opening transaction.

previous payment hash

At the top of the screenshot, we see a red arrow pointing to block with a height of 837,428.

So the "block height" is the first part of the ID 837428x1457x1.

The next part is the "transaction index", in this case 1457. This isn't shown in block explorers (at least I couldn't find it), but all you need to know is that each transaction in a Bitcoin block has an index number.

The final part of the ID is the "output index": 1.

This is identified in the screenshot above by the red arrow at the center-bottom.

Remember that computer software likes to start counting at 0, unlike humans, who tend to like to start counting at 1.

You can see that this transaction had two outputs:

0. The output for 0.00998460 was the "change" transaction, which went back to LND's internal wallet. This is output 0.
1. The output for 0.05 BTC constitutes the channel balance. This is output 1.

So a channel ID can be considered as:

HEIGHTxINDEXxOUTPUT

In this case:

837428x1457x1

Tracking payments

Scroll down the main LNDG page with your web browser, until you see the "Last 10 payments" section.

LNDG gets information on completed payments from LND's API. You can get the same information on the command line with lncli listpayments.

LNDG's payments list

LNDG shows a list of previous payments that you have made from your node. In this case, we see only one, the donation we sent to the Human Rights Foundation.

Let's drill into this payment by clicking on the Hash with our mouse.

Click on the Hash for details

Payment details

After clicking on the "Hash" value we get to a page which shows us the routing details for this payment.

Complete payment route

This is the complete route from your node, to the Human Rights Foundation's node, identified by the public key 4c8bb62fef2c52252780e4e3a24f9e15dcc203f2b07c872d0eb939f5b9817050.

The payment when through three (3) intermediary nodes on the way to its destination.

1. The first intermediary node was The Megalith Node. This makes sense, because so far, we only have one open channel, and it's with The Megalith Node!
2. No fee was charged in this first hop, because it's your own channel, and therefore, you see 0.0 in the Cost To column.
3. The next hop was to a node named "Sally Acorn". Megalith charged 1,488 PPM for this hop, resulting in a 2.201 Satoshi fee.
4. The next hop was to a node named "IRATEFEED [2-1-0-0]". Sally Acorn charged a 4,376 PPM for this hop, resulting in a fee of 8.822 Satoshis.
5. For the final hop "IRATEFEED [2-1-0-0]" charged a 0 PPM fee, so no additional fees were paid.

But I thought Lightning payments were hidden from the outside world!

You might remember from the lightning is very private section that the outside world can't see the route of lightning payments, and even intermediary nodes have a strictly limited view on a payment's route.

So you might be wondering: "Why can I see the entire route of my payment?"

Well, you should know that the sender of a payment can see the entire route of that payment, and, this is actually how the Lightning network is designed: Lightning payments are "source routed".

With "source routing", the payment-originating node actually builds the payment path entirely on its own, using the "gossip" database it constantly building (and pruning), based on chatter with peer nodes.

Let's check in on our watchtower

In the connect to a watchtower step, we either connected to an existing watchtower, or set up our own from scratch. It's critical that this connection is maintained. Let's look in LNDG to confirm that it's up and running.

Near the top of the interface you will see the "Towers" link. Click on it.

Towers link in LNDG

You should then see your connected towers, like this:

Towers list in LNDG

You can also view your connected towers with the command lncli wtclient towers.