Batch exchange withdrawal to lightning requires covenants

In the email, ZmnSCPxj discusses the risk associated with batched splicing mechanisms in Lightning Network channels. The core of the risk lies in the scenario where there are no funds in a channel and an old state exists. In such cases, if a participant engages in a batched splice, they can disrupt the transaction by broadcasting the old state and convincing miners to confirm it before the batched splice.To mitigate this risk, ZmnSCPxj suggests that any batched splicing mechanism should have a backout option. This means that if the batched splice transaction cannot be confirmed due to a participant posting an old commitment transaction, either a subset of the splice is re-created or the channels revert back to the pre-splice state. It is important to note that the post-splice state cannot be confirmed in this scenario.ZmnSCPxj acknowledges that current splicing technology runs both the pre-splice and post-splice states simultaneously until the splicing transaction is confirmed. However, it is also necessary to check if the splicing transaction cannot be confirmed by verifying if the other inputs to the splice transaction were already consumed by transactions that have deeply confirmed. If this is the case, the post-splice state should be dropped, and the channels should revert to the pre-splice state. It is unclear whether existing splice implementations actually perform this check.In conclusion, ZmnSCPxj highlights the importance of having a backout option in batched splicing mechanisms to address the risk of disruption caused by old commitment transactions. Without such precautions, any form of batched splicing can be risky.