Batch exchange withdrawal to lightning requires covenants

In this email, the sender discusses their efforts to design a protocol for allowing users to withdraw funds from exchanges and deposit them directly into their lightning wallet with minimal on-chain footprint. They propose using covenants, specifically SIGHASH_ANYPREVOUT, to achieve this. The sender explains that the current method of enabling lightning withdrawals is flawed because it shifts the burden of making an on-chain transaction to the user's wallet provider. This often requires a splice transaction if the user does not have enough inbound liquidity, resulting in multiple separate splice transactions if multiple users withdraw funds from an exchange. To address this, the sender suggests batching these transactions into a single transaction without introducing any intermediate transactions. However, a challenge arises as signatures are required from each wallet user for each channel. The availability problem arises as these users may not be online simultaneously, and if one user fails to complete the protocol, the whole batch must be discarded. To overcome this, each wallet user can provide a signature using SIGHASH_SINGLE | SIGHASH_ANYONECANPAY to create a new funding output with the expected amount. This allows users to sign before knowing the final transaction, which the exchange can create by batching pairs of inputs and outputs. Nevertheless, this approach has a fatal flaw as the wallet user cannot spend the new funding output since it is also a 2-of-2 between the wallet user and the wallet provider. This opens the possibility of the wallet provider blackmailing the user to retrieve their funds. In the Lightning Network, this issue is resolved by exchanging signatures for a commitment transaction that returns the funds to their owners before signing the parent funding/splice transaction. However, in this scenario, the txid of the batch transaction is unknown, preventing the use of this solution. The sender mentions that they couldn't find a clever workaround for this problem and believes there might not be one. However, the SIGHASH_ANYPREVOUT covenant resolves this issue by allowing anyprevout signatures for the commitment transaction, making them valid to spend from the batch transaction. The sender also suggests that other forms of covenants likely address this problem as well.Overall, the email discusses the challenges faced in designing a protocol for lightning withdrawals from exchanges and proposes using covenants, specifically SIGHASH_ANYPREVOUT, to overcome these challenges.