-
Notifications
You must be signed in to change notification settings - Fork 492
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.
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
More clarifications around channel_announcement
handling
#1220
base: master
Are you sure you want to change the base?
More clarifications around channel_announcement
handling
#1220
Conversation
This is a follow-up of lightning#1215, where we keep reworking the announcement requirements. We remove the rationale around deferring after `channel_ready` since that has been changed years ago and shouldn't be an issue anymore. We slightly rework the wording to minimize future conflicts with the splicing PR. While nodes are free to send `announcement_signatures` whenever they feel that the channel is safe from reorg, we disallow broadcasting the `channel_announcement` before at least 6 confirmations: this gives nodes a simple heuristic to ignore `channel_announcement`s for remote channels that aren't spec-compliant, without having to deal with the extra cost of managing reorgs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall seems like a good clarification. A few comments nits:
- remove conflicting `announcement_signatures` requirements - allow a buffer of a few blocks to account for late block arrival
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
We don't need more than 6 confirmations, we need at least that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM🌹
This is a follow-up of #1215, where we keep reworking the announcement requirements.
We remove the rationale around deferring after
channel_ready
since that has been changed years ago and shouldn't be an issue anymore.We slightly rework the wording to minimize future conflicts with the splicing PR.
While nodes are free to send
announcement_signatures
whenever they feel that the channel is safe from reorg, we disallow broadcasting thechannel_announcement
before at least 6 confirmations: this gives nodes a simple heuristic to ignorechannel_announcement
s for remote channels that aren't spec-compliant, without having to deal with the extra cost of managing reorgs.