path: root/44/731235af9b4cfb6cde327300a0a39aa84342f2

Return-Path: <bastien.teinturier@acinq.fr>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 76634C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 19 Oct 2023 07:35:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 3F74D60E2E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 19 Oct 2023 07:35:40 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 3F74D60E2E
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=acinq.fr header.i=@acinq.fr
 header.a=rsa-sha256 header.s=google header.b=GJBTkiRm
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level: 
X-Spam-Status: No, score=-2.088 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, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01]
 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 H3UBTSlyFk81
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 19 Oct 2023 07:35:38 +0000 (UTC)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com
 [IPv6:2a00:1450:4864:20::12b])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 1C6A960BD2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 19 Oct 2023 07:35:38 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 1C6A960BD2
Received: by mail-lf1-x12b.google.com with SMTP id
 2adb3069b0e04-507a3b8b113so6876400e87.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 19 Oct 2023 00:35:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=acinq.fr; s=google; t=1697700936; x=1698305736;
 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=YyuAl06DOLUDY6QmHxOYv050jrOXopuwEw0vN08lMY0=;
 b=GJBTkiRmJ0UgDKDif0YsDKJ02cv5IpnjiJ0pAHDCT5Ai6fYwOq2IizkLsPT1Pvulan
 1VlDLnHv63HhgDf79zjCHXa+InHCyRkmG6JBRD7qML5CmHidfuvVFy/QOPz3mxEUMiql
 zJPS73I1O2VivacrZd3LoPzHRNSAzcQel8dkaHGgXmMtNGHcPJObkT4aHbUzHyvuzXHl
 bX/xBx++IMfQYzwXnNESZhF9aTepR19dF8ugWS6sYn8nK6phjcNUXLNJI5M/MbqjqdeX
 fDMcnjZ7Ic2PWntUHytudJfeRX8fv4+dd3uU0GemRgm8dKKg4raZhHNMB9wkNMjZJMhr
 5Zwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1697700936; x=1698305736;
 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=YyuAl06DOLUDY6QmHxOYv050jrOXopuwEw0vN08lMY0=;
 b=ESJFcc/P7V0TArMR+2dCvhWZDkswZs2uBPNep/xXAkldu5nmpSCLSTXWeCqPHdJlOo
 CksM/i3iJGydNNn3nI8Wi0VE2ZF9iWvlx2Wlkzwf7XISd78/VosLsEckpJr0JBdW1qDY
 Mcggfm3aAFsDzefGdjdYzdmzDd0cmjiAbblfuAwIYnrK6H1IVHYSJyg2ePPC+rFz+3zM
 Gc22hjhdd79TLfLAbL6CRnIFK+957q7IeiL22aFW9+hQFTr2FSMAniBfOAkrTzPyO2MM
 vRrqHl5mCvnxFvJej++qr0Y1v8gfhFEXsQup0jrCdY4EGnbDagCdTUsTONKy10p+bRp3
 uzqg==
X-Gm-Message-State: AOJu0YwB5JMNiTvm1DPLsYfBL5ItD+6GNJHCEYZi6uB/JTXmqmXQWeLC
 lO07OFw8wEnl2kXzjC4x/Ul1R0K6FjfUYIZksctU9g==
X-Google-Smtp-Source: AGHT+IGzF137Xs/CHuw0Ma2paBXNxm4b7Jn9WLarTqvCGaCaS/vcrSi2VklEbOjFZfFtP7kLz4xYRoCxR3IO+Kyv338=
X-Received: by 2002:a19:a418:0:b0:507:968d:a301 with SMTP id
 q24-20020a19a418000000b00507968da301mr762752lfc.55.1697700935232; Thu, 19 Oct
 2023 00:35:35 -0700 (PDT)
MIME-Version: 1.0
References: <CACdvm3MuKmzQ1EFMJDc0ahhrG6xpD6Rr9Vh=ZTpVHa12ZALB0w@mail.gmail.com>
 <CALZpt+E+od+nejiZDeMfQ+qLNMc8UnU=G1YVsH+REut6+Jj-Bg@mail.gmail.com>
 <CACdvm3OJsg2Br91aDL8=eACTW1WkdQcUSCvpWyniuEZf+qSAuA@mail.gmail.com>
 <CALZpt+EwwQJo16_5tWVBz6xRZ-O0q7S+JCuJm9hwGMrrgsdRjw@mail.gmail.com>
