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

BOLT 7: Push the sending of announcements_signatures back a little (amended wording) #495

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
2 participants
@rustyrussell
Collaborator

rustyrussell commented Oct 29, 2018

Technically this change may result in channels_announcements only
coming from one end. However, because c-lightning already implements
announcement_signatures in this way, in practice this will improve
reliability of channel_announcements.

[ After much bikeshedding, wording rewritten but same effect -- RR ]

Closes #468
Closes: #474

BOLT 7: Push the sending of announcements_signatures back a little
Technically this change may result in channels_announcements only
coming from one end. However, because c-lightning already implements
announcement_signatures in this way, in practice this will improve
reliability of channel_announcements.

[ After much bikeshedding, wording rewritten but same effect -- RR ]

Closes #468
Closes: #474
@TheBlueMatt

This comment has been minimized.

Contributor

TheBlueMatt commented Oct 29, 2018

This does not fix #468?

@rustyrussell

This comment has been minimized.

Collaborator

rustyrussell commented Oct 30, 2018

I though #468 suggested exactly this:

if, instead, a node SHOULD wait until it has both sent and received a funding_locked to send an announcement_signatures..

Thus, this changes the text to:

MUST NOT send announcement_signatures messages until funding_locked has been sent and received

However, since other nodes don't obey this, we add the suggestion that you may store an unexpected announcement_signatures msg (hmm, indent is wrong, tabs vs spaces it seems)

- if it has not sent funding_locked:
    - MAY defer handling the announcement_signatures until after it has sent funding_locked
    - otherwise:
	  - MUST ignore it.
@TheBlueMatt

This comment has been minimized.

Contributor

TheBlueMatt commented Oct 31, 2018

Oh, am I blind? In any case the proposed changes look fine to me, I just didn't think we were comfortable making breaking changes to the spec that may make existing implementations "invalid".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment