Skip to content

Commit a265fc2

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 e7facb1 commit a265fc2

File tree

5 files changed

+290
-98
lines changed

5 files changed

+290
-98
lines changed

lightning/src/ln/chanmon_update_fail_tests.rs

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -20,6 +20,7 @@ use chain::channelmonitor::ChannelMonitor;
2020
use chain::transaction::OutPoint;
2121
use chain::{ChannelMonitorUpdateErr, Listen, Watch};
2222
use ln::channelmanager::{ChannelManager, ChannelManagerReadArgs, RAACommitmentOrder, PaymentSendFailure};
23+
use ln::channel::AnnouncementSigsState;
2324
use ln::features::InitFeatures;
2425
use ln::msgs;
2526
use ln::msgs::{ChannelMessageHandler, RoutingMessageHandler};
@@ -1402,6 +1403,11 @@ fn monitor_failed_no_reestablish_response() {
14021403
let node_chanmgrs = create_node_chanmgrs(2, &node_cfgs, &[None, None]);
14031404
let mut nodes = create_network(2, &node_cfgs, &node_chanmgrs);
14041405
let channel_id = create_announced_chan_between_nodes(&nodes, 0, 1, InitFeatures::known(), InitFeatures::known()).2;
1406+
{
1407+
let mut lock;
1408+
get_channel_ref!(nodes[0], lock, channel_id).announcement_sigs_state = AnnouncementSigsState::PeerReceived;
1409+
get_channel_ref!(nodes[1], lock, channel_id).announcement_sigs_state = AnnouncementSigsState::PeerReceived;
1410+
}
14051411

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

0 commit comments

Comments
 (0)