Hey Z-man, Antoine, Thank you for your feedback, responses inline.
z-man: > Then if I participate in a batched splice, I can disrupt the batched > splice by broadcasting the old state and somehow convincing miners to > confirm it before the batched splice. Correct, I didn't mention it in my post but batched splices cannot use 0-conf, the transaction must be confirmed to remove the risk of double spends using commit txs associated with the previous funding tx. But interestingly, with the protocol I drafted, the LSP can finalize and broadcast the batched splice transaction while users are offline. With a bit of luck, when the users reconnect, that transaction will already be confirmed so it will "feel 0-conf". Also, we need a mechanism like the one you describe when we detect that a splice transaction has been double-spent. But this isn't specific to batched transactions, 2-party splice transactions can also be double spent by either participant. So we need that mechanism anyway? The spec doesn't have a way of aborting a splice after exchanging signatures, but you can always do it as an RBF operation (which actually just does a completely different splice). This is what Greg mentioned in his answer. > part of the splice proposal is that while a channel is being spliced, > it should not be spliced again, which your proposal seems to violate. The spec doesn't require that, I'm not sure what made you think that. While a channel is being spliced, it can definitely be spliced again as an RBF attempt (this is actually a very important feature), which double spends the other unconfirmed splice attempts. ariard: > 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. I'm not entirely sure why you're bringing this up in this context... I agree that we most likely cannot use RBF on those batched transactions we will need to rely on CPFP and potentially package relay. But why is it different from non-multi-party transactions here? > See test here: > https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf I'd argue that this is quite different from the standard replacement cycling attack, because in this protocol wallet users can only unilaterally double-spend with a commit tx, on which they cannot set the feerate. The only participant that can "easily" double-spend is the exchange, and they wouldn't have an incentive to here, users are only withdrawing funds, there's no opportunity of stealing funds? Thanks, Bastien Le mar. 17 oct. 2023 à 21:10, Antoine Riard <antoine.ri...@gmail.com> a écrit : > 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-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
