Batch exchange withdrawal to lightning requires covenants

In the email thread, the discussion revolves around different aspects of batched splice transactions and the need for a mechanism to handle double-spending. The sender acknowledges that batched splices cannot use 0-conf and explains that the protocol allows the LSP to finalize and broadcast the batched splice transaction while users are offline. This gives the transaction a "feel" of being 0-conf when the users reconnect.

The need for a mechanism to detect and handle double-spent splice transactions is highlighted, but it is mentioned that this is not specific to batched transactions. Even 2-party splice transactions can be double-spent by either participant. The sender suggests using an RBF operation to abort a splice after exchanging signatures, but clarifies that the current spec does not require it.

The sender also mentions that during the process of splicing a channel, it can be spliced again as an RBF attempt, which effectively double spends the other unconfirmed splice attempts. This is seen as an important feature. Another participant raises the question of whether RBF can be used on batched transactions, to which the sender agrees that it may not be possible and suggests relying on CPFP and potentially package relay instead.

A link to a commit in the GitHub repository is provided, where further details about the context can be found. There is some discussion about the difference between the standard replacement cycling attack and the scenario in this protocol, where wallet users can only unilaterally double-spend with a commit tx. It is argued that the exchange, which has the ability to easily double-spend, would not have an incentive to do so in this case since users are only withdrawing funds and there is no opportunity to steal funds.

Overall, the email thread delves into the intricacies of batched splice transactions, the potential risks of double-spending, and the need for mechanisms to address these issues. The participants provide insights and discuss various approaches to handle double-spending, including the use of RBF, CPFP, and package relay.