When reconnecting in the middle of signing a splice, we must ensure that splice_locked is sent aftertx_signatures. Otherwise when using 0-conf we may retransmit splice_locked before tx_signatures, which our peer will ignore because they don't have a corresponding fully signed commitment.
This may eventually lead to a mismatch where one side thinks that the splice has been locked and the other doesn't, so one side will send more signatures which results in a force-close.
It should never happen though, because we only send splice_locked once the transaction has been published (zero-conf) or confirmed. Once that happened, we will never retransmit tx_signatures (because we run into that condition), so we'll never mix tx_signatures and splice_locked. But it is more future-proof to make that change, in case we later change our behavior to re-send tx_signatures even if the transaction was already published or confirmed.
When reconnecting in the middle of signing a splice, we must ensure that
splice_lockedis sent aftertx_signatures. Otherwise when using 0-conf we may retransmitsplice_lockedbeforetx_signatures, which our peer will ignore because they don't have a corresponding fully signed commitment.This may eventually lead to a mismatch where one side thinks that the splice has been locked and the other doesn't, so one side will send more signatures which results in a force-close.
It should never happen though, because we only send
splice_lockedonce the transaction has been published (zero-conf) or confirmed. Once that happened, we will never retransmittx_signatures(because we run into that condition), so we'll never mixtx_signaturesandsplice_locked. But it is more future-proof to make that change, in case we later change our behavior to re-sendtx_signatureseven if the transaction was already published or confirmed.