MIME-Version: 1.0
References: <CACdvm3MuKmzQ1EFMJDc0ahhrG6xpD6Rr9Vh=ZTpVHa12ZALB0w@mail.gmail.com>
 <Ckp3N2cHGyyFyTp8IkjqYwnXsef1KxzhFs9vHQvFCpdWKUCrCfpxLBAgIXsKEtTNQqvfdyywt7weJd2pVz8UKn6egfRy46-xd17pnltcQyU=@protonmail.com>
In-Reply-To: <Ckp3N2cHGyyFyTp8IkjqYwnXsef1KxzhFs9vHQvFCpdWKUCrCfpxLBAgIXsKEtTNQqvfdyywt7weJd2pVz8UKn6egfRy46-xd17pnltcQyU=@protonmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Tue, 17 Oct 2023 13:10:42 -0400
Message-ID: <CAB3F3Dtb2s7gCjV6ok3=XjOx174DEuRksij4GOoFD20atwJfig@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000f31f6b0607ec9a2d"
Cc: "lightning-dev\\\\\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Batch exchange withdrawal to lightning requires
	covenants
Precedence: list

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

> I do not know if existing splice implementations actually perform such a
check.
Unless all splice implementations do this, then any kind of batched
splicing is risky.

As long as the implementation decides to splice again at some point when a
prior
splice isn't confirming, it will self-resolve once any subsequent splice is
confirmed.

Cheers,
Greg

On Tue, Oct 17, 2023 at 1:04=E2=80=AFPM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning Bastien,
>
> I have not gotten around to posting it yet, but I have a write-up in my
> computer with the title:
>
> > Batched Splicing Considered Risky
>
> The core of the risk is that if:
>
> * I have no funds right now in a channel (e.g. the LSP allowed me to have
> 0 reserve, or this is a newly-singlefunded channel from the LSP to me).
> * I have an old state (e.g. for a newly-singlefunded channel, it could
> have been `update_fee`d, so that the initial transaction is old state).
>
> 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.
>
> Thus, it is important for *any* batched splicing mechanism to have a
> backout, where if the batched splice transaction can no longer be confirm=
ed
> due to some participant disrupting it by posting an old commitment
> transaction, either a subset of the splice is re-created or the channels
> revert back to pre-splice state (with knowledge that the post-splice stat=
e
> can no longer be confirmed).
>
> I know that current splicing tech is to run both the pre-splice and
> post-splice state simultaneously until the splicing transaction is
> confirmed.
> However we need to *also* check if the splicing transaction *cannot* be
> confirmed --- by checking if the other inputs to the splice transaction
> were already consumed by transactions that have deeply confirmed, and in
> that case, to drop the post-splice state and revert to the pre-splice sta=
te.
> I do not know if existing splice implementations actually perform such a
> check.
> Unless all splice implementations do this, then any kind of batched
> splicing is risky.
>
> Regards,
> ZmnSCPxj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">&gt; I do not know if existing splice implementations actu=
ally perform such a check.<br>Unless all splice implementations do this, th=
en any kind of batched splicing is risky.<div><br></div><div>As long as the=
 implementation decides to splice again at some point when a prior</div><di=
v>splice isn&#39;t confirming, it will self-resolve once any subsequent spl=
ice is confirmed.</div><div><br></div><div>Cheers,</div><div>Greg</div></di=
v><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On T=
ue, Oct 17, 2023 at 1:04=E2=80=AFPM ZmnSCPxj via bitcoin-dev &lt;<a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfound=
ation.org</a>&gt; wrote:<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">Good morning Bastien,<br>
<br>
I have not gotten around to posting it yet, but I have a write-up in my com=
puter with the title:<br>
<br>
&gt; Batched Splicing Considered Risky<br>
<br>
The core of the risk is that if:<br>
<br>
* I have no funds right now in a channel (e.g. the LSP allowed me to have 0=
 reserve, or this is a newly-singlefunded channel from the LSP to me).<br>
* I have an old state (e.g. for a newly-singlefunded channel, it could have=
 been `update_fee`d, so that the initial transaction is old state).<br>
<br>
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.<br>
<br>
Thus, it is important for *any* batched splicing mechanism to have a backou=
t, where if the batched splice transaction can no longer be confirmed due t=
o some participant disrupting it by posting an old commitment transaction, =
either a subset of the splice is re-created or the channels revert back to =
pre-splice state (with knowledge that the post-splice state can no longer b=
e confirmed).<br>
<br>
I know that current splicing tech is to run both the pre-splice and post-sp=
lice state simultaneously until the splicing transaction is confirmed.<br>
However we need to *also* check if the splicing transaction *cannot* be con=
firmed --- by checking if the other inputs to the splice transaction were a=
lready consumed by transactions that have deeply confirmed, and in that cas=
e, to drop the post-splice state and revert to the pre-splice state.<br>
I do not know if existing splice implementations actually perform such a ch=
eck.<br>
Unless all splice implementations do this, then any kind of batched splicin=
g is risky.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000f31f6b0607ec9a2d--