-
Notifications
You must be signed in to change notification settings - Fork 512
Gossip Infinite Loop Fix #1256
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
base: master
Are you sure you want to change the base?
Gossip Infinite Loop Fix #1256
Conversation
Update the spec to prevent an infinite message loop. As previously specified, both nodes must send `announcement_signatures` back and forth to each other forever. Update it to specify “once per connection” to prevent this loop.
- If it receives `announcement_signatures` for the funding transaction: | ||
- MUST respond with its own `announcement_signatures` message. | ||
- MUST respond with its own `announcement_signatures` message once per connection. |
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.
We should indeed make it clearer that we mustn't create an infinite loop (even though I hope every implementation already does this correctly - eclair does). I'm nitpicking, but with the change you're proposing, if we strictly follow the spec without thinking, we'd still be sending one redundant announcement_signatures
:
- Both nodes send
announcement_signatures
on reconnection because of the requirement above ("If it has NOT previously received (...): MUST sent its ownannouncement_signatures
message.) - When receiving the remote
announcement_signatures
, they would respond with their ownannouncement_signatures
, even though they already sent it right before - Then they would stop re-sending
announcement_signatures
It would be slightly more correct to change the spec to say that you only respond with your own announcement_signatures
if you haven't already sent it since reconnecting:
- If it receives `announcement_signatures` for the funding transaction:
- If it has not already sent its own `announcement_signatures` since reconnecting:
- MUST respond with its own `announcement_signatures`.
Also note that all of this will be cleaned up with taproot, where we will need nonces to be able to create our own announcement_signatures
, and will thus only re-send it after exchanging channel_ready
(which will contain those nonces). We won't be able to have a loop of announcement_signatures
message because we won't have nonces to create the partial signatures!
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.
@ddustin ping?
@ddustin this PR seems stale, can you update it to fix the pending comment? |
This change aligns our behavior with latest protocol guidelines. That is, when we receive a signature announcement when we already have the full proof we reply with our signature announcement once per (re)connection. see: lightning/bolts#1256
This change aligns our behavior with latest protocol guidelines. That is, when we receive a signature announcement when we already have the full proof we reply with our signature announcement once per (re)connection. see: lightning/bolts#1256
This change aligns our behavior with latest protocol guidelines. That is, when we receive a signature announcement when we already have the full proof we reply with our signature announcement once per (re)connection. see: lightning/bolts#1256
This change aligns our behavior with latest protocol guidelines. That is, when we receive a signature announcement when we already have the full proof we reply with our signature announcement once per (re)connection. see: lightning/bolts#1256
Update the spec to prevent an infinite message loop.
As previously specified, both nodes must send
announcement_signatures
back and forth to each other forever.Update it to specify “once per connection” to prevent this loop.