Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 24FC2C0032; Thu, 19 Oct 2023 17:10:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id EEF0F6FC1B; Thu, 19 Oct 2023 17:10:05 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org EEF0F6FC1B Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=j3CLUNYe X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSa0h7hHU1yZ; Thu, 19 Oct 2023 17:10:04 +0000 (UTC) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) by smtp3.osuosl.org (Postfix) with ESMTPS id C95CE610CD; Thu, 19 Oct 2023 17:10:03 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org C95CE610CD Received: by mail-il1-x136.google.com with SMTP id e9e14a558f8ab-352a1a0348fso31515775ab.1; Thu, 19 Oct 2023 10:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697735403; x=1698340203; darn=lists.linuxfoundation.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=TlvXaJeWAf+ohNW/kGljx2TOHF9El082WknT0f27ZAk=; b=j3CLUNYe6oInJtqyZmnnKiNEUQluYZgeU8SZJVKOY7J+BeSEniOGFMHu5rZOJef5pL A54xhnMeWuYMA/C6hHz3lJtmcTImgqrRkGDd9kPg1FFFdot59uoGBGXjMVwqpNDroXRR zcB4lwnqfQh2TGVSfXzq7k5dofvyc0kVOllTuAt22xYwf32JyCCjbeaBidfW3xRW2aum yR6HyNvObCWJyaO1z8tWfJ9UtfwD16ynLx6UkUmZTPuUHwQE54LXnAenYbJrVdss70xZ IjIKYxIfb9XOOlPcIAYrCGY4AipdA2d/3YSDxIyRYxXsOjz1wTAfNLonhav0E2LVxtqt DpMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697735403; x=1698340203; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TlvXaJeWAf+ohNW/kGljx2TOHF9El082WknT0f27ZAk=; b=sRCXbbB+C2+GoVUwqa386yFTuYlP+tbKrCbpHEJ+6U2Yb2oNSgNFCJZAndhFIdGuvU Ylg37aTqtBJKkMZ8H3IJbWYrMUJ7NHwb1lr6u9vI8/Ln31TDyG2ttFd9jaARsKTQlaI+ LJZtu5kXmATWuxGbDRgVlqS7GEmVA56yf+q/rYBt3P+XFkL3Y/R9M3QUat2sYieNXBds C6bWN4+7zG8zA5eyLnkkXDcz2QRTshtFRtws8JtI0DGDG2q8AqyqJNPZnG8nqzKO+ZEi DPBBDTUnhbofmtnFKGp5Er2orjM2MK/mBNycjelg1gPV/hXkrDCb/7qk3JTi2NKqp1MX Pl4Q== X-Gm-Message-State: AOJu0Yx36xiisk24DIjKPz85MwC2qEtlsCH9k/zHY6t4VX7p++gvzZxE 79sXfiisqMrdmjYbn3GHf3LT2oNKCjte94vq+7eyGl1cW3mxSQ== X-Google-Smtp-Source: AGHT+IGHk5dkk7RsEhBMtoCozZ1SqwnYdWD3GIEom2InnckaYkFavfTDciujwC+KPBIpT5LFV4aLG2rLZqCkWoHeJ9M= X-Received: by 2002:a92:d90e:0:b0:34f:9f86:dd45 with SMTP id s14-20020a92d90e000000b0034f9f86dd45mr2882079iln.3.1697735402534; Thu, 19 Oct 2023 10:10:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Thu, 19 Oct 2023 18:09:51 +0100 Message-ID: To: Bastien TEINTURIER Content-Type: multipart/alternative; boundary="000000000000973b90060814d314" X-Mailman-Approved-At: Thu, 19 Oct 2023 21:52:02 +0000 Cc: Bitcoin Protocol Discussion , "lightning-dev\\\\@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] [Lightning-dev] Batch exchange withdrawal to lightning requires covenants X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2023 17:10:06 -0000 --000000000000973b90060814d314 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=3D3 and pay 0 fees. On the contrar= y > this is a "standard" transaction that should use a reasonable feerate > and nVersion=3D2, that's why I don't think this comment applies. Under this model where the splice should be a "standard" nVersion=3D2 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 =C3=A0 08:35, Bastien TEINTURIER a =C3=A9crit : > 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=3D3 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=3D3 and pay 0 fees. On the contrar= y > this is a "standard" transaction that should use a reasonable feerate > and nVersion=3D2, that's why I don't think this comment applies. > > Cheers, > Bastien > > Le mer. 18 oct. 2023 =C3=A0 20:04, Antoine Riard a > =C3=A9crit : > >> Hi Bastien, >> >> Thanks for the answer. >> >> If I understand correctly the protocol you're describing you're aiming t= o >> enable batched withdrawals where a list of users are being sent funds fr= om >> 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 broadcastin= g >> 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=3D3 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/19d61fa8cf22a5050b51c4005603f43= d72f1efcf >> >> 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 fund= ing >> outputs are shared with a LSP, malicious collusion is less plausible. >> >> Best, >> Antoine >> >> Le mer. 18 oct. 2023 =C3=A0 15:35, Bastien TEINTURIER = a >> =C3=A9crit : >> >>> 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 an= d >>> 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, bu= t >>> 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 doubl= e >>> 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=3D3, is robust enough for >>> > multi-party transactions and covenant-enable constructions under usua= l >>> > 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 transaction= s >>> 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/19d61fa8cf22a5050b51c4005603f4= 3d72f1efcf >>> >>> 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 =C3=A0 21:10, Antoine Riard a >>> =C3=A9crit : >>> >>>> Hi Bastien, >>>> >>>> > The naive way of enabling lightning withdrawals is to make the user >>>> > provide a lightning invoice that the exchange pays over lightning. T= he >>>> > 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 transactio= n >>>> > will be necessary. If N users withdraw funds from an exchange, we mo= st >>>> > 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=3D3, is robust enough for >>>> multi-party transactions and covenant-enable constructions under usual= risk >>>> models. >>>> >>>> See test here: >>>> >>>> https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f= 43d72f1efcf >>>> >>>> Appreciated expert eyes of folks understanding both lightning and core >>>> mempool on this. >>>> There was a lot of back and forth on nversion=3D3 design rules, though >>>> the test is normally built on glozow top commit of the 3 Oct 2023. >>>> >>>> Best, >>>> Antoine >>>> >>>> Le mar. 17 oct. 2023 =C3=A0 14:03, Bastien TEINTURIER a >>>> =C3=A9crit : >>>> >>>>> Good morning list, >>>>> >>>>> I've been trying to design a protocol to let users withdraw funds fro= m >>>>> 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). T= he >>>>> 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. Th= e >>>>> 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 mos= t >>>>> 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 th= e >>>>> 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 ne= ed >>>>> signatures from N users who may not be online at the same time, and i= f >>>>> one of those users never comes online or doesn't complete the protoco= l, >>>>> we must discard the whole batch. >>>>> >>>>> There is a workaround though: each wallet user can provide a signatur= e >>>>> using `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` that spends their curre= nt >>>>> funding output to create a new funding output with the expected amoun= t. >>>>> This lets users sign *before* knowing the final transaction, which th= e >>>>> 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 t= he >>>>> 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 commitme= nt >>>>> transaction that sends the funds back to their owners *before* signin= g >>>>> 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 b= e >>>>> valid to spend from the batch transaction. We are safe from signature >>>>> reuse, because funding keys are rotated at each splice so we will nev= er >>>>> 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 >>>>> >>>> --000000000000973b90060814d314 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bastien,

