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

[rustyrussell]

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 does not fix #468?

[rustyrussell]

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]

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".

[renepickhardt]

meta:

maybe I am still to new to protocol development. but that seems like a lot of complex overhead to make a backward compatible fix for a former bug. is that the normal way to go?

[rustyrussell]

In practice, allowing it through early turns out to be trivial (at least, in C-lightning). In future we may stop doing that, however. Meanwhile, usability trumps perfection...