Batch exchange withdrawal to lightning requires covenants

The email discusses the design of a protocol to enable users to withdraw funds from exchanges directly into their lightning wallet in an efficient manner. The author suggests that this can be achieved by utilizing covenants, specifically mentioning the effectiveness of SIGHASH_ANYPREVOUT. The purpose of the email is to explain the reasoning behind this approach and highlight it as a valuable use case for covenants.The current method of enabling lightning withdrawals involves the user providing a lightning invoice for the exchange to pay over lightning. However, this approach often shifts the burden of making an on-chain transaction to the user's wallet provider. If the user lacks sufficient inbound liquidity, a splice transaction will be necessary. In situations where multiple users withdraw funds from an exchange, multiple separate splice transactions may occur. To avoid this, the idea is proposed to batch these transactions into a single one without any intermediate steps.A challenge arises due to the need for signatures from each corresponding wallet user for each channel being spliced. These signatures are required because the current funding output is a 2-of-2 multisig between the wallet user and the wallet provider. However, the availability problem arises as these users may not be online simultaneously. If any user fails to come online or complete the protocol, the entire batch must be discarded.To address this issue, a workaround is suggested. Each wallet user can provide a signature using SIGHASH_SINGLE | SIGHASH_ANYONECANPAY to spend their current funding output and 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. However, this workaround introduces a significant problem: the wallet user has no means of spending the new funding output since it is also a 2-of-2 between the wallet user and the wallet provider. Consequently, the wallet provider can potentially blackmail the user and force them to pay in order to retrieve their funds.In the Lightning Network, this issue is typically resolved by exchanging signatures for a commitment transaction that sends the funds back to their owners before signing the parent funding/splice transaction. However, in this scenario, it is not feasible because the txid of the batch transaction is unknown at that point. The author admits to being unable to find a clever solution and believes there might not be one, but welcomes any alternative suggestions.The use of SIGHASH_ANYPREVOUT immediately resolves this problem. It allows for the exchange of anyprevout signatures for the commitment transaction, making them valid for spending from the batch transaction. The rotation of funding keys at each splice ensures that signature reuse is not an issue, as no other output will utilize the same 2-of-2 script. While the author has not explored other forms of covenants in detail, it is likely that most of them also address this problem.