Increase channel close delay to 72 blocks #1270
Conversation
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.
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.
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.
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.
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.
|
I am not sure if implementations which do not support splicing yet need to implement this delay. You mention it is only important for local scoring/reputation history. Moreover how do the nodes which spliced correlated the new channel_announcement with the old one ? Because the channel_announcment has no trace of the old funding tx ? |
It is important for all implementations to support this, even if they don't support actually creating splice transactions, otherwise they're penalizing implementations that use splicing by removing valid channels from their path-finding graph. Ideally, what all implementations should ship right now is that when you detect a transaction that spends a public channel, instead of considering it closed and removing it from your network graph, you should:
It's as simple as that! This has been eclair's behavior for the past ~6 months already, not sure about other implementations' status. |
Thank you so much for this detailed explanation, we will implement it on LND side, likely in LND 21 because LND 20 is already in its final stages. |
|
Awesome thanks 🙏 |
4 participants
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.