path: root/67/a73424a85b1543e453620c0d274ba3feb9aa48

Return-Path: <antoine.riard@gmail.com>
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: <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>
 <CACdvm3MRkTnz_S8YKvMQW8tWDb6Q3hJT5jfzsTLMLM7j+4awzQ@mail.gmail.com>
In-Reply-To: <CACdvm3MRkTnz_S8YKvMQW8tWDb6Q3hJT5jfzsTLMLM7j+4awzQ@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Thu, 19 Oct 2023 18:09:51 +0100
Message-ID: <CALZpt+GPm36gwMbE5Co5VRckEYnLC+T1QcAQM+eOEB4erjORLg@mail.gmail.com>
To: Bastien TEINTURIER <bastien@acinq.fr>
Content-Type: multipart/alternative; boundary="000000000000973b90060814d314"
X-Mailman-Approved-At: Thu, 19 Oct 2023 21:52: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 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 <bastien@acinq.fr> 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 <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 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 <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 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 <antoine.riard@gmail.c=
om> 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 <bastien@acinq.f=
r> 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

<div dir=3D"ltr">Hi Bastien,<div><br></div><div>Thanks for your additional =
comments.</div><div><br></div><div>&gt; Yes, they can, and any user could a=
lso double-spend the batch using a<br>&gt; commit tx spending from the prev=
ious funding output. Participants must<br>&gt; expect that this may happen,=
 that&#39;s what I mentioned previously that<br>&gt; you cannot use 0-conf =
on that splice transaction. But apart from that,<br>&gt; it acts as a regul=
ar splice: participants must watch for double-spends<br>&gt; (as discussed =
in the previous messages) while waiting for confirmations.<br></div><div><b=
r></div><div>Understood better, it&#39;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&#39;re already aware of I think and=
 where one should wait for a few confirmations before using spawned channel=
s.</div><div><br></div><div>&gt; I don&#39;t think this should use nVersion=
=3D3 and pay 0 fees. On the contrary<br>&gt; this is a &quot;standard&quot;=
 transaction that should use a reasonable feerate<br>&gt; and nVersion=3D2,=
 that&#39;s why I don&#39;t think this comment applies.<br></div><div><br><=
/div><div>Under this model where the splice should be a &quot;standard&quot=
; nVersion=3D2 transaction that is using a reasonable feerate for non-delay=
ed broadcast, yes my comment does not apply, agree here.</div><div><br></di=
v><div>However for a hypothetical=C2=A0future, where the picked up feerate =
of the batch splicing isn&#39;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><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=A0jeu. 19 oct. 2023 =C3=A0=C2=A008:3=
5, Bastien TEINTURIER &lt;<a href=3D"mailto:bastien@acinq.fr">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-width:1px;border-left-style:s=
olid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">=
Hi Antoine,<br><br>&gt; If I&#39;m correct, two users can cooperate malicio=
usly 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-feer=
ate package / high<br>&gt; fee package and then evicting out 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. Participants must<br>=
expect that this may happen, that&#39;s what I mentioned previously that<br=
>you cannot use 0-conf on that splice transaction. But apart from that,<br>=
it acts as a regular splice: participants must watch for double-spends<br>(=
as discussed in the previous messages) while waiting for confirmations.<br>=
<br>&gt; If the batch withdrawal has been signed with 0-fee thanks to the<b=
r>&gt; nversion=3D3 policy exemption, it will be evicted out of the mempool=
.<br>&gt; A variant of a replacement cycling attack.<br><br>I don&#39;t thi=
nk this should use nVersion=3D3 and pay 0 fees. On the contrary<br>this is =
a &quot;standard&quot; transaction that should use a reasonable feerate<br>=
and nVersion=3D2, that&#39;s why I don&#39;t think this comment applies.<br=
><br>Cheers,<br>Bastien<br></div><br><div class=3D"gmail_quote"><div dir=3D=
"ltr" class=3D"gmail_attr">Le=C2=A0mer. 18 oct. 2023 =C3=A0=C2=A020:04, Ant=
oine Riard &lt;<a href=3D"mailto:antoine.riard@gmail.com" target=3D"_blank"=
>antoine.riard@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1=
ex"><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&#3=
9;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-out&quot;). Those channels funding o=
utputs are 2-of-2, between two lambda users or e.g a lambda user and a LSP.=
</div><div><br></div><div>If I&#39;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</div><div><br></div>=
<div>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.</div><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/19d61fa8cf22a5050b51c4005603f43d72f1efcf" target=3D"_=
blank">https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c400560=
3f43d72f1efcf</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 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.</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=A0mer. 18 oct. 2023 =C3=A0=C2=A015:35, Bastien TEINTURIE=
R &lt;<a href=3D"mailto:bastien@acinq.fr" target=3D"_blank">bastien@acinq.f=
r</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:sol=
id;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">He=
y Z-man, 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 dis=
rupt the batched<br>&gt; splice by broadcasting the old state and somehow c=
onvincing miners to<br>&gt; confirm it before the batched splice.<br><br>Co=
rrect, I didn&#39;t mention it in my post but batched splices cannot use<br=
>0-conf, 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=
 interestingly, with the protocol I drafted, the LSP can finalize and<br>br=
oadcast the batched splice transaction while users are offline. With a<br>b=
it of luck, when the users reconnect, that transaction will already be<br>c=
onfirmed so it will &quot;feel 0-conf&quot;.<br><br>Also, we need a mechani=
sm like the one you describe when we detect that<br>a splice transaction ha=
s been double-spent. But this isn&#39;t specific to<br>batched transactions=
, 2-party splice transactions can also be double<br>spent by either partici=
pant. So we need that mechanism anyway? The spec<br>doesn&#39;t have a way =
of aborting 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=
 splice proposal is that while a channel is being spliced,<br>&gt; it shoul=