Thanks for your additional = comments.

> Yes, they can, and any user could a= lso double-spend the batch using a
> commit tx spending from the prev= ious 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 regul= ar 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 pa= rticipant 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 channel= s.

> I don't think this should use nVersion= =3D3 and pay 0 fees. On the contrary
> this is a "standard"= transaction that should use a reasonable feerate
> and nVersion=3D2,= that's why I don't think this comment applies.

<= /div>
Under this model where the splice should be a "standard"= ; nVersion=3D2 transaction that is using a reasonable feerate for non-delay= ed broadcast, yes my comment does not apply, agree here.

However for a hypothetical=C2=A0future, 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 r= e-broadcasting the batch splice tx package with a bumped CPFP, might be aff= ected by my concern if it is correct. To be verified.

<= div>Best,
Antoine

Le=C2=A0jeu. 19 oct. 2023 =C3=A0=C2=A008:3= 5, Bastien TEINTURIER <bastien@acinq= .fr> a =C3=A9crit=C2=A0:
= Hi Antoine,

> If I'm correct, two users can cooperate malicio= usly against the batch
> withdrawal transactions by re-signing a CPFP= from 2-of-2 and
> broadcasting the batch withdrawal as a higher-feer= ate package / high
> fee package and then evicting out the CPFP.
<= br>Yes, they can, and any user could also double-spend the batch using acommit tx spending from the previous funding output. Participants must
= expect that this may happen, that's what I mentioned previously thatyou 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=3D3 policy exemption, it will be evicted out of the mempool= .
> A variant of a replacement cycling attack.

I don't thi= nk this should use nVersion=3D3 and pay 0 fees. On the contrary
this is = a "standard" transaction that should use a reasonable feerate
= and nVersion=3D2, that's why I don't think this comment applies.
Cheers,
Bastien

Le=C2=A0mer. 18 oct. 2023 =C3=A0=C2=A020:04, Ant= oine Riard <antoine.riard@gmail.com> a =C3=A9crit=C2=A0:
Hi Bastien,

Thanks for the answer.<= /div>

If I understand correctly the protocol=C2=A0you= 9;re describing=C2=A0you'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 o= utputs 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 malic= iously 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.=C2=A0

=
If the batch withdrawal has been signed with 0-fee thanks to the nvers= ion=3D3 policy exemption, it will be evicted out of the=C2=A0mempool. A var= iant of a replacement cycling attack.

