Lightning Node Management - Handling High On-Chain Fees

May 22, 2023

As Bitcoin adoption increases, demand for block space will also rise, inevitably resulting in higher on-chain fees. In this scenario, users will lean more toward Lightning Network for small payments. But this also means that Lightning nodes must pay more when doing on-chain activity. Regardless of what you're using lightning for, it's a good idea to not only prepare for such a scenario but also know how to mitigate the impacts when such events happen.

This piece will help you navigate high-fee events with your Lightning node from the perspective of a routing node. These nodes are naturally more active than the regular sender and receivers they are more exposed to potential loss with on-chain fees. But most of the advice provided here is also useful for sovereign users and merchants running their Lightning Node.

All commands and parameters mentioned are for LND nodes. If you run a different implementation, you should search the documentation for analogous commands.

Be safe, not sorry.

Here’s what you can do before on-chain fees increase. Ensure you don’t wait until D-Day to take action and take advantage of low on-chain fees to prepare yourself.

Increase revenue

Increasing your revenue stream means you’ll have more margin for any on-chain expenses. You can sell liquidity using tools such as Lightning Pool or Magma if you have liquidity. Also, ensure your node is reliable for others to use so you’re a good routing candidate. This will help you route more payments and increase fee revenue. You can start by following Nate’s tips on his walkthrough on how to build a lightning node for routing.

Run the numbers

All the extra work needed to have a reliable routing node is useless if you don’t keep track of the cost and revenues of your operation. Data allows you to make informed decisions on the fees you can pay while still being profitable if you need to make an on-chain transaction. Tools such as Surge can help you with that.

Use Anchor outputs channels whenever possible

Every transaction off-chain is a valid, signed unpublished Bitcoin transaction called a “commitment transaction”. These transactions can be broadcast on-chain if one party decides to close the channel unilaterally. This is known as a “force close” transaction.

Since the broadcast of a commitment transaction can occur at any point, it’s impossible to estimate how much fee the transaction should pay accurately. If you pay a too-low fee rate, the commitment transaction may not get confirmed in time. As a result, any timelocks inside it could expire, and funds can be stolen.

This is where anchor outputs can help. These outputs can be attached to commitment transactions to allow either channel participant to bump the transaction fee. You should consider opening anchor output channels whenever possible.

In LND, check that protocol.no-anchors is not enabled on your configuration file. This will force all of your lightning channels to be anchor output channels. Without this channel type, you cannot increase the fee of a force close. But remember that LND will require 1 UTXO to be reserved for every anchor channel.

Mitigation

Here is what you can do while on-chain fees are high. There’s a great variety of options available in the node runner toolkit, but remember, if you also prepare for such events with the tips mentioned in the last section, your options will be even broader.

Bump fee

If you run LND, you can use the bumpfee command to increase the fee of an arbitrary input or transaction. It would be best to use this in case you need to increase fees for a force close. It can also be used to bump fees for any other transaction in the wallet. The first fee bump will use Child-Pays-For-Parent (CPFP), and subsequent calls will use Replace-By-Fee (RBF).

Consider that this command doesn’t do effective ancestor fee rate calculation as of the moment of writing, but the LND team is actively working to add this feature. You can follow the progress here.

Update routing policy

Consider a more conservative approach to your routing policy. You want to avoid on-chain costs, so it makes sense to be pickier on what you’ll route to decrease the chance of channel closes.

One way of doing that is increasing min_htlc_mstat, which is the value for the smallest HTLC your node will route. You should also consider increasing time_lock_delta, a “expiry” date for a lightning payment. Increasing this value gives more time for a payment to be confirmed.

Finally, you can increase your fee policy with the fee_rate and base_fee parameters. This can help to offset any potential on-chain cost.

Take Advantage of Anchor Outputs

If you have anchor channel outputs, you can increase max-commit-fee-anchors, the maximum fee rate in sat/vByte that will be used for anchor channel commitments. The default value is 10 sat/vByte, so adjust this to ensure that any potential force close gets propagated on-chain.

Update block confirmation target

When cooperatively closing a channel peers will negotiate the target number of blocks for confirming the cooperative close transaction. You can increase coop-close-targe-confs on your node configuration file to pay fewer fees on the close. The bump fee command can also increase the fee if necessary.

Update fee rate for justice transactions

If you happen to be connected to watchtowers and an old commitment transaction is published on-chain while your node is offline, the watchtower can apply the justice transaction to sweep the channel's funds. The fee rate for this transaction can be set with wtclient.sweep-fee-rate config.

Limit the maximum number of pending HTLCs

The cost of a force-close transaction is highly influenced by the number of concurrent HTLCs the remote party can add to the commitment. The maximum possible value is 483 which can result in a transaction of about 15,000 vBytes. A 500 sat/vByte fee means 7,500,000 satoshis for one transaction. Fortunately, you can configure the maximum number of pending HTLCs with the default-remote-max-htlcs parameter.

Don’t let transactions drop out of the mempool

When there are many unconfirmed transactions, nodes will start purging old and low-fee transactions out of their mempool. Keep an eye on the purge value and rebroadcast any purge transaction. It’s also good to continually broadcast on chain transactions in this kind of scenario, LND, for example does that by default since v0.16.2.

Concluding

By taking proactive measures and staying informed, Lightning node operators and users can handle high on-chain fees more effectively. Let’s summarize what we’ve learned:

Before High On-Chain Fees:
- Increase revenue through liquidity sales and being a reliable routing node.
- Track costs and revenues to make informed decisions.
- Use anchor output channels for better fee control.
During High On-Chain Fees:
- Utilize the bumpfee command to increase fees for force close and other transactions.
- Adjust routing policies to be more conservative and decrease on-chain costs.
- Leverage anchor outputs and adjust max-commit-fee-anchors for fee adjustments.
- Update block confirmation targets for on-chain transactions and fee rates for watchtower justice transactions.
- Limit the number of pending HTLCs to reduce force close costs.
- Monitor the mempool and rebroadcast transactions to prevent them from dropping out.