channeld.c: update logic for retransmitting channel_ready Extracted logic from if clause to variable for readability, and add extra checks to make sure a splice is active
What the developer wrote
Authored by Níckolas Goline
channeld.c: update logic for retransmitting channel_ready
Extracted logic from if clause to variable for readability, and add extra checks to make sure a splice is active
What changed, and why it matters
This change adjusts when Core Lightning re-sends a 'channel_ready' message after a peer reconnects. It adds an extra check to avoid retransmitting the message if a splice (a way to resize a Lightning channel) is active. The commit is framed as a readability improvement with added splice-safety checks, but it does not clearly state it fixes a security bug.
Review whether the prior code could cause incorrect channel_ready retransmission during an active splice, which might lead to protocol confusion or state mismatch. Treat as a correctness/safety fix; monitor for related BOLT compliance or security advisories from the project.
Security signals we found
Logic change around retransmission of channel_ready during peer reconnection
New condition checks received TLV funding_locked txid against current funding txid
Splice-related state now gates channel_ready retransmission
No explicit security framing in commit message or diff comments
Evidence from the diff
In channeld.c’s peer_reconnect(), the conditions for retransmitting channel_ready are refactored into a new boolean is_splice_active. The new variable includes the previous splice/funding checks and adds a new condition: if received channel_reestablish TLVs contain my_current_funding_locked and its txid differs from the current channel funding txid, the channel_ready is not retransmitted. This prevents re-sending channel_ready when a splice is in progress and the peer has already locked a different funding transaction.
Changed components
channeld/channeld.cpeer_reconnect()channel_ready retransmission logicsplice state handlingInspect captured patch +12 / −4
diff --git a/channeld/channeld.c b/channeld/channeld.c
index 0b45fb88..ca8d300b 100644
--- a/channeld/channeld.c
+++ b/channeld/channeld.c
@@ -5954,6 +5954,17 @@ static void peer_reconnect(struct peer *peer,
"next_funding_txid not recognized.");
}
+ /* "none of those channel_reestablish messages contain
+ * my_current_funding_locked or next_funding for a splice transaction" */
+ bool is_splice_active = local_next_funding
+ || peer->splice_state->locked_ready[LOCAL]
+ || remote_next_funding
+ || (recv_tlvs
+ && recv_tlvs->my_current_funding_locked
+ && !bitcoin_txid_eq(
+ &recv_tlvs->my_current_funding_locked->my_current_funding_locked_txid,
+ &peer->channel->funding.txid));
+
/* BOLT #2:
*
* - if `next_commitment_number` is 1 in both the
@@ -5968,10 +5979,7 @@ static void peer_reconnect(struct peer *peer,
if (peer->channel_ready[LOCAL]
&& peer->next_index[LOCAL] == 1
&& next_commitment_number == 1
- && !local_next_funding
- && !(send_tlvs && send_tlvs->my_current_funding_locked)
- && !remote_next_funding
- && !(recv_tlvs && recv_tlvs->my_current_funding_locked)) {
+ && !is_splice_active) {
struct tlv_channel_ready_tlvs *tlvs = tlv_channel_ready_tlvs_new(tmpctx);
tlvs->short_channel_id = &peer->local_alias;
Why this scored 34/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.