Separate commitment_signed batches from interactive tx commitment_signed

[ddustin]

Clarifying the logic for commitment_signed batches are different and separate from individual commitment_signed messages used during interactive transaction protocol reestablishing.

This creates a clean separation from when next_commitment_number is being used to resend an individual commitment_signed message and when it is being used to resend a commitment_signed batch.

Without this change implementors don’t have clarity about whether a decremented next_commitment_number is meant to send an individual commitment_signed message, ``commitment_signed` batch, or both.

[t-bast]

separate from individual commitment_signed messages used during interactive transaction protocol reestablishing.

I don't think I agree with this base principle: individual commitment_signed messages aren't only used during interactive-tx construction, they're also the normal case of a channel operating without a pending splice. It's rather having a batch of commitment_signed message which is an exceptional case where splice transactions are pending. Most of the time, nodes will exchange a single commitment_signed message without the batch field set.

If I'm understanding you correctly, I think that what you're really trying to disambiguate is whether a next_commitment_number set to the current commitment number (and thus asking for a retransmission) applies to the commitment_signed of an interactive-tx or a commitment_signed (batch or individual) for normal channel operation. If that's what you want, it's the presence of the next_funding_txid field that gives you this information:

• if next_funding_txid is set, then a commitment_signed retransmission will be for the commitment_signed of the interactive-tx session
• if next_funding_txid is NOT set, then it means tx_signatures have been sent and received, and thus the corresponding commitment_signed has been sent and received (since we only send tx_signatures after sending and receiving `commitment_signed), and the retransmission is for normal channel operation (which could be a batch if splices are pending, or an individual message if there are no pending splices)

Does that make sense? Or am I misunderstanding your goal here?