Dr. Carsten Otto

Carsten Otto

Lightning Network

Channel and Fee Policy

I believe the fee rate can be used to guide payments. Channels that do not have funds which may be used to forward transactions are disabled (lncli updatechanstatus), whereas I apply a fee rate discount to channels which have a lot of funds available on the local side (i.e., funds that may be used to forward transactions).

One strength of the lightning network is that channels can be used in both directions, possibly sending/receiving the channel capacity multiple times over the lifetime of the channel. As such, I apply a fee rate discount for bidirectional peers.

Rule Value / Condition Rationale
Channel size At least 3M sat
= 3,000,000 sat
= 0.03 BTC		 I prefer larger channels because the on-chain transaction fees you need to pay to open channels are independent of channel size. As such, for larger channels the fee rate can be set to lower values. Furthermore, for regular payments larger channels usually have enough funds on the sending side even if the channel is not perfectly balanced (50% of the funds on each side).
Availability Peers need to be online 24/7 If a peer is offline...
  • funds are locked up and cannot be used for anything
  • a channel can only be closed using a unilateral force close transaction, which is more expensive and locks up funds for a while
  • this harms the peer's reputation, further diminishing the usefulness of the channel
Base fee, paid once per transaction 0 msat Base fees complicate route finding (#PickhardtPayments) and higher base fees make microtransactions infeasible.
Low outbound liquidity less than 30,000 sat or 0.1% on my side: channel is disabled My node cannot send useful amounts. In order to avoid failed routing attempts, I disable my side of the channel.

Fee rate, updated every few hours:

With a fee rate of F ppm (ppm = parts per million), it costs X / 1,000,000 * F sat to forward X sat (plus the base fee).
As an example, forwarding 2M sat with a fee rate of 40 ppm costs 2M / 1M * 40 sat = 80 sat (plus the base fee).

Rule Value / Condition Rationale
Manual fee rate set manually I observe the performance of my channels and might configure a different (possibly higher) fee rate based on my experience.
Default, channel initiated by my peer 1,000 ppm This fee rate may be reduced further, see below.
Default, channel initiated by my node at least 1,000 ppm Higher rates help me recoup on-chain fees, especially for channels that never send the funds back. This fee rate may be reduced further, see below.
High outbound liquidity At least 970k sat on my side, and
I recouped any paid fees:
fee rate is reduced by half		 The channel is able to send useful amounts. By reducing the fee rate, I can incentivize other nodes to route through this channel. This is only done after I recouped my on-chain fees (which is only necessary if I opened the channel) to protect against nodes that never send the funds back.
Bidirectional channel My node received enough funds through this channel, and
I recouped my paid fees:
fee rate is reduced by half		 The channel can be used in both directions. By reducing the fee rate, I can incentivize other nodes to route through the channel. This is only done after I recouped my on-chain fees (which is only necessary if I opened the channel) to protect against nodes that never send the funds back.
Idle channel My node did not forward any funds trough the channel for a while: fee rate is reduced The configured fee rate may be too high. By reducing the fee rate, I can incentivize other nodes to route through the channel. This way I can learn which fee rate is more appropriate.

Examples

  • You just opened a channel to my node. The fee rate is set to the default of 1,000 ppm. In addition, my side of the channel is disabled, because there are no funds on my side.
  • For a channel that you opened to my node, the funds are on both sides, but with just a few per cent of the funds on my side. The channel has not been used in the other direction, yet. I set the fee rate to 1,000 ppm.
  • For a channel that you opened to my node, the funds are on both sides, but with 900,000 sat on my side. The channel has not been used in the other direction, yet. I set the fee rate to 500 ppm, because my node already received enough funds via the channel to demonstrate its potential to be used in both directions.
  • For a channel that you opened to my node, at least 970k sat are on my side. I set the fee rate to 250 ppm, because the channel has enough funds to send a lot, and my node already received enough funds via the channel to demonstrate its potential to be used in both directions.
  • I opened a 3M sat channel and paid 2,000 sat for the on-chain transaction to open the channel. I set the fee rate to around 1,333 ppm so that I can pay for the open and close transactions without making a loss, even if the channel is closed after the funds are sent to the remote side (without any back-and-forth). As soon as the channel is used in both directions, or when I earn fees via this channel, I reduce the fee rate accordingly.

Random thoughts about running a routing node

I have been running this node since mid 2018, and in the past couple of years I have learned a thing or two based on my experiences. This text is my attempt to share this knowledge with you. Although it is very easy to set up a node in the lightning network, it is a lot harder to attract incoming channels and forward a satisfactory number of transactions.

Inbound and outbound liquidity

If you want to send funds from your node to any other node in the lightning network, you need to have outbound liquidity. This can easily be achieved by just opening channels to other nodes, so that you can send funds to those nodes. You may also use your directly connected peers to route your funds towards your destination. However, if you want to receive funds, you need to have inbound liquidity.

As inbound liquidity is made out of funds that belong to someone else, you need to convince someone else to open a channel to your node. Additionally, if you send funds to other nodes, these funds become inbound liquidity.

You may ask people to open channels to your node (some people organize via Reddit etc. to create triangles/rings of channels between their nodes). Nowadays, you can also buy liquidity from specific peers (lnbig.com, yalls) or use services like loop to acquire inbound liquidity.

Based on my experience it helps to offer a node that is attractive for others. Given enough time (patience is key!), assuming that your node is stable and has good channels to many good peers, other people will find your node and might be interested in opening channels to it. I believe the criteria listed at terminal.lightning.engineering are helpful in creating an attractive node.

Channel sizes

The lightning network is capable of routing microtransactions for low fees, which is why even a very small channel may be helpful. However, smaller channels still need to be opened (and, eventually, closed) via on-chain transactions. The fees you need to pay for these transactions are not proportional to the channel size. As an example, a transaction opening a 10,000,000 sat channel might cost the same as a transaction opening a 10,000 sat channel.

As the node operator, you usually want to recoup those on-chain fees via forwarding (off-chain) fees. As such, for smaller channels, you might need to forward the funds back and forth multiple times before earning back the on-chain fees you spent for opening the channel. This also means that you would rely on your peer to send the channel funds back to you, or that you would need to pay for rebalance transactions.

For larger channels it might suffice to just send a fraction of the funds, giving you the option to configure a lower fee rate without exposing yourself to financial risk. Additionally, larger channels allow you to route large transactions (earning you lots of fees), which is not possible with smaller channels.

I always enjoy seeing my node forward (lots of) microtransactions, but based on my experience only larger payments help recoup the on-chain fees. Customers of exchanges like Bitfinex tend to send/receive transactions with amounts higher than 1M sat. Each of these transactions brings in a lot of fees, but also requires your node to have a lot of inbound and outbound liquidity.

Forwarding fees

In theory a channel in the lightning network can be used without limit, sending funds back and forth countless times. If you have a channel that behaves like this, over time you will earn enough routing fees to recoup your costs. However, in reality, most channels do not show this perfect behaviour.

Some nodes are known to be liquidity drains, which means that they mostly receive funds. As an example, some merchant may loop out to convert outbound liquidity to inbound liquidity and off-chain funds (so that the merchant can receive more funds off-chain and can cash out on-chain). This process works by sending funds from the merchant to the LOOP node in the lightning network. Although there is also a reverse process called loop in, in practice the LOOP node rarely sends funds.

With drain nodes like LOOP (and others) there is always the risk that the funds are quickly forwarded to the other side of the channel, and then the channel is closed. In this scenario, you only earn fees for forwarding 100% of the funds once, and have to pay both the channel open and channel close transaction on-chain fees. On top of that, you lose inbound liquidity, which might lead to further costs/troubles.

Based on my experience it is a good idea to charge high fees, especially for nodes with unknown behaviour, or those with known drain behaviour. You can always adjust fees if you learn more about how a channel behaves, but raising fees after you already routed your funds to the other side is not helpful. It might be a good idea to have a look at the fee rates other nodes charge to send to some node before you open a channel to that node!

Channel Closes

In a perfect world, you would never have to close a channel as long as you do not need on-chain access to your funds. In reality, there are several situations in which channels are closed.

Both the lightning network specification and the various software implementations are evolving. Nothing is perfect, which is why bugs surface from time to time. Based on my experience there is a very low risk that you lose access to your funds. However, there is a higher risk of channels being closed without it being intentional. This may, for example, happen due to spikes in on-chain fees or programming errors.

Node operators may need to close channel to move the funds to another (new?) node. Node operators may want to close smaller channels, for the reasons outlined above. A channel might not be good enough, making operators want to close the channel and invest the funds elsewhere.

Of course, you should make sure that your peer does not have a bad reputation for closing channels early and often. In addition, even for peers with a good reputation, you should always assume that any channel may be closed sooner than later. As such, make sure that you charge appropriate fees!

Number of forwarded transactions

The lightning network is able to forward several transactions per second (per node!). However, in my experience I have rarely seen more than one transaction per hour on my node. Please do not assume that, once you opened a few channels, your node automatically starts to forward lots of transactions.

More realistically, you might see a few smaller transactions per day, and a larger transaction every couple of days. This, obviously, depends on a lot of factors, including your node's liquidity/reputation/availability, and of course also the users/services at the source and target nodes of the transactions.

With this in mind, you should plan accordingly. Most of your funds will not move most of the time, which is why all associated costs and risks should be offset by those few (larger?) transactions you see over the (short?) lifetime of the channel. If you have outbound liquidity to an exchange, you might need to wait for the market conditions to change so that users want to sell coins on the exchange. As soon as this happens, when you forward their funds to the exchange, you should charge fees that also take into account the risk (your node might be hacked?) and work you invested up front: you paid to open the channel in time, you made sure to attract inbound liquidity, ...

In my experience users are willing to pay seemingly high fee rates, as long as you provide the service they need: near instant transactions to the target of their choice.

Monitoring and tool support

If you run a routing node, you need to understand how the node is doing, and if there is anything that needs to be fixed.

  • Are there routing attempts that failed because you lack outbound liquidity?
  • Are some of your channels inactive, and why?
  • Are there channels that route far less than expected?
  • Was a channel closed, and why?
  • Do you need to rebalance liquidity to enable future forwarding transactions?
There are various tools that help answer at least some of these questions, but you as a node operator need to invest time setting them up and getting comfortable using them.

Aside from any manual monitoring and tweaking, you should also make sure that certain changes are performed automatically. This could, for example, be disabling your side of a channel if you do not have any outbound liquidity, or adjusting the fee rate, or reconnecting to peers with inactive channels.