Batched Splicing Considered Risky

This process becomes crucial when considering the dynamics of unconfirmed splice transactions within a channel. Specifically, when such a transaction is double spent by an unrelated transaction not aimed at splicing for that channel, it introduces a scenario where the existing systems lack a formal mechanism for its removal from the pending splice transaction list. However, this perceived limitation is argued against on the grounds of unnecessary complexity.

The stance taken suggests a different approach where the splice transaction, despite being double spent, remains within the list of pending splice transactions. The proposal advocates for sending a commit_sig for the affected transaction whenever the channel is utilized. This method is highlighted as having minimal overhead, offering a streamlined solution to the issue at hand. Furthermore, it assures an automatic cleanup of the splice transaction once another splice transaction successfully confirms. This approach simplifies the operational framework while effectively addressing the challenge posed by double spends in the context of unconfirmed splice transactions.