Merge pull request #2071 from TheBlueMatt/2023-01-fix-fast-extra-ready-panic

Fix panic on receiving `channel_ready` after 1st commitment update

diff --git a/lightning/src/ln/channel.rs b/lightning/src/ln/channel.rs
index 842c91180868c3d21a95feff20b303aba7c5288d..9af0f6379e5a1672e851a61ef0c54d717235a1a5 100644 (file)
--- a/lightning/src/ln/channel.rs
+++ b/lightning/src/ln/channel.rs
@@ -2484,6 +2484,11 @@ impl<Signer: WriteableEcdsaChannelSigner> Channel<Signer> {
                                        // If they haven't ever sent an updated point, the point they send should match
                                        // the current one.
                                        self.counterparty_cur_commitment_point
+                               } else if self.cur_counterparty_commitment_transaction_number == INITIAL_COMMITMENT_NUMBER - 2 {
+                                       // If we've advanced the commitment number once, the second commitment point is
+                                       // at `counterparty_prev_commitment_point`, which is not yet revoked.
+                                       debug_assert!(self.counterparty_prev_commitment_point.is_some());
+                                       self.counterparty_prev_commitment_point
                                } else {
                                        // If they have sent updated points, channel_ready is always supposed to match
                                        // their "first" point, which we re-derive here.

diff --git a/lightning/src/ln/priv_short_conf_tests.rs b/lightning/src/ln/priv_short_conf_tests.rs
index 7636f5c63641edc5e18cb5d7f69d3375a9fa235b..f563a63cfd1a41b2363ac5421c53d39b3effa7a2 100644 (file)
--- a/lightning/src/ln/priv_short_conf_tests.rs
+++ b/lightning/src/ln/priv_short_conf_tests.rs
@@ -242,6 +242,13 @@ fn test_routed_scid_alias() {
        check_added_monitors!(nodes[0], 1);
 
        pass_along_route(&nodes[0], &[&[&nodes[1], &nodes[2]]], 100_000, payment_hash, payment_secret);
+
+       as_channel_ready.short_channel_id_alias = Some(0xeadbeef);
+       nodes[2].node.handle_channel_ready(&nodes[1].node.get_our_node_id(), &as_channel_ready);
+       // Note that we always respond to a channel_ready with a channel_update. Not a lot of reason
+       // to bother updating that code, so just drop the message here.
+       get_event_msg!(nodes[2], MessageSendEvent::SendChannelUpdate, nodes[1].node.get_our_node_id());
+
        claim_payment(&nodes[0], &[&nodes[1], &nodes[2]], payment_preimage);
 
        // Now test that if a peer sends us a second channel_ready after the channel is operational we