path: root/3c/de9215ffcf6c3647e73a651b8fab476896e31d

Return-Path: <gsanders87@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 559D3C0032;
 Tue, 17 Oct 2023 17:10:57 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 115B741E59;
 Tue, 17 Oct 2023 17:10:57 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 115B741E59
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20230601 header.b=T7vpcCRI
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Gs5YW1C-aNiy; Tue, 17 Oct 2023 17:10:56 +0000 (UTC)
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [IPv6:2a00:1450:4864:20::630])
 by smtp4.osuosl.org (Postfix) with ESMTPS id B1EC541690;
 Tue, 17 Oct 2023 17:10:55 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org B1EC541690
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-9c603e235d1so151063966b.3; 
 Tue, 17 Oct 2023 10:10:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1697562654; x=1698167454;
 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=frQjBBkSsQtp4uCFoaUALtsYZe6dj6POlIRFHb3raSI=;
 b=T7vpcCRIzwBrcP0hzmzjEzTkyav6rA9nC3HrTu5eGu7VNqftXNjTMOW0QtBKLzaJxk
 YXe+K1rOHQGo0y91jsNtOxyQH7cLfSuX7vRz8n+gYQkYms2+/DhggVooIjdD/EVS0fds
 prJUH55l6k2UiZKq13DQDhkYaQRnIunTosaYzSJb7Vhr9TKL30ZV/Q4NTZmhpg/xnvHz
 /EOnnXNhNastrIIxXBM14WfqabkZBZnt+76UsB/DjmSYP2ocxTmSZ03XvQhmHkW05Hut
 KQtEdkCkUfHSAr4aITw+Bbzz/OuyFl2Iv7JWWs/vhN/rOyLuFiDbvBUV31ADyN6NiWtE
 WDqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1697562654; x=1698167454;
 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=frQjBBkSsQtp4uCFoaUALtsYZe6dj6POlIRFHb3raSI=;
 b=IRZ13dwdOpzIOm6NaE++lYQ2c5dOLHbY6QQFbXXgxs1MLrAgLEyriNYxbUP+enFmFu
 IdUiRvr5pR6NjzyXl7973y+OpbDPOkJnBKqO8eVED7Vnua7c+VRnDtSjv/D/Izx04P+I
 R4NOzfjO0MGm1yOh1Bw5goBpk5ruTe2aqGJ0IdwymP01oFcQvPPclMXid8tfaMKpYFCc
 dtE7petUXwPabvdCqstPncSjEEVxHVkEegJ9U3BBybpcIOjQVQcMueXn1Ce+4S41HnCV
 WLPbqIuyCs6RflSTIaW0dZ7oDW7hiBUjfGJI9OQmDQ8Bg7thS5dpyJMVHyOzpHt/79Vu
 10sQ==
X-Gm-Message-State: AOJu0Yw9J2+4iG8KWoFk1UZwQ5x4BdWLzlTND4gX41IYmo7Mh/4RLOrB
 ZTwIFb4y6Qxu8ESd92CWnRakEhBrWpwCxBPl9bk=
X-Google-Smtp-Source: AGHT+IET2S/JGhKx0uRDyDGGceRUc0fYETdFmyb8SvrUs+FLfYIH20MLeOzne4265TD7gauUuv5Gfzw1EHUTqIPMlN0=
X-Received: by 2002:a17:907:6096:b0:9ae:522e:8f78 with SMTP id
 ht22-20020a170907609600b009ae522e8f78mr2492888ejc.74.1697562653563; Tue, 17
 Oct 2023 10:10:53 -0700 (PDT)
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
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: Tue, 17 Oct 2023 17:10:57 -0000

--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--