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

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

Author: TheBlueMatt

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.

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