Skip to content

Conversation

ddustin
Copy link
Contributor

@ddustin ddustin commented May 2, 2025

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.

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.
Comment on lines 94 to +95
- 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.
Copy link
Collaborator

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 own announcement_signatures message.)
  • When receiving the remote announcement_signatures, they would respond with their own announcement_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!

Copy link
Collaborator

Choose a reason for hiding this comment

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

@ddustin ping?

@t-bast t-bast added the spelling These changes may be merged without additional sign off from the weekly meeting label May 5, 2025
@t-bast
Copy link
Collaborator

t-bast commented Jun 11, 2025

@ddustin this PR seems stale, can you update it to fix the pending comment?

gijswijs added a commit to gijswijs/lnd that referenced this pull request Jun 17, 2025
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
gijswijs added a commit to gijswijs/lnd that referenced this pull request Jun 17, 2025
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
gijswijs added a commit to gijswijs/lnd that referenced this pull request Jun 17, 2025
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
gijswijs added a commit to gijswijs/lnd that referenced this pull request Jul 7, 2025
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
@ddustin
Copy link
Contributor Author

ddustin commented Aug 11, 2025

Sounds like we're moving towards putting info about a channel_announcement in the channel reestablish

@t-bast
Copy link
Collaborator

t-bast commented Aug 12, 2025

@ddustin I have made that change to the splice spec in the latest commit of #1160 (f9fd539) and have updated eclair to implement this latest spec (in ACINQ/eclair#2887). Let me know what you think and how implementation goes on your side!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
spelling These changes may be merged without additional sign off from the weekly meeting
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants