MIME-Version: 1.0
References: <CACdvm3MuKmzQ1EFMJDc0ahhrG6xpD6Rr9Vh=ZTpVHa12ZALB0w@mail.gmail.com>
 <CALZpt+E+od+nejiZDeMfQ+qLNMc8UnU=G1YVsH+REut6+Jj-Bg@mail.gmail.com>
In-Reply-To: <CALZpt+E+od+nejiZDeMfQ+qLNMc8UnU=G1YVsH+REut6+Jj-Bg@mail.gmail.com>
From: Bastien TEINTURIER <bastien@acinq.fr>
Date: Wed, 18 Oct 2023 16:35:40 +0200
Message-ID: <CACdvm3OJsg2Br91aDL8=eACTW1WkdQcUSCvpWyniuEZf+qSAuA@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000006f1e2b0607fe8e71"
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
Precedence: list

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

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/19d61fa8cf22a5050b51c4005603f43d72=
f1efcf

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.com> =
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. 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=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/19d61fa8cf22a5050b51c4005603f43d=
72f1efcf
>
> 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 th=
e
> 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). The
>> goal of this post is to explain why, and add this usecase to the list of
>> useful things we could do if we had covenants (insert "wen APO?" meme).
>>
>> The naive way of enabling lightning withdrawals is to make the user
>> provide a lightning invoice that the exchange pays over lightning. The
>> issue is that in most cases, this simply shifts the burden of making an
>> on-chain transaction to the user's wallet provider: if the user doesn't
>> have enough inbound liquidity (which is likely), a splice transaction
>> will be necessary. If N users withdraw funds from an exchange, we most
>> likely will end up with N separate splice transactions.
>>
>> Hence the idea of batching those into a single transaction. Since we
>> don't want to introduce any intermediate transaction, we must be able
>> to create one transaction that splices multiple channels at once. The
>> issue is that for each of these channels, we need a signature from the
>> corresponding wallet user, because we're spending the current funding
>> output, which is a 2-of-2 multisig between the wallet user and the
>> wallet provider. So we run into the usual availability problem: we need
>> signatures from N users who may not be online at the same time, and if
>> one of those users never comes online or doesn't complete the protocol,
>> we must discard the whole batch.
>>
>> There is a workaround though: each wallet user can provide a signature
>> using `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` that spends their current
>> funding output to create a new funding output with the expected amount.
>> This lets users sign *before* knowing the final transaction, which the
>> exchange can create by batching pairs of inputs/outputs. But this has
>> a fatal issue: at that point the wallet user has no way of spending the
>> new funding output (since it is also a 2-of-2 between the wallet user
>> and the wallet provider). The wallet provider can now blackmail the user
>> and force them to pay to get their funds back.
>>
>> Lightning normally fixes this by exchanging signatures for a commitment
>> transaction that sends the funds back to their owners *before* signing
>> the parent funding/splice transaction. But here that is impossible,
>> because we don't know yet the `txid` of the batch transaction (that's
>> the whole point, we want to be able to sign before creating the batch)
>> so we don't know the new `prevout` we should spend from. I couldn't find
>> a clever way to work around that, and I don't think there is one (but
>> I would be happy to be wrong).
>>
>> With `SIGHASH_ANYPREVOUT`, this is immediately fixed: we can exchange
>> anyprevout signatures for the commitment transaction, and they will be
>> valid to spend from the batch transaction. We are safe from signature
>> reuse, because funding keys are rotated at each splice so we will never
>> create another output that uses the same 2-of-2 script.
>>
>> I haven't looked at other forms of covenants, but most of them likely
>> address this problem as well.
>>
>> Cheers,
>> Bastien
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>

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

<div dir=3D"ltr">Hey Z-man, Antoine,<br><br>Thank you for your feedback, re=
sponses inline.<br><br>z-man:<br><br>&gt; Then if I participate in a batche=
d splice, I can disrupt the batched<br>&gt; splice by broadcasting the old =
state and somehow convincing miners to<br>&gt; confirm it before the batche=
d splice.<br><br>Correct, I didn&#39;t mention it in my post but batched sp=
lices 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 fun=
ding tx.<br><br>But interestingly, with the protocol I drafted, the LSP can=
 finalize and<br>broadcast the batched splice transaction while users are o=
ffline. With a<br>bit of luck, when the users reconnect, that transaction w=
ill already be<br>confirmed so it will &quot;feel 0-conf&quot;.<br><br>Also=
, we need a mechanism like the one you describe when we detect that<br>a sp=
lice transaction has been double-spent. But this isn&#39;t specific to<br>b=
atched transactions, 2-party splice transactions can also be double<br>spen=
t by either participant. So we need that mechanism anyway? The spec<br>does=
n&#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>co=
mpletely 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 splice=
d,<br>&gt; it should not be spliced again, which your proposal seems to vio=
late.<br><br>The spec 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 s=
pliced again as<br>an RBF attempt (this is actually a very important featur=
e), which double<br>spends the other unconfirmed splice attempts.<br><br>ar=
iard:<br><br>&gt; It is uncertain to me if secure fee-bumping, even with fu=
ture<br>&gt; mechanisms like package relay and nversion=3D3, is robust enou=
gh for<br>&gt; multi-party transactions and covenant-enable constructions u=
nder usual<br>&gt; risk models.<br><br>I&#39;m not entirely sure why you&#3=
9;re bringing this up in this context...<br>I agree that we most likely can=
not use RBF on those batched transactions<br>we will need to rely on CPFP a=
nd potentially package relay. But why is<br>it different from non-multi-par=
ty transactions here?<br><br>&gt; See test here:<br>&gt; <a href=3D"https:/=
/github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf"=
>https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d7=
2f1efcf</a><br><br>I&#39;d argue that this is quite different from the stan=
dard replacement<br>cycling attack, because in this protocol wallet users c=
an 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; doubl=
e-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 steali=
ng 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">anto=
ine.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 solid rg=
b(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 make the u=
ser<br>&gt; provide a lightning invoice that the exchange pays over lightni=
ng. 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 doesn&#39;t<br>&gt; have enough inbound liquidity (which is l=
ikely), 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 relay 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/1=
9d61fa8cf22a5050b51c4005603f43d72f1efcf" target=3D"_blank">https://github.c=
om/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf</a><br></=
div><div><br></div><div>Appreciated expert eyes of folks understanding both=
 lightning and core 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 gl=
ozow 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 TEINTU=
RIER &lt;<a href=3D"mailto:bastien@acinq.fr" target=3D"_blank">bastien@acin=
q.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);p=
adding-left:1ex"><div dir=3D"ltr">Good morning list,<br><br>I&#39;ve been t=
rying to design a protocol to let users withdraw funds from<br>exchanges di=
rectly into their lightning wallet in an efficient way<br>(with the smalles=
t on-chain footprint possible).<br><br>I&#39;ve come to the conclusion that=
 this is only possible with some form of<br>covenants (e.g. `SIGHASH_ANYPRE=
VOUT` 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>useful things we could do if w=
e 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 lightning =
invoice that the exchange pays over lightning. The<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 doesn&#39;t<br>have enough i=
nbound liquidity (which is likely), a splice transaction<br>will be necessa=
ry. If N users withdraw funds from an exchange, we most<br>likely will end =
up with N separate splice transactions.<br><br>Hence the idea of batching t=
hose 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 tha=
t 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, becau=
se we&#39;re spending the current funding<br>output, which is a 2-of-2 mult=
isig between the wallet user and the<br>wallet provider. So we run into the=
 usual availability problem: we need<br>signatures from N users who may not=
 be online at the same time, and if<br>one of those users never comes onlin=
e 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 signat=
ure<br>using `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` that spends their curr=
ent<br>funding output to create a new funding output with the expected amou=
nt.<br>This lets users sign *before* knowing the final transaction, which t=
he<br>exchange can create by batching pairs of inputs/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<b=
r>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 commitment<br>transaction that s=
ends the funds back to their owners *before* signing<br>the parent funding/=
splice transaction. But here that is impossible,<br>because we don&#39;t kn=
ow yet the `txid` of the batch transaction (that&#39;s<br>the whole point, =
we want to be able to sign before creating the batch)<br>so we don&#39;t kn=
ow the new `prevout` we should spend from. I couldn&#39;t find<br>a clever =
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 immediate=
ly fixed: we can exchange<br>anyprevout signatures for the commitment trans=
action, and they will be<br>valid to spend from the batch transaction. We a=
re safe from signature<br>reuse, because funding keys are rotated at each s=
plice so we will never<br>create another output that uses the same 2-of-2 s=
cript.<br><br>I haven&#39;t looked at other forms 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>

--0000000000006f1e2b0607fe8e71--