1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
|
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">> 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'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 <<a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfound=
ation.org</a>> 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>
> 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--
|