This feels sort of dumb but I wrote it up and thought maybe others would find it enlightening.
There's been a question of whether or not we should re-send all of the commitment-sigs after a new splice has been negotiated. The current CLN draft of splicing sends all of them, should we only send the one? After writing this out, it seems fairly obvious to me that the correct way forward is to only send a commitment sig for the newly negotiated splice; all of the commitment sigs should be re-sent only when the underlying commitment tx changes (eg. htlc added/removed). Longer analysis below. As an interesting 'historical aside', in the original splicing draft proposal, all commitment sigs were sent in a single message; we've since split them out into more messages, which now nicely allows for only sending the new commitment_signed message when appropriate. ~nifty h/t to @ddustin and @t-bast for surfacing this. # Should we re-send commit_sigs + revoke_and_ack for newly negotiated splices? ## Background When a splice tx is successfully negotiated, we need to send a commitment-sig to the peer to be able to send the new funding tx. After `tx_complete`, we need to exchange the `commitment_sig` for the newly created splice tx. ## Purpose of `commitment_signed` The purpose of the `commitment_signed` message is to send the peer your commitment sig for the currently proposed commitment. ## Purpose of `revoke_and_ack` The purpose of `revoke_and_ack` is two-fold: - Send a revocation point for the previous commitment transaction, REVOKING the previous commitment - ACK that the commitment sig has been received for the next commitment ## Current Protocol Currently we send the following: - a `commitment_sig` message for the just negotiated splice tx - resends all prior negotiated splice `commit_sigs` (if RBF) and the non-splice commit-sig. After receiving all the `commit_sig` messages, we do the 'normal' thing where we then exchange a single `revoke_and_ack`. Notably, the Current Protocol is identical for both new commitment signed workflows and a new splice negotiation. Which is to say, we re-use the same protocol for any new commitment signatures that are required. ### Benefits to this Approach - Single action to be taken after either a new commitment is negotiated or a splice. - Less complexity in implementation + less testing footprint ### Drawbracks to this Approach - Redundant messages are sent (peer already has all prior commitment sigs in the splice case) - More signing required for successful splice ## Alternative Proposal Instead of sending all of the commit-sigs and a revoke_and_ack, we'd send a single `commitment_sig`. ### Benefits of this Approach - Less data sent over the wire. Only new information is transmitted - Less signatures need to be (re)-generated. ### Drawbacks to this Approach - We need a way to communicate that the `commitment_sig` has been received. (`tx_signatures` should fill this role.) - It's a slightly different way of doing commitments.
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
