6 Glossary
This is a collection of definitions and jargon commonly used to talk about the various facets of the Bitcoin Lightning Network dynamics. Many of these words and concepts were coined by various people thinking about, and working on the LN.
Centrality
Centrality is a generic term to describe a node’s or a channel’s position in a (Lightning) network. There are dozens of formulations of centralities that each describe something different, but the most basic metrics we can talk about in the context of the LN are a node’s betweenness, closeness and eigenvector centralities.
Betweenness
Betweeness centrality measures the number of shortest paths that pass through a node. A higher number of shortest paths a node has to any two other node in the network, the more likely they will be included in a route depending on the liquidity balance of each channel in the path.
Closeness
Closeness, or hopness on Amboss, centrality is a measure of how many hops it takes to reach any node on the network from a given node. The better the rank, the fewer the hops required to reach any and all nodes.
Eigenvector
Eigenvector, or hubness on Amboss, centrality measures influence of a given node in the network. Higher ranks imply a well-connected node that is linked to other well-connected nodes. A lower eigenvector centrality could also imply a new and/or underserved node in the network.
Channel balance
Refers to the proportion of outbound and inbound liquidity sitting in a channel. Opening an unsolicited channel to a peer will start off as 100% outbound. A typical liquidity swap like on LightningNetwork+ will start a channel off 50% outbound and 50% inbound.
Effective liquidity balance
Refers to the perceived (not exact!) liquidity available across channels for HTLCs of a particular size, but almost always of 500k sats or less. Inbound and outbound balances closer to 50% indicate that sufficient liquidity is available in either direction to forward a typical payment. An effective inbound (or outbound) balance of 70% or greater usually implies a node is either not properly balanced across channels or is overall inbound-heavy (or outbound-heavy).
HTLC response time
Refers to the time (in seconds) taken by a node to process an HTLC. Faster HTLC response times lead to faster payments. Several factors can affect response time, for example, whether the HTLC is being carried over Tor or clear net (like IPV4/IPV6), geographic distance between nodes forwarding payments, and the hardware on which a node is running.
Liquidity demand
HTLC requests on a given channel, or across a node’s channels, over some time period represents liquidity demand. Higher demand might occur in spurts, in small or large HTLCs sizes for a variety of reasons. Higher demand can be seen as an opportunity to compete in fees. Contrast that with lower demand, which can also occur for a variety of reasons, may also present an opportunity. It could be a mispricing of liquidity, or a liquidity bottleneck due to HTLC failures, or something else.
Liquidity flexibility
Liquidity flexibility is analogous to the notion of power grid flexibility. It measures a node’s capability to maintain a balance between 1) liquidity across channels and 2) HTLC demand (under uncertainty) for that liquidity. The higher the flexibility, ranging from 0-100, the better a node is perceived as capable of responding to HTLC demand for its liquidity across channels.
Liquidity flow rate
Depending on fees, liquidity can move more or less quickly between channels. Nodes with lower average fees will see more volume, whereas nodes with higher fees will see less volume. The fees vs flow rate dynamic can be theoretically modelled like the following:
This model doesn’t account for liquidity value, demand, timing, or other dynamics, but still a useful visual.
Outbound liquidity value
The value of outbound liquidity (i.e., your channel fees) is estimated by analysing the cost of potential payments in your node’s neighborhood as well as to common payment destinations. Sustained volume at high fees imply high outbound value. High volume at relatively lower fees (i.e., lower percentile) suggests a given channel is underpriced, especially if liquidity moves in one direction only. Low volume at high fees suggests that a given channel may be overpriced. However, it may be worth maintaining higher fees at low volume depending on the size of a forwarded HTLC and the inbound & outbound channel pairs that forward the HTLC. Low volume at low fees suggests low demand through that channel. It may be worth considering reallocating liquidity elsewhere if low demand at low fees persists. ## Maximum liquidity flow {-#maxflow}
Maximum flow is the highest amount of sats that can theoretically be pushed through a path if liquidity were 100% outbound. In reality, outbound across a path is likely 50% or less.
Node behaviors and traits
Nodes are not so different from living organisms in an ecosystem. They each have a genetic code that specifies how they’re built, but they can exhibit a range of behaviors when it comes to deploying and moving liquidity around the network, which can also evolve over time.
Liquidity sink
A liquidity sink pulls inbound from other channels more than it pushes. An example of this would be an on-chain swap service.
Liquidity source
A liquidity source pushes inbound to other channels more than it pulls. A wallet node could be a liquidity source.
Ping-pong or bidirectional router
This node pushes approximately as much as it pulls liquidity. Payments can be small and frequent (Nostr zaps), or fewer and further between but larger (liquidity battery). This kind of behavior in the wild is rare but widely sought after in a peer.
Swap routing node
A node that offers on-/off-chain swap services to increase or decrease inbound liquidity. Known services include the Lightning Labs Loop node, and others like deezy.io or ipayblue.com.
Rebalancing strategies
Maintaining a routing node involves managing liquidity between channels, either actively through circular payments, or passively by adjusting fees to encourage liquidity movement. The goal is to manage liquidity in places where it is needed rather than aiming for an arbitrary ratio of outbound to inbound.
Active
This is a fee strategy that involves making a circular payment from one channel to another in order to meet liquidity demands. Usually, a circular repayment will be attempted to push liquidity from an outbound-heavy channel to an inbound-heavy channel. It could also be a circular payment from a peer that is just easier to get cheap outbound pushed to a liquidity sink. Ideally, liquidity is purchased where it can be sold for a profit, but it needn’t be so. Also, it needn’t be mutually exclusive to passive rebalancing.
Passive
This is a fee strategy that attempts to encourage higher liquidity volume and ideally bi-directional volume such that channel balances are passively maintained. The success of this strategy depends on multiple factors, and can often be difficult to achieve. It’s not uncommon for liquidity to get pushed to one side and then never move back, even at a fee of 0ppm. This strategy needn’t be mutually exclusive to active rebalancing.