Increase channel close delay to 72 blocks #1270
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In lightning#1044, we introduced a 12-blocks delay before considering a channel closed when we see a spending confirmation on-chain. This ensures that if the channel was spliced instead of closed, the channel participants are able to broadcast a new `channel_announcement` to the rest of the network. If this new `channel_announcement` is received by renote nodes before the 12-blocks delay, the channel can keep its history in path finding scoring/reputation, which is important. We then realize that 12 blocks probably wasn't enough to allow this to happen: some implementations default to 8 confirmations before sending `splice_locked`, and allow node operators to increase this value. We thus bump this delay to 72 blocks to allow more time before channels are removed from the local graph.
t-bast
added a commit
to ACINQ/eclair
that referenced
this pull request
Jun 17, 2025
We previously waited for 12 blocks before removing spent channels from our graph: the spec updates this delay to 72 blocks to allow more time for splice announcement in lightning/bolts#1270. We also make this configurable, which can simplify testing and allows nodes to wait even longer if they wish.
t-bast
added a commit
to ACINQ/eclair
that referenced
this pull request
Jun 17, 2025
We previously waited for 12 blocks before removing spent channels from our graph: the spec updates this delay to 72 blocks to allow more time for splice announcement in lightning/bolts#1270. We also make this configurable, which can simplify testing and allows nodes to wait even longer if they wish.
3 tasks
25 tasks
After a channel has been spent, we temporarily keep it in our graph in case it was spent by a splice transaction: however, we must not rebroadcast the corresponding `channel_announcement` to our peers, who may otherwise think we're spamming them with invalid channels. We don't rebroadcast `channel_update`s either in that case, unless they have the `disable` bit set to 1, which indicates that the channel is likely closed.
25 tasks
24 tasks
25 tasks
Roasbeef
reviewed
Aug 11, 2025
07-routing-gossip.md
Outdated
| @@ -228,6 +228,7 @@ The receiving node: | |||
| - SHOULD store this `channel_announcement`. | |||
| - once its funding output has been spent OR reorganized out: | |||
| - SHOULD forget a channel after a 72-block delay. | |||
| - MUST NOT rebroadcast this `channel_announcement` to its peers. | |||
Some implementations don't always check whether channels are spent before relaying gossip, and thus cannot guarantee that they'll only relay unspent channels. We relax the requirements to a `SHOULD NOT` instead of a `MUST NOT` to reflect that.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In #1044, we introduced a 12-blocks delay before considering a channel closed when we see a spending confirmation on-chain. This ensures that if the channel was spliced instead of closed, the channel participants are able to broadcast a new
channel_announcementto the rest of the network. If this newchannel_announcementis received by renote nodes before the 12-blocks delay, the channel can keep its history in path finding scoring/reputation, which is important.We then realize that 12 blocks probably wasn't enough to allow this to happen: some implementations default to 8 confirmations before sending
splice_locked, and allow node operators to increase this value. We thus bump this delay to 72 blocks to allow more time before channels are removed from the local graph.We also add requirements in the 2nd commit to avoid rebroadcasting announcement for spent channels, because our peers may otherwise think we're trying to spam them.