d not be spliced again, which your proposal seems to violate.<br><br>The sp=
ec doesn&#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=
>spends the other unconfirmed splice attempts.<br><br>ariard:<br><br>&gt; I=
t is uncertain to me if secure fee-bumping, even with future<br>&gt; mechan=
isms like package relay and nversion=3D3, is robust enough for<br>&gt; mult=
i-party transactions and covenant-enable constructions under usual<br>&gt; =
risk models.<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 thos=
e batched transactions<br>we will need to rely on CPFP and potentially pack=
age relay. But why is<br>it different from non-multi-party transactions her=
e?<br><br>&gt; See test here:<br>&gt; <a href=3D"https://github.com/ariard/=
bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf" target=3D"_blank">=
https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72=
f1efcf</a><br><br>I&#39;d argue that this is quite different from the stand=
ard replacement<br>cycling attack, because in this protocol wallet users ca=
n 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 stealin=
g funds?<br><br>Thanks,<br>Bastien<br></div><br><div class=3D"gmail_quote">=
<div dir=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" targ=
et=3D"_blank">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-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr">Hi Bastien,<div><br></div><div>&gt; The n=
aive way of enabling lightning withdrawals is to make the user<br>&gt; prov=
ide a lightning invoice that the exchange pays over lightning. The<br>&gt; =
issue is that in most cases, this simply shifts the burden of making an<br>=
&gt; on-chain transaction to the user&#39;s wallet provider: if the user do=
esn&#39;t<br>&gt; have enough inbound liquidity (which is likely), a splice=
 transaction<br>&gt; will be necessary. If N users withdraw funds from an e=
xchange, we most<br>&gt; likely will end up with N separate splice transact=
ions.<br></div><div><br></div><div>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.</div><div><br></div><div>See test here:</div>=
<div><a href=3D"https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b=
51c4005603f43d72f1efcf" target=3D"_blank">https://github.com/ariard/bitcoin=
/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf</a><br></div><div><br></di=
v><div>Appreciated expert eyes of folks understanding both lightning and co=
re mempool on this.</div><div>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.</div><div><br></div><div>Best,</div><div>Antoine</div></d=
iv><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">bastien@acinq.fr</a>&gt; a =
=C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-le=
ft-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Good morning l=
ist,<br><br>I&#39;ve been trying to design a protocol to let users withdraw=
 funds from<br>exchanges directly into their lightning wallet in an efficie=
nt way<br>(with the smallest on-chain footprint possible).<br><br>I&#39;ve =
come to the conclusion that this is only possible with some form of<br>cove=
nants (e.g. `SIGHASH_ANYPREVOUT` would work fine in this case). The<br>goal=
 of this post is to explain why, and add this usecase to the list of<br>use=
ful things we could do if we had covenants (insert &quot;wen APO?&quot; mem=
e).<br><br>The naive way of enabling lightning withdrawals is to make the u=
ser<br>provide a lightning invoice that the exchange pays over lightning. T=
he<br>issue is that in most cases, this simply shifts the burden of making =
an<br>on-chain transaction to the user&#39;s wallet provider: if the user d=
oesn&#39;t<br>have enough inbound liquidity (which is likely), a splice tra=
nsaction<br>will be necessary. If N users withdraw funds from an exchange, =
we most<br>likely will end up with N separate splice transactions.<br><br>H=
ence the idea of batching those into a single transaction. Since we<br>don&=
#39;t want to introduce any intermediate transaction, we must be able<br>to=
 create one transaction that splices multiple channels at once. The<br>issu=
e is that for each of these channels, we need a signature from the<br>corre=
sponding wallet user, because we&#39;re spending the current funding<br>out=
put, which is a 2-of-2 multisig between the wallet user and the<br>wallet p=
rovider. So we run into the usual availability problem: we need<br>signatur=
es from N users who may not be online at the same time, and if<br>one of th=
ose users never comes online or doesn&#39;t complete the protocol,<br>we mu=
st discard the whole batch.<br><br>There is a workaround though: each walle=
t user can provide a signature<br>using `SIGHASH_SINGLE | SIGHASH_ANYONECAN=
PAY` that spends their current<br>funding output to create a new funding ou=
tput with the expected amount.<br>This lets users sign *before* knowing the=
 final transaction, which the<br>exchange can create by batching pairs of i=
nputs/outputs. But this has<br>a fatal issue: at that point the wallet user=
 has no way of spending 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 normally fixes this by exchanging signatures for a commi=
tment<br>transaction that sends the funds back to their owners *before* sig=
ning<br>the parent funding/splice transaction. But here that is impossible,=
<br>because we don&#39;t know yet the `txid` of the batch transaction (that=
&#39;s<br>the whole point, we want to be able to sign before creating the b=
atch)<br>so we don&#39;t know the new `prevout` we should spend from. I cou=
ldn&#39;t find<br>a clever way to work around that, and I don&#39;t think t=
here is one (but<br>I would be happy to be wrong).<br><br>With `SIGHASH_ANY=
PREVOUT`, this is immediately fixed: we can exchange<br>anyprevout signatur=
es 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 form=
s of covenants, but most of them likely<br>address this problem as well.<br=
><br>Cheers,<br>Bastien<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>
</blockquote></div>

--000000000000973b90060814d314--