Skip to content

Commit cc7a03a

Browse files
committed
Disconect announcement_signatures sending from funding_locked
The spec actually requires we never send `announcement_signatures` (and, thus, `channel_announcement`s) until after six confirmations. However, we would happily have sent them prior to that as long as we exchange `funding_locked` messages with our countarparty. Thanks to re-broadcasting this issue is largely harmless, however it could have some negative interactions with less-robust peers. Much more importantly, this represents an important step towards supporting 0-conf channels, where `funding_locked` messages may be exchanged before we even have an SCID to construct the messages with. Because there is no ACK mechanism for `announcement_signatures` we rely on existing channel updates to stop rebroadcasting them - if we sent a `commitment_signed` after an `announcement_signatures` and later receive a `revoke_and_ack`, we know our counterparty also received our `announcement_signatures`. This may resolve some rare edge-cases where we send a `funding_locked` which our counterparty receives, but lose connection before the `announcement_signatures` (usually the very next message) arrives. Sadly, because the set of places where an `announcement_signatures` may now be generated more closely mirrors where `funding_locked` messages may be generated, but they are now separate, there is a substantial amount of code motion providing relevant parameters about current block information and ensuring we can return new `announcement_signatures` messages.
1 parent cb8a5cf commit cc7a03a

File tree

5 files changed

+274
-94
lines changed

5 files changed

+274
-94
lines changed

lightning/src/ln/chanmon_update_fail_tests.rs

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -21,6 +21,7 @@ use chain::transaction::OutPoint;
2121
use chain::{ChannelMonitorUpdateErr, Listen, Watch};
2222
use ln::{PaymentPreimage, PaymentHash};
2323
use ln::channelmanager::{ChannelManager, ChannelManagerReadArgs, RAACommitmentOrder, PaymentSendFailure};
24+
use ln::channel::AnnouncementSigsState;
2425
use ln::features::InitFeatures;
2526
use ln::msgs;
2627
use ln::msgs::{ChannelMessageHandler, ErrorAction, RoutingMessageHandler};
@@ -1420,6 +1421,11 @@ fn monitor_failed_no_reestablish_response() {
14201421
let node_chanmgrs = create_node_chanmgrs(2, &node_cfgs, &[None, None]);
14211422
let mut nodes = create_network(2, &node_cfgs, &node_chanmgrs);
14221423
let channel_id = create_announced_chan_between_nodes(&nodes, 0, 1, InitFeatures::known(), InitFeatures::known()).2;
1424+
{
1425+
let mut lock;
1426+
get_channel_ref!(nodes[0], lock, channel_id).announcement_sigs_state = AnnouncementSigsState::PeerReceived;
1427+
get_channel_ref!(nodes[1], lock, channel_id).announcement_sigs_state = AnnouncementSigsState::PeerReceived;
1428+
}
14231429

14241430
// Route the payment and deliver the initial commitment_signed (with a monitor update failure
14251431
// on receipt).

0 commit comments

Comments
 (0)