Batch exchange withdrawal to lightning requires covenants

The email begins with a warning about the risk of "not confirming" due to an unexpected increase in mempool usage. The author mentions that if the attack is not being performed, there is a possibility that the previous splice transaction, which was not confirming for a while, could end up confirming instead of the subsequent splice. This edge case could potentially be targeted by attackers and result in the loss of funds if implementations naively delete the signatures for commitment transactions related to the previously-not-confirming splice transaction.

The author then brings up the point that part of the splice proposal is that a channel should not be spliced again while it is already being spliced. The proposal put forward by Greg seems to violate this aspect of the splice proposal.

Overall, the email highlights the potential risks and concerns related to the confirmation process and the implementation of the splice transaction. It emphasizes the importance of considering edge cases and potential attacks to ensure the security of funds.