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 07: delay announcement_signatures by max(6, min_depth) confs #625

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
3 participants
@cfromknecht
Copy link
Collaborator

commented Jun 25, 2019

This PR modifies the sending requirements of announcement_signatures to wait max(6, min_depth) blocks before sending. The current reading says to wait for the funding_locked exchange and 6 confirmations, so this modification doesn't change the height at which the announcement_signatures should first be sent, but removes the stricter ordering requirements wrt funding_locked and (indirectly) channel_reestablish.

Note that the current wording is conflicting, as BOLT 2 say that BOLT 7 message retransmission is independent of BOLT 2 retransmission, though the current announcement_signatures retransmission has ordering requirements wrt to funding_locked.

The proposed fix here is to relax the ordering constraints on announcement_signatures, while still ensuring that announcement_signatures aren't transmitted grossly before the funding_locked message (e.g., the case where min_depth >> 6). This change is aimed at making the BOLTs more isolated, and reduce the coordination requirements between gossip and peer messages.

This change makes it easier for implementations to isolate critical forwarding functionality from non-critical processing of gossip traffic via isolated daemons or subsystems.

See prior discussion on #620

@renepickhardt
Copy link
Contributor

left a comment

As far as I understand the process for channel opening this PR is not specific enough. Only the fundee sets a min_depth in their channel_accept message. When suggesting to wait for min(6,min_depth) it is unclear whose min_depth value to use.

Let's say A funds a channel with min=15 to B who has mdin_depth=9. Now B would send the announcement message at 9? It is not aware of A's 15. What about A? Do they use their own min_depth or the one from B? I assume A's.

On a side note: while I understand your request one thing bothers me. If for some reason the funding_locked did not arrive in our non reliable communication layer we might end up announcing a public channel on gossip for which we don't have the next per_commit_point which makes the channel unusable for the network. We might have to add a rule about that with the update_add_htlc messages.

@cfromknecht cfromknecht force-pushed the cfromknecht:delay-announcement-signatures branch from f16a8c5 to cdc0f15 Jul 1, 2019

@cfromknecht

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 1, 2019

Thanks for the feedback @renepickhardt

As far as I understand the process for channel opening this PR is not specific enough. Only the fundee sets a min_depth in their channel_accept message. When suggesting to wait for min(6,min_depth) it is unclear whose min_depth value to use.

Let's say A funds a channel with min=15 to B who has mdin_depth=9. Now B would send the announcement message at 9? It is not aware of A's 15. What about A? Do they use their own min_depth or the one from B? I assume A's.

I can see how that could be confusing, I've updated the wording to be more specific. I was under the assumption that since the both parties use the same fundee-proposed minimum_depth that this would carry over.

On a side note: while I understand your request one thing bothers me. If for some reason the funding_locked did not arrive in our non reliable communication layer we might end up announcing a public channel on gossip for which we don't have the next per_commit_point which makes the channel unusable for the network.

A conservative node may still choose to send its announcement_signatures only after receiving the remote party's funding_locked, which would yield the same thing as the current BOLT 7 wording. Given the propagation delay of gossip traffic, I don't think it'd be much of an issue if they are loosely coupled, even if they were spaced out by a few seconds. If the transport between two nodes is so unreliable that they can send one but not the other, they're going to have trouble being a useful channel.

I'm more concerned with the case where a node maliciously withholds funding_locked after receiving announcement_signatures, but as discussed in the other thread, this is really no different from the a malicious peer becoming unresponsive even if funding_locked had been exchanged.

We might have to add a rule about that with the update_add_htlc messages.

What rule do you have in mind?

@TheBlueMatt

This comment has been minimized.

Copy link
Collaborator

commented Jul 1, 2019

This effectively reverts #495 without (IMO) sufficient justification. Practically, #495 was important as it allows a node to avoid storing their peers' announcement_signatures prior to announcement (which should wait on having sent and received funding_locked). If you want them to be separate from channel_reestablish, I don't have a huge disagreement there (though it really doesn't seem right - announcement_signatures really makes little sense as a BOLT 7 message - its not about gossip, its about peers exchanging information which they can use to gossip their own channels), but as-is this breaks real things.

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.