BOLT 02: clarify that announcement_signatures is a BOLT 7 msg

[cfromknecht]

There seems to be some confusion as to which messages can be sent
before channel_reestablish. The spec says that all BOLT 7 messages
can be sent independently of the requirements of channel_reestablish.
This change clarifies that announcement_signatures are also included
categorically.

[cfromknecht]

Relevant links:

• lnd sends announcement_signatures before reestablish_channel lightningnetwork/lnd#2940 (comment)
• Unable to retrieve advertised address for node ...: no advertised addresses found lightningnetwork/lnd#3183 (comment)
• ElementsProject/lightning@9366787
• Clarification: Waiting for their announcement signatures. What does it actually mean? ElementsProject/lightning#1778 (comment)
• Clarification: Waiting for their announcement signatures. What does it actually mean? ElementsProject/lightning#1778 (comment)

[cfromknecht]

Note: this wording hasn’t been meaningfully changed for three years. IMO this change isn’t actually necessary as the text is already pretty explicit, but if it helps to clarify then I suppose it’s useful.

[pm47]

While I agree with @cfromknecht that a litteral interpretation of the spec does allow sending of announcement_signatures before channel_reestablish, I think that it is wrong because the exchange of announcement_signatures is part of the lifecycle of the channel:

BOLT 2:
Once both nodes have exchanged funding_locked (and optionally announcement_signatures), the channel can be used to make payments via Hashed Time Locked Contracts.

For that reason announcement_signatures should probably have been part of BOLT 2.

The decorrelation between BOLT 2 and BOLT 7 makes of course complete sense for node_announcement, channel_announcement and channel_update.

[cfromknecht]

I think that it is wrong because the exchange of announcement_signatures is part of the lifecycle of the channel

Only for advertised channels, announcement_signatures are not critical to using the channel otherwise we couldn't have non-advertised channels. I'd argue that the restriction to block on announcement_signatures is unnecessary, and either way doesn't inherently impose an ordering wrt channel_reestablish.

IMO the existing delineation is very clean, all channels are inherently created private and can be advertised via the processes in BOLT 7 if announce_channel is set. There's no inherent reason why a channel couldn't be made public after-the-fact if both parties opt in.

What would we gain by restricting counterparties from using their own channel before the proofs have been constructed? The counterparties already signal their readiness to use the channel via funding_locked, announcment_signatures only serve to signal readiness to forward HTLCs for the wider network.

I think a good litmus test for whether something belongs in BOLT 7 vs BOLT 2 is whether or not it only applies to advertised channels, which is how the current spec reads (apart from blocking usage on announcement_signatures).

[pm47]

I'd argue that the restriction to block on announcement_signatures is unnecessary

What would we gain by restricting counterparties from using their own channel before the proofs have been constructed?

I agree, and we don't block on announcement_signatures in eclair either. I believed this part was covering the opposite scenario where min_depth>6, but now that I re-read it, it is not at all obvious. Anyway, the point I was making is that we don't want to announce a channel before it is usable, so we need to exchange funding_locked before announcement_signatures. If we agree on this, then it follows that announcement_signatures can't be sent before channel_reestablish.

[cfromknecht]

I believed this part was covering the opposite scenario where min_depth>6

Anyway, the point I was making is that we don't want to announce a channel before it is usable

I agree here, in the case where announcement_signatures could be sent well before funding_locked, we don't want to announce early.

I don't think this implies though that funding_locked has to be sent before announcement_signatures. Isn't it sufficient to recommend waiting max(6, min_depth) blocks in BOLT 7 before sending announcement _signatures to your peer, without requiring a them to be tightly coupled?

The last peer to speak dictates the time of announcement, so a malicious peer can't force an earlier announcement.

Even a peer is malicious and gets you to exchange announcement_signatures but doesn't send funding_locked (resulting in an unusable, advertised channel), I don't see how would be any different from the peer refusing to participate in the protocol even if funding_locked had been exchanged.

[pm47]

I don't think this implies though that funding_locked has to be sent before announcement_signatures. Isn't it sufficient to recommend waiting max(6, min_depth) blocks in BOLT 7 before sending announcement _signatures to your peer, without requiring a them to be tightly coupled?

It would indeed be sufficient, gives more degrees of liberty, but is also less straightforward and I don't see the added benefit of flexibility in that case. I think the existence of this PR justifies that sometimes simpler and straightforward at the expense of flexibility could avoid future interop issues.

[cfromknecht]

is also less straightforward and I don't see the added benefit of flexibility in that case.

If I'm not mistaken, the original philosophy was that different BOLTs could be implemented in distinct daemons. Requiring more coordination between the two makes this separation strictly more cumbersome. FWIW, in LND the BOLT 2 and BOLT 7 subsystems are completely isolated from each other, so I think it's a matter of perspective on which approach is more straightforward. I also would have thought CL would also be interested in reducing the coordination requirements given the multi-daemon architecture.

Considering that imposing a stricter ordering doesn't offer anything from a safety perspective, are there any other substantial reasons to remove the flexibility that aren't addressed by delaying announcement_signatures for max(6, min_depth) blocks?

@cdecker @rustyrussell any thoughts on this? Would delaying announcement_signatures as described help at all with compat in the cases you've seen? If so I think that'd be a pretty minimal change on our end. I could also make a PR add this recommendation to BOLT 7, since idt it conflicts with any of the existing requirements.

also thank you @pm47 for the helpful discussion and improving my understanding of the nuances :)

[cfromknecht]

So in writing up the proposal to use a max(6, min_depth) delay for announcement_signatures, I came across the exact requirement that is conflicting and explains source of confusion. See #625 for more details

[TheBlueMatt]

Strongly disagree that announcement_signatures "is a BOLT 7 message" - its not a gossip message, its not something which is forwarded on, and its something which is generated from local channel state (and the receiving node must use local channel state to process it).

[cfromknecht]

It lives in BOLT 7 and has all of its requirements specified in BOLT 7, if that doesn't constitute a BOLT 7 message it's not clear to me why others would infer that. Are gossip query messages also "not BOLT 7 messages"?

[TheBlueMatt]

I can't say I particularly care where it is specified, but from a practical implementation PoV, as in my example in #625, there really are reasons to have its send tie be determined by channel info.

[rustyrussell]

Yes, this is wrong. It's in bolt 7 because there was a desire to thin out bolt 2. It's not "independent of particular channels", its only relation to gossip is that it's a precursor to being able to gossip: it is in no manner a gossip message itself.