From: Antoine Riard Date: Tue, 19 Nov 2019 22:48:22 +0000 (-0500) Subject: Document our handling of announcement_sigs X-Git-Tag: v0.0.12~177^2~1 X-Git-Url: http://git.bitcoin.ninja/index.cgi?a=commitdiff_plain;h=e938e592b2dbe7dc66b33f10ccb539afdf1a6b08;p=rust-lightning Document our handling of announcement_sigs We may have in the future to rebroadcast announcement_sigs at peer reconnection if this a burning issue as spec lacks a acknowledgement mechanism. --- diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs index c863f46b6..5452e365d 100644 --- a/lightning/src/ln/channelmanager.rs +++ b/lightning/src/ln/channelmanager.rs @@ -1972,6 +1972,15 @@ impl ChannelManager { } try_chan_entry!(self, chan.get_mut().funding_locked(&msg), channel_state, chan); if let Some(announcement_sigs) = self.get_announcement_sigs(chan.get()) { + // If we see locking block before receiving remote funding_locked, we broadcast our + // announcement_sigs at remote funding_locked reception. If we receive remote + // funding_locked before seeing locking block, we broadcast our announcement_sigs at locking + // block connection. We should guanrantee to broadcast announcement_sigs to our peer whatever + // the order of the events but our peer may not receive it due to disconnection. The specs + // lacking an acknowledgement for announcement_sigs we may have to re-send them at peer + // connection in the future if simultaneous misses by both peers due to network/hardware + // failures is an issue. Note, to achieve its goal, only one of the announcement_sigs needs + // to be received, from then sigs are going to be flood to the whole network. channel_state.pending_msg_events.push(events::MessageSendEvent::SendAnnouncementSignatures { node_id: their_node_id.clone(), msg: announcement_sigs,