Skip to content

Increase channel close delay to 72 blocks #1270

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Increase channel close delay to 72 blocks #1270

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
bd17c49
Increase channel close delay to 72 blocks
t-bast Jun 17, 2025
b8ad1c2
Add requirements to avoid rebroadcasting spent channels
t-bast Jul 1, 2025
5dc8db0
Relax requirements to avoid rebroadcasting spent channels
t-bast Aug 12, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 9 additions & 3 deletions 07-routing-gossip.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SHOULD NOT?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 5dc8db0


### Rationale

Expand Down Expand Up @@ -485,7 +486,7 @@ The origin node:
signal a channel's temporary unavailability (e.g. due to a loss of
connectivity) OR permanent unavailability (e.g. prior to an on-chain
settlement).
- MAY sent a subsequent `channel_update` with the `disable` bit set to 0 to
- MAY send a subsequent `channel_update` with the `disable` bit set to 0 to
re-enable the channel.
- MUST set `timestamp` to greater than 0, AND to greater than any
previously-sent `channel_update` for this `short_channel_id`.
Expand All @@ -504,10 +505,13 @@ The origin node:
- SHOULD keep accepting the previous channel parameters for 10 minutes

The receiving node:
- if the `short_channel_id` does NOT match a previous `channel_announcement`,
OR if the channel has been closed in the meantime:
- if the `short_channel_id` does NOT match a previous `channel_announcement`:
- MUST ignore `channel_update`s that do NOT correspond to one of its own
channels.
- if the channel output has been spent:
- MUST ignore `channel_update`s, unless they have the `disable` bit set to 1.
- MUST NOT rebroadcast `channel_update`s to its peers, unless they have the
`disable` bit set to 1.
- SHOULD accept `channel_update`s for its own channels (even if non-public),
in order to learn the associated origin nodes' forwarding parameters.
- if `signature` is not a valid signature, using `node_id` of the
Expand Down Expand Up @@ -870,6 +874,8 @@ The receiver:
`first_timestamp` plus `timestamp_range`.
- If a `channel_announcement` has no corresponding `channel_update`s:
- MUST NOT send the `channel_announcement`.
- If the funding output of the `channel_announcement` has been spent:
- MUST NOT send the `channel_announcement`.
- Otherwise:
- MUST consider the `timestamp` of the `channel_announcement` to be the `timestamp` of a corresponding `channel_update`.
- MUST consider whether to send the `channel_announcement` after receiving the first corresponding `channel_update`.
Expand Down