In-Reply-To: <CALZpt+EwwQJo16_5tWVBz6xRZ-O0q7S+JCuJm9hwGMrrgsdRjw@mail.gmail.com>
From: Bastien TEINTURIER <bastien@acinq.fr>
Date: Thu, 19 Oct 2023 09:35:23 +0200
Message-ID: <CACdvm3MRkTnz_S8YKvMQW8tWDb6Q3hJT5jfzsTLMLM7j+4awzQ@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000002e170906080ccd38"
X-Mailman-Approved-At: Thu, 19 Oct 2023 08:47:02 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 "lightning-dev\\\\@lists.linuxfoundation.org"
 <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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Oct 2023 07:35:40 -0000

--0000000000002e170906080ccd38
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 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 mer. 18 oct. 2023 =C3=A0 20:04, Antoine Riard <antoine.riard@gmail.com> =
a
=C3=A9crit :

> 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 fro=
m
> 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=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 o=
n
> non-deployed package acceptance code:
>
> https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d=
72f1efcf
>
> 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 fundi=
ng
> outputs are shared with a LSP, malicious collusion is less plausible.
>
> Best,
> Antoine
>
> Le mer. 18 oct. 2023 =C3=A0 15:35, Bastien TEINTURIER <bastien@acinq.fr> =
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 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=3D3, 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/19d61fa8cf22a5050b51c4005603f43=
d72f1efcf
>>
>> 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 <antoine.riard@gmail.co=
m> 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. 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.
>>>
>>> It is uncertain to me if secure fee-bumping, even with future mechanism=
s
>>> 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/19d61fa8cf22a5050b51c4005603f4=
3d72f1efcf
>>>
>>> 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 <bastien@acinq.fr=
> a
>>> =C3=A9crit :
>>>
>>>> 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). Th=
e
>>>> 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 a=
n
>>>> 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 nee=
d
>>>> 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 curren=
t
>>>> 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 th=
e
>>>> 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 us=
er
>>>> and force them to pay to get their funds back.
>>>>
>>>> Lightning normally fixes this by exchanging signatures for a commitmen=
t
>>>> 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 fi=
nd
>>>> 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 neve=
r
>>>> 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
>>>>
>>>

--0000000000002e170906080ccd38
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Antoine,<br><br>&gt; If I&#39;m correct, two users can =
cooperate maliciously against the batch<br>&gt; withdrawal transactions by =
re-signing a CPFP from 2-of-2 and<br>&gt; broadcasting the batch withdrawal=
 as a higher-feerate package / high<br>&gt; fee package and then evicting o=
ut the CPFP.<br><br>Yes, they can, and any user could also double-spend the=
 batch using a<br>commit tx spending from the previous funding output. Part=
icipants must<br>expect that this may happen, that&#39;s what I mentioned p=
reviously that<br>you cannot use 0-conf on that splice transaction. But apa=
rt from that,<br>it acts as a regular splice: participants must watch for d=
ouble-spends<br>(as discussed in the previous messages) while waiting for c=
onfirmations.<br><br>&gt; If the batch withdrawal has been signed with 0-fe=
e thanks to the<br>&gt; nversion=3D3 policy exemption, it will be evicted o=
ut of the mempool.<br>&gt; A variant of a replacement cycling attack.<br><b=
r>I don&#39;t think this should use nVersion=3D3 and pay 0 fees. On the con=
trary<br>this is a &quot;standard&quot; transaction that should use a reaso=
nable feerate<br>and nVersion=3D2, that&#39;s why I don&#39;t think this co=
mment applies.<br><br>Cheers,<br>Bastien<br></div><br><div class=3D"gmail_q=
uote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mer. 18 oct. 2023 =C3=
=A0=C2=A020:04, Antoine Riard &lt;<a href=3D"mailto:antoine.riard@gmail.com=
">antoine.riard@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi Bastien,<div><br>=
</div><div>Thanks for the answer.</div><div><br></div><div>If I understand =
correctly the protocol=C2=A0you&#39;re describing=C2=A0you&#39;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 (&quot;splice-ou=
t&quot;). Those channels funding outputs are 2-of-2, between two lambda use=
rs or e.g a lambda user and a LSP.</div><div><br></div><div>If I&#39;m corr=
ect, two users can cooperate maliciously against the batch withdrawal trans=
actions by re-signing a CPFP from 2-of-2 and broadcasting the batch withdra=
wal as a higher-feerate package / high fee package and then evicting out th=
e CPFP.=C2=A0</div><div><br></div><div>If the batch withdrawal has been sig=
ned with 0-fee thanks to the nversion=3D3 policy exemption, it will be evic=
ted out of the=C2=A0mempool. A variant of a replacement cycling attack.</di=
v><div><br></div><div>I think this more or less=C2=A0matches the test I&#39=
;m pointing to you which is on non-deployed package acceptance code:</div><=
div><a href=3D"https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b5=
1c4005603f43d72f1efcf" target=3D"_blank">https://github.com/ariard/bitcoin/=
commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf</a><br></div><div><br></div=
><div>Please correct me if I&#39;m wrong or missing assumptions. Agree with=
 you on the assumptions that the exchange does not have an incentive to dou=
