Batch exchange withdrawal to lightning requires covenants

The email discusses a potential risk related to the "not confirming" status of a splice transaction. It mentions that there is a possibility that the reason for "not confirming" could be due to an unexpected increase in mempool usage. The author highlights an edge case where a previous splice transaction that was not confirming for a while could end up confirming instead of the subsequent splice transaction.This situation could be exploited by attackers, and if implementations naively delete the signatures for commitment transactions for the previously-not-confirming splice transaction, it could result in a loss of funds. The author also points out that part of the splice proposal is that a channel should not be spliced again while it is being spliced, which the recipient's proposal seems to violate.Overall, the email raises concerns about the potential vulnerability and suggests that precautions should be taken to address this risk.Note: The farewell part of the email has been ignored as per the given rules.