What You Need To Know About Channel Closures
The biggest source of uncertainty, and sometimes expense, for node runners, are channel closures.
The Lightning protocol protects the recipient of a channel open.
Given NODE A and NODE B above, the costs of closing this channel will be entirely born by NODE A.
This isn't immediately clear to new node runners, and wasn't clear to me when first started, but it's important to understand: The costs of a channel closure are entirely paid by the node that opened the channel.
This is nice, because it means that simply accepting a channel from any node on the network is not a risky endeavor.
Opening a channel, however, does present certain risks, as if you open a channel, you will also (eventually) be paying the channel closure fees, and those fees might vary in a unpredictable manner.
For the rest of this page, we'll be discussing channel closure from the point of view of the channel "opener" -- because the channel "recipient" doesn't have much to worry about.
Always try to time channel closures for when on-chain fees are low
As we discussed Bitcoin on-chain fees are like the weather.
If you want to close a channel, but the fees are really high (like, bad weather), just be patient.
Unless you really need to close the channel immediately, to free up funds, you should wait a few hours (or days) until fees come down.
Best case scenario: Mutual channel closure
A "mutual" channel closure can be initiated by either side of a channel.
For a "mutual" closure to be possible, both nodes must be online, and must be able to communicate with each other.
When you use the lncli closechannel command, LND will automatically attempt a mutual closure.
A mutual closure:
- Allows the channels to ensure that there are no pending HTLCs (Hashed Timelock Contracts) in the channel at the time of closure
- Because there will be no pending HTLCs, the size (in bytes) of the transaction will be reasonably small
- Because the transactions will be small (in bytes), the closing fees should be reasonable.
If possible, never initiate a channel closure when your peer is offline.
LNDG makes it easy to see, at a glance, which of your channel partners is offline.
Go to the main LNDG page, and scroll down. Any inactive peers will be listed in the "Inactive Channels" section:
Don't close these channels while they are inactive.
Not great scenario: Forced channel closure
In some cases, a forced-close will be unavoidable.
The most common case is that your channel partner has gone offline, has been offline for days or weeks, and you don't have much confidence that this partner node well ever come online again.
In this case, you have no choice to force close it.
You also start the process with the lncli closechannel command, and lncli will warn you that your partner is offline and you must attempt a forced close.
When forced-closure can get expensive
Forced closures get additively more expensive when there are pending HTLCs in a channel. The more pending HTLCs, the more data will have to be written to the blockchain, and the more you will have to pay in fees.
LNDG shows you clearly when one of your inactive channels has a pending transaction:
You can see that the final channel in this list has one "Unsettled" transaction. You REALLY want to avoid force-closing this channel, especially during a period of high fees.
The forced-closure horror stories involve a LOT of pending HTLCs
Node runners have publicly complained about instances where channels had HUNDREDS of pending HTLCs, and because a forced closure during times of high fees, the (opening) node runner was forced to pay fees amounting to over $1000 US.
This won't happen to you, because we've already protected you in your lnd.conf
Assuming you've followed my guide, if you look in lnd/PRIVATE/lnd.conf, you will see the following variable set:
default-remote-max-htlcs=10
Read the definition for this variable here.
Setting this to 10 means that no more than 10 concurrent HTLCs will be allowed in this channel at any one time.
This protects you from huge losses during forced close, because no more than this number of HTLCs will have to be written to the blockchain in the case of an unfortunately-timed closure.
I decided on 10, because you really DO want some amount of concurrent payments. But you could choose 5 or 25 for this number, I can't really say with certainty what the optimal number is.
This is an area of ongoing research
The developers working full-time Lightning Network, that is, mostly the development teams behind LND and CLN, persons who are considerably smarter than myself, are well-aware of this problem.
This problem could probably be solved by a tweak to Bitcoin's code, something which may or may not ever happen. But other mitigations might still be found which won't require a change to Bitcoin. Stay tuned.