Re: [bitcoin-dev] [Lightning-dev] Batch exchange withdrawal to lightning requires covenants
Hi Bastien,
Thanks for your additional comments.
> Yes, they can, and any user could also double-spend the batch using a
> commit tx spending from the previous funding output. Participants must
> expect that this may happen, that's what I mentioned previously that
> you cannot use 0-conf on that splice transaction. But apart from that,
> it acts as a regular splice: participants must watch for double-spends
> (as discussed in the previous messages) while waiting for confirmations.
Understood better, it's like a regular splice where one participant might
be able to double-spend at any time with a previous commit tx. So yes,
usual liquidity griefing we're already aware of I think and where one
should wait for a few confirmations before using spawned channels.
> I don't think this should use nVersion=3 and pay 0 fees. On the contrary
> this is a "standard" transaction that should use a reasonable feerate
> and nVersion=2, that's why I don't think this comment applies.
Under this model where the splice should be a "standard" nVersion=2
transaction that is using a reasonable feerate for non-delayed broadcast,
yes my comment does not apply, agree here.
However for a hypothetical future, where the picked up feerate of the batch
splicing isn't compelling enough in face of mempool spikes, interactivity
to re-generate a bumped RBF might not be an option. Sadly re-broadcasting
the batch splice tx package with a bumped CPFP, might be affected by my
concern if it is correct. To be verified.
Best,
Antoine
Le jeu. 19 oct. 2023 à 08:35, Bastien TEINTURIER a
écrit :
> Hi Antoine,
>
> > If I'm correct, two users can cooperate maliciously against the batch
> > withdrawal transactions by re-signing a CPFP from 2-of-2 and
> > broadcasting the batch withdrawal as a higher-feerate package / high
> > fee package and then evicting out the CPFP.
>
> Yes, they can, and any user could also double-spend the batch using a
> commit tx spending from the previous funding output. Participants must
> expect that this may happen, that's what I mentioned previously that
> you cannot use 0-conf on that splice transaction. But apart from that,
> it acts as a regular splice: participants must watch for double-spends
> (as discussed in the previous messages) while waiting for confirmations.
>
> > If the batch withdrawal has been signed with 0-fee thanks to the
> > nversion=3 policy exemption, it will be evicted out of the mempool.
> > A variant of a replacement cycling attack.
>
> I don't think this should use nVersion=3 and pay 0 fees. On the contrary
> this is a "standard" transaction that should use a reasonable feerate
> and nVersion=2, that's why I don't think this comment applies.
>
> Cheers,
> Bastien
>
> Le mer. 18 oct. 2023 à 20:04, Antoine Riard a
> écrit :
>
>> Hi Bastien,
>>
>> Thanks for the answer.
>>
>> If I understand correctly the protocol you're describing you're aiming to
>> enable batched withdrawals where a list of users are being sent funds from
>> an exchange directly in a list of channel funding outputs ("splice-out").
>> Those channels funding outputs are 2-of-2, between two lambda users or e.g
>> a lambda user and a LSP.
>>
>> If I'm correct, two users can cooperate maliciously against the batch
>> withdrawal transactions by re-signing a CPFP from 2-of-2 and broadcasting
>> the batch withdrawal as a higher-feerate package / high fee package and
>> then evicting out the CPFP.
>>
>> If the batch withdrawal has been signed with 0-fee thanks to the
>> nversion=3 policy exemption, it will be evicted out of the mempool. A
>> variant of a replacement cycling attack.
>>
>> I think this more or less matches the test I'm pointing to you which is
>> on non-deployed package acceptance code:
>>
>> https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf
>>
>> Please correct me if I'm wrong or missing assumptions. Agree with you on
>> the assumptions that the exchange does not have an incentive to
>> double-spend its own withdrawal transactions, or if all the batched funding
>> outputs are shared with a LSP, malicious collusion is less plausible.
>>
>> Best,
>> Antoine
>>
>> Le mer. 18 oct. 2023 à 15:35, Bastien TEINTURIER a
>> écrit :
>>
>>> 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
Re: [bitcoin-dev] [Lightning-dev] Batch exchange withdrawal to lightning requires covenants
Hi Antoine,
> If I'm correct, two users can cooperate maliciously against the batch
> withdrawal transactions by re-signing a CPFP from 2-of-2 and
> broadcasting the batch withdrawal as a higher-feerate package / high
> fee package and then evicting out the CPFP.
Yes, they can, and any user could also double-spend the batch using a
commit tx spending from the previous funding output. Participants must
expect that this may happen, that's what I mentioned previously that
you cannot use 0-conf on that splice transaction. But apart from that,
it acts as a regular splice: participants must watch for double-spends
(as discussed in the previous messages) while waiting for confirmations.
> If the batch withdrawal has been signed with 0-fee thanks to the
> nversion=3 policy exemption, it will be evicted out of the mempool.
> A variant of a replacement cycling attack.
I don't think this should use nVersion=3 and pay 0 fees. On the contrary
this is a "standard" transaction that should use a reasonable feerate
and nVersion=2, that's why I don't think this comment applies.
Cheers,
Bastien
Le mer. 18 oct. 2023 à 20:04, Antoine Riard a
écrit :
> Hi Bastien,
>
> Thanks for the answer.
>
> If I understand correctly the protocol you're describing you're aiming to
> enable batched withdrawals where a list of users are being sent funds from
> an exchange directly in a list of channel funding outputs ("splice-out").
> Those channels funding outputs are 2-of-2, between two lambda users or e.g
> a lambda user and a LSP.
>
> If I'm correct, two users can cooperate maliciously against the batch
> withdrawal transactions by re-signing a CPFP from 2-of-2 and broadcasting
> the batch withdrawal as a higher-feerate package / high fee package and
> then evicting out the CPFP.
>
> If the batch withdrawal has been signed with 0-fee thanks to the
> nversion=3 policy exemption, it will be evicted out of the mempool. A
> variant of a replacement cycling attack.
>
> I think this more or less matches the test I'm pointing to you which is on
> non-deployed package acceptance code:
>
> https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf
>
> Please correct me if I'm wrong or missing assumptions. Agree with you on
> the assumptions that the exchange does not have an incentive to
> double-spend its own withdrawal transactions, or if all the batched funding
> outputs are shared with a LSP, malicious collusion is less plausible.
>
> Best,
> Antoine
>
> Le mer. 18 oct. 2023 à 15:35, Bastien TEINTURIER a
> écrit :
>
>> 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
Re: [bitcoin-dev] [Lightning-dev] Batch exchange withdrawal to lightning requires covenants
Hi Bastien,
Thanks for the answer.
If I understand correctly the protocol you're describing you're aiming to
enable batched withdrawals where a list of users are being sent funds from
an exchange directly in a list of channel funding outputs ("splice-out").
Those channels funding outputs are 2-of-2, between two lambda users or e.g
a lambda user and a LSP.
If I'm correct, two users can cooperate maliciously against the batch
withdrawal transactions by re-signing a CPFP from 2-of-2 and broadcasting
the batch withdrawal as a higher-feerate package / high fee package and
then evicting out the CPFP.
If the batch withdrawal has been signed with 0-fee thanks to the nversion=3
policy exemption, it will be evicted out of the mempool. A variant of a
replacement cycling attack.
I think this more or less matches the test I'm pointing to you which is on
non-deployed package acceptance code:
https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf
Please correct me if I'm wrong or missing assumptions. Agree with you on
the assumptions that the exchange does not have an incentive to
double-spend its own withdrawal transactions, or if all the batched funding
outputs are shared with a LSP, malicious collusion is less plausible.
Best,
Antoine
Le mer. 18 oct. 2023 à 15:35, Bastien TEINTURIER a
écrit :
> 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 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:
>>
>>
Re: [bitcoin-dev] [Lightning-dev] Batch exchange withdrawal to lightning requires covenants
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 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 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
Re: [bitcoin-dev] [Lightning-dev] Batch exchange withdrawal to lightning requires covenants
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 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
