-
Notifications
You must be signed in to change notification settings - Fork 491
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 2&7: Cleaner separation of concerns wrt announcement signatures #97
Conversation
So far we did not have any indication on what to do if a node does not allow announcing the channel and we had a mix of concerns in the `funding_locked` message, which would also transfer the signatures needed for the announcement. This is a proposal about splitting the signatures into their own message, so that simple omission is an opt-out of announcements, and it does not mix announcement/gossip stuff into the peer-protocol.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is good, but incomplete:
-
You need to move the following from 02 to 07 (removing the part that lets the sigs be zeros):
The sender MUST set
announcement-node-signature
andannouncement-bitcoin-signature
to the signatures for thechannel_announcement
message, or all zeroes if it does not want the
channel announced.The recipient SHOULD fail the channel if the
announcement-node-signature
andannouncement-bitcoin-signature
s are incorrect (and not all zeroes). The recipient SHOULD queue thechannel_announcement
message for its peers if it has sent and received a non-zeroannouncement-node-signature
andannouncement-bitcoin-signature
. -
You need to specify that it MUST follow
funding-locked
(specifically, after you have BOTH received and sent funding-locked successfully). -
Please also edit bolt 02 "Once both nodes have exchanged
funding_locked
" to add "(and optionallyannouncement_signatures
)". -
Finally, "Message Retransmission" needs updating: the line "
funding_locked
: acknowledged by" should be duplicated to "announcement_signatures
: acknowledged by" and announcement_signatures added to the list of things which acknowledgefunding_locked
.
I definitely need new reading glasses, sorry for missing those :-) I amended your first two points, but I am a bit wary of mixing the channel lifecycle messages with the routing messages. The exchange of the routing signatures is not time-critical, so we could just move the signature exchange at a later point in the execution, outside of the strict state machine. Retransmission is also rather simple: if we haven't seen our channel announced we can just send the signatures again. |
Christian Decker <notifications@github.com> writes:
I definitely need new reading glasses, sorry for missing those :-)
I amended your first two points, but I am a bit wary of mixing the channel lifecycle messages with the routing messages. The exchange of the routing signatures is not time-critical, so we could just move the signature exchange at a later point in the execution, outside of the strict state machine. Retransmission is also rather simple: if we haven't seen our channel announced we can just send the signatures again.
I'd agree, except you can't distinguish between "they didn't want to
announce the channel" and "they didn't get my message" or "I didn't get
their message".
The other reliable way to do it is *always* re-transmit on new
connection if we've agreed on funding locked, unless you've seen an
announcement. But that still needs to be specified in the reconnection
paragraph, so it's no cleaner :(
Cheers,
Rusty.
|
I like the "just send signature on open/reopen" much better, it's an event we are hooking into anyway to do the initial announcement. |
I share Christian's concerns, but I am still slightly in favor of the existing explicit opt-out mechanism because I think it makes the channel creation flow simpler and easier to understand (even if it comes at the expense of the separation of concerns). Also I like the fact that we know from the get-go if the channel will ever be 'public' or 'private' from a user's perspective. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent, I really like this change. With the mechanism we were using before, there wasn't an explicit way for a node to op-out of advertising a channel or not.
In order to resolve the ambiguity issues that Rusty brought up, we could add a bit to the open_channel
and accept_channel
which signals if the message carrying the announcement signatures are to be expected or not.
07-routing-gossip.md
Outdated
* [64:node-signature] | ||
* [64:bitcoin-signature] | ||
|
||
An `announcement_signatures` message MUST NOT be sent before the channel is fully established, i.e., before both ends have received the corresponding `channel_locked` messages. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
channel_locked
should be funding_locked
OK, I think we want to add a feature bit. That should be easy: |
Ok, amended the PR to include the opt-in localfeature, added a tracking document for the assigned feature flags and added the restriction to send it inbetween the One minor concern is that the featureflag now impacts all channels on this connection ( |
So far we did not have any indication on what to do if a node does not
allow announcing the channel and we had a mix of concerns in the
funding_locked
message, which would also transfer the signaturesneeded for the announcement. This is a proposal about splitting the
signatures into their own message, so that simple omission is an
opt-out of announcements, and it does not mix announcement/gossip
stuff into the peer-protocol.
This builds on top of #96. There is some concern that pulling this
message out of the strictly controlled state machine of the channel
lifecycle may have unwanted consequences.