I think this= more or less=C2=A0matches the test I'm pointing to you which is on non= -deployed package acceptance code:

Please correct me if I'm= wrong or missing assumptions. Agree with you on the assumptions that the e= xchange does not have an incentive to double-spend its own withdrawal trans= actions, or if all the batched funding outputs are shared with a LSP, malic= ious collusion is less plausible.

Best,
= Antoine

Le=C2=A0mer. 18 oct. 2023 =C3=A0=C2=A015:35, Bastien TEINTURIE= R <bastien@acinq.f= r> a =C3=A9crit=C2=A0:
He= y Z-man, Antoine,

Thank you for your feedback, responses inline.
=
z-man:

> Then if I participate in a batched splice, I can dis= rupt the batched
> splice by broadcasting the old state and somehow c= onvincing miners to
> confirm it before the batched splice.

Co= rrect, I didn't mention it in my post but batched splices cannot use0-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
br= oadcast the batched splice transaction while users are offline. With a
b= it of luck, when the users reconnect, that transaction will already be
c= onfirmed so it will "feel 0-conf".

Also, we need a mechani= sm like the one you describe when we detect that
a splice transaction ha= s been double-spent. But this isn't specific to
batched transactions= , 2-party splice transactions can also be double
spent by either partici= pant. 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 shoul= d not be spliced again, which your proposal seems to violate.

The sp= ec 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 doublespends the other unconfirmed splice attempts.

ariard:

> I= t is uncertain to me if secure fee-bumping, even with future
> mechan= isms like package relay and nversion=3D3, is robust enough for
> mult= i-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 thos= e batched transactions
we will need to rely on CPFP and potentially pack= age relay. But why is
it different from non-multi-party transactions her= e?

> See test here:
> = https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72= f1efcf

I'd argue that this is quite different from the stand= ard replacement
cycling attack, because in this protocol wallet users ca= n 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 stealin= g funds?

Thanks,
Bastien

=
Le=C2=A0mar. 17 oct. 2023 =C3=A0=C2= =A021:10, Antoine Riard <antoine.riard@gmail.com> a =C3=A9crit=C2=A0:
=
Hi Bastien,

> The n= aive way of enabling lightning withdrawals is to make the user
> prov= ide 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 do= esn't
> have enough inbound liquidity (which is likely), a splice= transaction
> will be necessary. If N users withdraw funds from an e= xchange, we most
> likely will end up with N separate splice transact= ions.

It is uncertain to me if secure fee-bump= ing, even with future mechanisms like package relay and=C2=A0nversion=3D3, = is robust enough for multi-party transactions and covenant-enable construct= ions under usual risk models.

See test here:
=

Appreciated expert eyes of folks understanding both lightning and co= re mempool on this.
There was a lot of back and forth on nversion= =3D3 design rules, though the test is normally built on glozow top commit o= f the 3 Oct 2023.

Best,
Antoine

Le= =C2=A0mar. 17 oct. 2023 =C3=A0=C2=A014:03, Bastien TEINTURIER <bastien@acinq.fr> a = =C3=A9crit=C2=A0:
Good morning l= ist,

I've been trying to design a protocol to let users withdraw= funds from
exchanges directly into their lightning wallet in an efficie= nt way
(with the smallest on-chain footprint possible).

I've = come to the conclusion that this is only possible with some form of
cove= nants (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
use= ful things we could do if we had covenants (insert "wen APO?" mem= e).

The naive way of enabling lightning withdrawals is to make the u= ser
provide a lightning invoice that the exchange pays over lightning. T= he
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 d= oesn't
have enough inbound liquidity (which is likely), a splice tra= nsaction
will be necessary. If N users withdraw funds from an exchange, = we most
likely will end up with N separate splice transactions.

H= ence the idea of batching those into a single transaction. Since we
don&= #39;t want to introduce any intermediate transaction, we must be able
to= create one transaction that splices multiple channels at once. The
issu= e is that for each of these channels, we need a signature from the
corre= sponding wallet user, because we're spending the current funding
out= put, which is a 2-of-2 multisig between the wallet user and the
wallet p= rovider. So we run into the usual availability problem: we need
signatur= es from N users who may not be online at the same time, and if
one of th= ose users never comes online or doesn't complete the protocol,
we mu= st discard the whole batch.

There is a workaround though: each walle= t user can provide a signature
using `SIGHASH_SINGLE | SIGHASH_ANYONECAN= PAY` that spends their current
funding output to create a new funding ou= tput with the expected amount.
This lets users sign *before* knowing the= final transaction, which the
exchange can create by batching pairs of i= nputs/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 commi= tment
transaction that sends the funds back to their owners *before* sig= ning
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 b= atch)
so we don't know the new `prevout` we should spend from. I cou= ldn't find
a clever way to work around that, and I don't think t= here is one (but
I would be happy to be wrong).

With `SIGHASH_ANY= PREVOUT`, this is immediately fixed: we can exchange
anyprevout signatur= es 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 form= s 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/ma= ilman/listinfo/lightning-dev
--000000000000973b90060814d314--