Batch exchange withdrawal to lightning requires covenants

Antoine acknowledges Bastien's proposed protocol for batched splices but raises a concern about the feasibility of interactive re-generation of a bumped Replace-By-Fee (RBF) transaction in a hypothetical scenario with mempool spikes. Antoine suggests further verification is required regarding re-broadcasting the batch splice transaction package with a bumped Child Pays for Parent (CPFP). Antoine also confirms the understanding that participants can potentially double spend the batch using a commit transaction but clarifies that this should not be done for the splice transaction. He agrees with Bastien's suggestion to use a "standard" transaction for the splice transaction with a reasonable feerate and nVersion=2.

The email proposes a solution for reducing on-chain transaction size by avoiding settlement transactions and generating only one transaction. It discusses the possibility of using swap-in-potentiam (SiP) as an option and mentions its use in Eclair. The email shares a link for further information on SiP. It also discusses a protocol described by Bastien for batched withdrawals and raises a concern about the possibility of malicious cooperation against the batch withdrawal transactions, resulting in a replacement cycling attack. The email addresses the difference between multi-party and non-multi-party transactions in this context.

Antoine raises concerns about the robustness of secure fee-bumping in multi-party transactions and covenant-enable constructions. They share a test on GitHub and request input from experts familiar with lightning and core mempool. ZmnSCPxj warns Greg about the risk of "not confirming" due to unexpected mempool usage and highlights the possibility of a previous splice transaction eventually confirming instead of the subsequent splice, leading to potential loss of funds if commitment transaction signatures are deleted. ZmnSCPxj also discusses the core risk associated with batched splicing mechanisms in the Lightning Network and emphasizes the need for a backout mechanism in batched splicing. They raise concerns about existing splice implementations and the risks involved.

ZmnSCPxj explains the design of a protocol to withdraw funds from exchanges directly into a lightning wallet using covenants. They mention the effectiveness of SIGHASH_ANYPREVOUT and propose batching multiple splice transactions into a single one without intermediate steps. They discuss the challenge of obtaining signatures from each wallet user and suggest a workaround using SIGHASH_SINGLE | SIGHASH_ANYONECANPAY. However, they mention the risk of the wallet provider potentially blackmailing the user. The author invites alternative suggestions and presents the use of SIGHASH_ANYPREVOUT as a resolution to allow exchanging anyprevout signatures for the commitment transaction.

The emails cover various topics related to multi-party transactions, covenant-enable constructions, risks in batched splicing mechanisms, and the design of a protocol for efficient lightning withdrawals from exchanges.