ble-spend its own withdrawal transactions, or if all the batched funding ou=
tputs are shared with a LSP, malicious collusion is less plausible.</div><d=
iv><br></div><div>Best,</div><div>Antoine</div></div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mer. 18 oct. 2023 =
=C3=A0=C2=A015:35, Bastien TEINTURIER &lt;<a href=3D"mailto:bastien@acinq.f=
r" target=3D"_blank">bastien@acinq.fr</a>&gt; a =C3=A9crit=C2=A0:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hey Z-ma=
n, Antoine,<br><br>Thank you for your feedback, responses inline.<br><br>z-=
man:<br><br>&gt; Then if I participate in a batched splice, I can disrupt t=
he batched<br>&gt; splice by broadcasting the old state and somehow convinc=
ing miners to<br>&gt; confirm it before the batched splice.<br><br>Correct,=
 I didn&#39;t mention it in my post but batched splices cannot use<br>0-con=
f, the transaction must be confirmed to remove the risk of double<br>spends=
 using commit txs associated with the previous funding tx.<br><br>But inter=
estingly, with the protocol I drafted, the LSP can finalize and<br>broadcas=
t the batched splice transaction while users are offline. With a<br>bit of =
luck, when the users reconnect, that transaction will already be<br>confirm=
ed so it will &quot;feel 0-conf&quot;.<br><br>Also, we need a mechanism lik=
e the one you describe when we detect that<br>a splice transaction has been=
 double-spent. But this isn&#39;t specific to<br>batched transactions, 2-pa=
rty splice transactions can also be double<br>spent by either participant. =
So we need that mechanism anyway? The spec<br>doesn&#39;t have a way of abo=
rting a splice after exchanging signatures, but<br>you can always do it as =
an RBF operation (which actually just does a<br>completely different splice=
). This is what Greg mentioned in his answer.<br><br>&gt; part of the splic=
e proposal is that while a channel is being spliced,<br>&gt; it should not =
be spliced again, which your proposal seems to violate.<br><br>The spec doe=
sn&#39;t require that, I&#39;m not sure what made you think that.<br>While =
a channel is being spliced, it can definitely be spliced again as<br>an RBF=
 attempt (this is actually a very important feature), which double<br>spend=
s the other unconfirmed splice attempts.<br><br>ariard:<br><br>&gt; It is u=
ncertain to me if secure fee-bumping, even with future<br>&gt; mechanisms l=
ike package relay and nversion=3D3, is robust enough for<br>&gt; multi-part=
y transactions and covenant-enable constructions under usual<br>&gt; risk m=
odels.<br><br>I&#39;m not entirely sure why you&#39;re bringing this up in =
this context...<br>I agree that we most likely cannot use RBF on those batc=
hed transactions<br>we will need to rely on CPFP and potentially package re=
lay. But why is<br>it different from non-multi-party transactions here?<br>=
<br>&gt; See test here:<br>&gt; <a href=3D"https://github.com/ariard/bitcoi=
n/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf" target=3D"_blank">https:=
//github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf=
</a><br><br>I&#39;d argue that this is quite different from the standard re=
placement<br>cycling attack, because in this protocol wallet users can only=
<br>unilaterally double-spend with a commit tx, on which they cannot set<br=
>the feerate. The only participant that can &quot;easily&quot; double-spend=
 is<br>the exchange, and they wouldn&#39;t have an incentive to here, users=
 are<br>only withdrawing funds, there&#39;s no opportunity of stealing fund=
s?<br><br>Thanks,<br>Bastien<br></div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mar. 17 oct. 2023 =C3=A0=C2=A021:10=
, Antoine Riard &lt;<a href=3D"mailto:antoine.riard@gmail.com" target=3D"_b=
lank">antoine.riard@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi Bastien,<div>=
<br></div><div>&gt; The naive way of enabling lightning withdrawals is to m=
ake the user<br>&gt; provide a lightning invoice that the exchange pays ove=
r lightning. The<br>&gt; issue is that in most cases, this simply shifts th=
e burden of making an<br>&gt; on-chain transaction to the user&#39;s wallet=
 provider: if the user doesn&#39;t<br>&gt; have enough inbound liquidity (w=
hich is likely), a splice transaction<br>&gt; will be necessary. If N users=
 withdraw funds from an exchange, we most<br>&gt; likely will end up with N=
 separate splice transactions.<br></div><div><br></div><div>It is uncertain=
 to me if secure fee-bumping, even with future mechanisms like package rela=
