Batch exchange withdrawal to lightning requires covenants

In the email, there is a discussion about batched splices and their use of 0-conf transactions. It is mentioned that batched splices cannot use 0-conf and that the transaction must be confirmed to remove the risk of double spends. The writer also mentions a drafted protocol where the LSP can finalize and broadcast the batched splice transaction while users are offline, making it feel like a 0-conf transaction when users reconnect. The email also brings up the need for a mechanism to detect double-spent splice transactions, noting that this is not specific to batched transactions but also applies to 2-party splice transactions. The spec does not have a way to abort a splice after exchanging signatures, but it can be done as an RBF operation. The writer agrees with this approach and mentions that a channel being spliced can be spliced again as an RBF attempt, which double spends the other unconfirmed splice attempts.There is some confusion in the email about the use of RBF on batched transactions compared to non-multi-party transactions. The writer argues that using RBF on batched transactions may not be possible and suggests relying on CPFP and potentially package relay instead. They provide a link to a commit on GitHub for further reference.Additionally, the writer mentions that the protocol being discussed is different from the standard replacement cycling attack because wallet users can only unilaterally double-spend with a commit tx, on which they cannot set the feerate. The only participant that can easily double-spend is the exchange, but they wouldn't have an incentive to do so in this case since users are only withdrawing funds.Overall, the email covers various topics related to batched splices, including the use of 0-conf transactions, mechanisms for detecting double-spent transactions, the possibility of using RBF, and the differences between the discussed protocol and the standard replacement cycling attack.