Batch exchange withdrawal to lightning requires covenants

There is a potential risk associated with the reason for "not confirming" in the context mentioned. This risk arises from an unexpected increase in mempool usage. It is important to consider that if the attack is not being performed, there is a possibility that the previous splice transaction, which was not confirming for a while, may end up confirming instead of the subsequent splice transaction. Although this is an edge case, it could be targeted and result in the loss of funds if implementations delete the signatures for commitment transactions for the previously-not-confirming splice transaction without considering this scenario. It is worth noting that part of the splice proposal suggests that a channel should not be spliced again while it is already being spliced, which the mentioned proposal seems to violate.

Please let me know if you need any further information or clarification.