Skip to content
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 02: clarify that announcement_signatures is a BOLT 7 msg #620

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
3 participants
@cfromknecht
Copy link
Collaborator

commented Jun 13, 2019

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

This comment has been minimized.

Copy link
Collaborator Author

commented Jun 13, 2019

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

This comment has been minimized.

Copy link
Collaborator

commented Jun 14, 2019

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

This comment has been minimized.

Copy link
Collaborator Author

commented Jun 14, 2019

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

This comment has been minimized.

Copy link
Collaborator

commented Jun 17, 2019

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

This comment has been minimized.

Copy link
Collaborator Author

commented Jun 19, 2019

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

This comment has been minimized.

Copy link
Collaborator

commented Jun 20, 2019

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

This comment has been minimized.

Copy link
Collaborator Author

commented Jun 20, 2019

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

This comment has been minimized.

Copy link
Collaborator Author

commented Jun 25, 2019

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

This comment has been minimized.

Copy link
Collaborator

commented Jul 1, 2019

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

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 2, 2019

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

This comment has been minimized.

Copy link
Collaborator

commented Jul 2, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.