Hi Bastien, > The naive way of enabling lightning withdrawals is to make the user > provide a lightning invoice that the exchange pays over lightning. The > issue is that in most cases, this simply shifts the burden of making an > on-chain transaction to the user's wallet provider: if the user doesn't > have enough inbound liquidity (which is likely), a splice transaction > will be necessary. If N users withdraw funds from an exchange, we most > likely will end up with N separate splice transactions.
It is uncertain to me if secure fee-bumping, even with future mechanisms like package relay and nversion=3, is robust enough for multi-party transactions and covenant-enable constructions under usual risk models. See test here: https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf Appreciated expert eyes of folks understanding both lightning and core mempool on this. There was a lot of back and forth on nversion=3 design rules, though the test is normally built on glozow top commit of the 3 Oct 2023. Best, Antoine Le mar. 17 oct. 2023 à 14:03, Bastien TEINTURIER <bast...@acinq.fr> a écrit : > Good morning list, > > I've been trying to design a protocol to let users withdraw funds from > exchanges directly into their lightning wallet in an efficient way > (with the smallest on-chain footprint possible). > > I've come to the conclusion that this is only possible with some form of > covenants (e.g. `SIGHASH_ANYPREVOUT` would work fine in this case). The > goal of this post is to explain why, and add this usecase to the list of > useful things we could do if we had covenants (insert "wen APO?" meme). > > The naive way of enabling lightning withdrawals is to make the user > provide a lightning invoice that the exchange pays over lightning. The > issue is that in most cases, this simply shifts the burden of making an > on-chain transaction to the user's wallet provider: if the user doesn't > have enough inbound liquidity (which is likely), a splice transaction > will be necessary. If N users withdraw funds from an exchange, we most > likely will end up with N separate splice transactions. > > Hence the idea of batching those into a single transaction. Since we > don't want to introduce any intermediate transaction, we must be able > to create one transaction that splices multiple channels at once. The > issue is that for each of these channels, we need a signature from the > corresponding wallet user, because we're spending the current funding > output, which is a 2-of-2 multisig between the wallet user and the > wallet provider. So we run into the usual availability problem: we need > signatures from N users who may not be online at the same time, and if > one of those users never comes online or doesn't complete the protocol, > we must discard the whole batch. > > There is a workaround though: each wallet user can provide a signature > using `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` that spends their current > funding output to create a new funding output with the expected amount. > This lets users sign *before* knowing the final transaction, which the > exchange can create by batching pairs of inputs/outputs. But this has > a fatal issue: at that point the wallet user has no way of spending the > new funding output (since it is also a 2-of-2 between the wallet user > and the wallet provider). The wallet provider can now blackmail the user > and force them to pay to get their funds back. > > Lightning normally fixes this by exchanging signatures for a commitment > transaction that sends the funds back to their owners *before* signing > the parent funding/splice transaction. But here that is impossible, > because we don't know yet the `txid` of the batch transaction (that's > the whole point, we want to be able to sign before creating the batch) > so we don't know the new `prevout` we should spend from. I couldn't find > a clever way to work around that, and I don't think there is one (but > I would be happy to be wrong). > > With `SIGHASH_ANYPREVOUT`, this is immediately fixed: we can exchange > anyprevout signatures for the commitment transaction, and they will be > valid to spend from the batch transaction. We are safe from signature > reuse, because funding keys are rotated at each splice so we will never > create another output that uses the same 2-of-2 script. > > I haven't looked at other forms of covenants, but most of them likely > address this problem as well. > > Cheers, > Bastien > _______________________________________________ > Lightning-dev mailing list > lightning-...@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