y and=C2=A0nversion=3D3, is robust enough for multi-party transactions and =
covenant-enable constructions under usual risk models.</div><div><br></div>=
<div>See test here:</div><div><a href=3D"https://github.com/ariard/bitcoin/=
commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf" target=3D"_blank">https://=
github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf</=
a><br></div><div><br></div><div>Appreciated expert eyes of folks understand=
ing both lightning and core mempool on this.</div><div>There was a lot of b=
ack and forth on nversion=3D3 design rules, though the test is normally bui=
lt on glozow top commit of the 3 Oct 2023.</div><div><br></div><div>Best,</=
div><div>Antoine</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
 class=3D"gmail_attr">Le=C2=A0mar. 17 oct. 2023 =C3=A0=C2=A014:03, Bastien =
TEINTURIER &lt;<a href=3D"mailto:bastien@acinq.fr" target=3D"_blank">bastie=
n@acinq.fr</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex"><div dir=3D"ltr">Good morning list,<br><br>I&#39;ve =
been trying to design a protocol to let users withdraw funds from<br>exchan=
ges directly into their lightning wallet in an efficient way<br>(with the s=
mallest on-chain footprint possible).<br><br>I&#39;ve come to the conclusio=
n that this is only possible with some form of<br>covenants (e.g. `SIGHASH_=
ANYPREVOUT` would work fine in this case). The<br>goal of this post is to e=
xplain why, and add this usecase to the list of<br>useful things we could d=
o if we had covenants (insert &quot;wen APO?&quot; meme).<br><br>The naive =
way of enabling lightning withdrawals is to make the user<br>provide a ligh=
tning invoice that the exchange pays over lightning. The<br>issue is that i=
n most cases, this simply shifts the burden of making an<br>on-chain transa=
ction to the user&#39;s wallet provider: if the user doesn&#39;t<br>have en=
ough inbound liquidity (which is likely), a splice transaction<br>will be n=
ecessary. If N users withdraw funds from an exchange, we most<br>likely wil=
l end up with N separate splice transactions.<br><br>Hence the idea of batc=
hing those into a single transaction. Since we<br>don&#39;t want to introdu=
ce any intermediate transaction, we must be able<br>to create one transacti=
on that splices multiple channels at once. The<br>issue is that for each of=
 these channels, we need a signature from the<br>corresponding wallet user,=
 because we&#39;re spending the current funding<br>output, which is a 2-of-=
2 multisig between the wallet user and the<br>wallet provider. So we run in=
to the usual availability problem: we need<br>signatures from N users who m=
ay not be online at the same time, and if<br>one of those users never comes=
 online or doesn&#39;t complete the protocol,<br>we must discard the whole =
batch.<br><br>There is a workaround though: each wallet user can provide a =
signature<br>using `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` that spends thei=
r current<br>funding output to create a new funding output with the expecte=
d amount.<br>This lets users sign *before* knowing the final transaction, w=
hich the<br>exchange can create by batching pairs of inputs/outputs. But th=
is has<br>a fatal issue: at that point the wallet user has no way of spendi=
ng the<br>new funding output (since it is also a 2-of-2 between the wallet =
user<br>and the wallet provider). The wallet provider can now blackmail the=
 user<br>and force them to pay to get their funds back.<br><br>Lightning no=
rmally fixes this by exchanging signatures for a commitment<br>transaction =
that sends the funds back to their owners *before* signing<br>the parent fu=
nding/splice transaction. But here that is impossible,<br>because we don&#3=
9;t know yet the `txid` of the batch transaction (that&#39;s<br>the whole p=
oint, we want to be able to sign before creating the batch)<br>so we don&#3=
9;t know the new `prevout` we should spend from. I couldn&#39;t find<br>a c=
lever way to work around that, and I don&#39;t think there is one (but<br>I=
 would be happy to be wrong).<br><br>With `SIGHASH_ANYPREVOUT`, this is imm=
ediately fixed: we can exchange<br>anyprevout signatures for the commitment=
 transaction, and they will be<br>valid to spend from the batch transaction=
. We are safe from signature<br>reuse, because funding keys are rotated at =
each splice so we will never<br>create another output that uses the same 2-=
of-2 script.<br><br>I haven&#39;t looked at other forms of covenants, but m=
ost of them likely<br>address this problem as well.<br><br>Cheers,<br>Basti=
en<br></div>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href=3D"mailto:Lightning-dev@lists.linuxfoundation.org" target=3D"_blank=
">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev=
" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/ma=
ilman/listinfo/lightning-dev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>

--0000000000002e170906080ccd38--