channeld: Implement receiving of `start_batch`
What changed, and why it matters
This commit adds code to handle a new peer message called 'start_batch' in Core Lightning's channel daemon. Previously, the message type existed but was ignored (the case just returned). Now the daemon parses the message, checks that it is requesting a batch of 'commitment_signed' messages, and forwards the batch size into the existing batch signature handling logic. The change itself is a feature completion rather than a clear security fix, but it removes a place where a protocol message was silently ignored and could have caused mismatched state between two channel peers.
Review whether batch_size needs an upper-bound sanity check before being passed to handle_peer_commit_sig_batch(), and confirm that peer_failed_warn() on malformed start_batch is the desired failure policy. Audit the interaction between start_batch and the next read message to ensure an attacker cannot desynchronize the channel state by sending an unexpected or malformed start_batch.
Security signals we found
Previously ignored protocol message is now parsed and acted upon
Message parsing failure calls peer_failed_warn(), terminating the connection
Unrecognized batch_info types are logged and ignored rather than failing the peer
batch_size is now consumed from a peer-controlled message and passed to batch commitment signature handling
No input length or batch_size bounds checks visible in the added code
Evidence from the diff
The patch implements handle_peer_start_batch() in channeld/channeld.c. It deserializes a WIRE_START_BATCH message using fromwire_start_batch(), validates the TLV batch_info field equals WIRE_COMMITMENT_SIGNED, logs and ignores other types, and then calls handle_peer_commit_sig_batch() with the decoded batch_size and a freshly read follow-up message from the peer. The peer_in() switch case for WIRE_START_BATCH now invokes this handler instead of doing nothing. The commit message says ‘Since batch_size has moved into this new message, we can’t ignore it anymore and have to process it.’
Changed components
channeld/channeld.cWIRE_START_BATCH message handlinghandle_peer_commit_sig_batch() batch processingInspect captured patch +30 / −0
diff --git a/channeld/channeld.c b/channeld/channeld.c
index 2c1697cd..fde5e382 100644
--- a/channeld/channeld.c
+++ b/channeld/channeld.c
@@ -2325,6 +2325,35 @@ static struct commitsig_info *handle_peer_commit_sig_batch(struct peer *peer,
allow_empty_commit, msg_batch);
}
+static void handle_peer_start_batch(struct peer *peer, const u8 *msg)
+{
+ u16 batch_size;
+ struct channel_id channel_id;
+ struct tlv_start_batch_tlvs *tlvs;
+ if (!fromwire_start_batch(tmpctx, msg, &channel_id, &batch_size, &tlvs))
+ peer_failed_warn(peer->pps, &peer->channel_id,
+ "Bad start_batch %s", tal_hex(msg, msg));
+
+ if (!tlvs || !tlvs->batch_info
+ || *tlvs->batch_info != WIRE_COMMITMENT_SIGNED) {
+ status_unusual("Ignoring Unrecognized start_batch message type"
+ " %s, expected WIRE_COMMITMENT_SIGNED.",
+ tlvs && tlvs->batch_info
+ ? peer_wire_name(*tlvs->batch_info)
+ : "N/A");
+ return;
+ }
+
+ handle_peer_commit_sig_batch(peer, peer_read(tmpctx, peer->pps), 0,
+ peer->channel->funding_pubkey[REMOTE],
+ NULL, 0, 0,
+ peer->next_index[LOCAL],
+ &peer->next_local_per_commit,
+ false,
+ batch_size);
+}
+
+
/* Pops the penalty base for the given commitnum from our internal list. There
* may not be one, in which case we return NULL and leave the list
* unmodified. */
@@ -4884,6 +4913,7 @@ static void peer_in(struct peer *peer, const u8 *msg)
handle_peer_add_htlc(peer, msg);
return;
case WIRE_START_BATCH:
+ handle_peer_start_batch(peer, msg);
return;
case WIRE_COMMITMENT_SIGNED:
handle_peer_commit_sig_batch(peer, msg, 0,
Why this scored 33/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.