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
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
|
Return-Path: <antoine.riard@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 359B4C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 Oct 2022 23:10:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 0B00440180
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 Oct 2022 23:10:30 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 0B00440180
Authentication-Results: smtp2.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20210112 header.b=MG1WEUUl
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 smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id D5szHqQbAcmL
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 Oct 2022 23:10:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 5728840134
Received: from mail-il1-x135.google.com (mail-il1-x135.google.com
[IPv6:2607:f8b0:4864:20::135])
by smtp2.osuosl.org (Postfix) with ESMTPS id 5728840134
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 Oct 2022 23:10:28 +0000 (UTC)
Received: by mail-il1-x135.google.com with SMTP id o2so1058059ilo.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 Oct 2022 16:10:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=so9hvh64tI+ZMIbTCL2I1dkWT7Yo8AwVD63c1xdDLrY=;
b=MG1WEUUlc1wa/iBRDKa5Ap00KqM54Y6E/ueP78/7GfEQWyNbmhnF0XwYa7xW2VIc2X
28qboTgoFOzPUUhwpPVKuNUCDShcxhuI4ksMnQnDgS66Ms8VoIlVsSbAuFPJ6Hs1EQ5I
MLuVzh5jK/Bu9BtmLozqX/7Sq52HnZBxepyAZsVO0ci6wFhfvqa68UXCClj1VRvL3wNY
GSYGI5r5fUUyu73DPJf0MaCsfhA1MipI7oJIxXlYGvdjJbsUhbgRchP5BG9Jp6hVIPl2
LRkq2FSyw/Aq9vt99lUnsfJ4Tp3u8OLZ4sLEDUkuctrKOjDXecsMjCFfsCyROcVwIyp6
NgzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
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=so9hvh64tI+ZMIbTCL2I1dkWT7Yo8AwVD63c1xdDLrY=;
b=Lvs0iSL94vmNeXyY4kP9T7cFWbIe0E95zJYq1SuFk0T07YtTWAY9jnhgOBqMSsVgF/
a3VDMJZaxMEIuTx1ec+/k2tf4hMsELI/W05I90bTxonrY/igu1dDjaqc7veHRkPokRWg
80+y6gXjmbkEJGIkzJfbtOVrkEubwoli+6PVtDFroAdSo8u7sOLOy5AUzMGO0/fs03fo
WzulIRd/RXjjUqT5o62DOBqAyvzaPxCr5rsXKWDwBU70pNve63gVXvhHXWx3r2rLLeMz
XXu14q7gQg+pvjs811xdt4JQpfxjgIL3MvYWb+P2pQXAXhjun5dZbmuthymqagC1/GOj
lCTg==
X-Gm-Message-State: ACrzQf1WpF2FOeUfntuzJPRMhRD/O6BwnyAjmfi8Fy6OtTnZYONtuW0X
fniT6/N1Y+2aPZKqnTDnKQcPcfACtvwdhEX4ktc6CnGhkps=
X-Google-Smtp-Source: AMsMyM4aRPgALLnUtaPkeSHrH/deXqO2YgazYUfmPlM3v3ilr8ioYV7yPRjaV0etgPZugQsVqu3OPKJRbukU7at08E0=
X-Received: by 2002:a92:ca0d:0:b0:2fc:24a6:9115 with SMTP id
j13-20020a92ca0d000000b002fc24a69115mr20629831ils.70.1666566627222; Sun, 23
Oct 2022 16:10:27 -0700 (PDT)
MIME-Version: 1.0
References: <CAKiPDnSsKPhL9-0pJBNav6SYJ45qiuxB6X-NMa1i65vHrxK2bA@mail.gmail.com>
<CALZpt+FPWSFbr6r-5J0YO1o3SvMQC4Gyj-QWTJ4yA3ZbJtOUxQ@mail.gmail.com>
<CAKiPDnQ68HgVYxB5nyJ+XQzs1L1KBqiuxFpnk3eqv3egEWziaA@mail.gmail.com>
In-Reply-To: <CAKiPDnQ68HgVYxB5nyJ+XQzs1L1KBqiuxFpnk3eqv3egEWziaA@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Sun, 23 Oct 2022 19:10:16 -0400
Message-ID: <CALZpt+GQ_aEA8LOzr7E_dHwWDZveKGyXw5cAvc5JvBnTocwsJQ@mail.gmail.com>
To: Dario Sneidermanis <dario@muun.com>
Content-Type: multipart/alternative; boundary="000000000000cf6bd105ebbbc71a"
X-Mailman-Approved-At: Sun, 23 Oct 2022 23:48:36 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Analysis of full-RBF deployment methods
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: Sun, 23 Oct 2022 23:10:30 -0000
--000000000000cf6bd105ebbbc71a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Dario,
Thanks for providing more thoughts to the discussion!
> Notice that #26323 (option 5 in the OP) has the advantage of getting us
to a
> reliable full-RBF network the fastest (in particular, much faster than th=
e
> current opt-in deployment) while not threatening zero-conf applications
> until
> the activation time. That is, #26323 gives us a way in which we don't nee=
d
> to
> choose between the security of one use case versus the other. We can have
> both.
For sure, contracting protocols and multi-party applications exposed by the
lack of full-rbf are still young overall, though as they attract more
volume they're also likely to become honeypots for any competing services
providers interested to hijack economic traffic (kinda the same concern
than channel jamming...) At the same time, we still have 0confs services
more exposed by full-rbf, a bit stuck between Scylla and Charybdis.
As commented on #26323, I'm personally fine with this approach, and I fully
opine that providing a clear and predictable time point to 0confs operators
is very valuable. Even more, I think May 1st 2023, is a bit too early,
10-12 months sounds more reasonable.
At the same time, I believe it's the opinion of a few developers and other
Bitcoin service operators that the Core project is taking too much
responsibility in taking for the network by shipping full-rbf=3Dtrue.
(Really I'm 50/50 between those 2 opinions, as I'm the author of both
#26305 and #25600 and concept ACK on #26323, and any process forward would
sounds good to me)
> I don't think asking for a predictable deployment timeline for a change
that
> would put some applications at increased risk could be described as
> burdening
> the developers with solving every operational risk. This deployment metho=
d
> comparison's goal was precisely to soften the burden on core devs.
I can understand the confusion here. As it has been discussed on your
original thread, from my comprehension, the idea has been raised of a
optech working group or something to build collaboration between wallet
devs, merchant devs and protocol devs around "Bitcoin payment" issues like
FX risk, additional layers of security for 0confs, RBF and CPFP, etc [0].
While again, I reassert that such a multi-stakeholder forum could be really
fruitful for the ecosystem at large, I don't know if it should be a
prerequisite that we solve all the potential payment issues before
proceeding with full-rbf deployment. However I'm keeping aware about the
interdependency between full-rbf and operational, legal and business issues
that one encounters running a Bitcoin merchant/service, not easy to make
everything works I can guess.
[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021076=
.html
Best,
Antoine
Le ven. 21 oct. 2022 =C3=A0 17:13, Dario Sneidermanis <dario@muun.com> a =
=C3=A9crit :
> Hello Antoine,
>
> Thanks for taking the time to answer every email with detailed analysis! =
I
> can
> see it's a lot of work. I'll answer inline.
>
> On Thu, Oct 20, 2022 at 10:50 PM Antoine Riard <antoine.riard@gmail.com>
> wrote:
> > Personally, I still think deferring full-rbf deployment, while it sound=
s
> > reasonable to let existing services and applications adapt their
> software and
> > business models, doesn't come risk-free for the contracting protocols a=
nd
> > multi-party applications affected by the pinning DoS vector. Deferring =
ad
> > vitam aeternam left them exposed to disruptions when their traffic volu=
me
> > would start to be significant. While those use-cases
> > (splicing/dual-channels/collaborative constructions) were mostly
> vaporware a
> > year ago when I raised the issue, it turns out they have become a far
> more
> > tangible reality today. Beyond the 3 coinjoins services
> > (Wasabi/Joinmarket/Whirlpool), we have new things like ln-vortex, or
> Phoenix
> > wallet and some LDK users planning to use dual-funded soon.
>
> To solve the attack you described in [0], collaborative transaction
> protocols
> (such as dual-funded channels) need a *reliable* way to replace
> transactions.
> Otherwise, protocol parties using full-RBF may see replacements succeed i=
n
> their
> own mempool, only to find out they weren't relayed to a miner once it's
> too late
> (ie. once the replacement that won is mined).
>
> I'm calling a full-RBF deployment reliable to the point at which any
> full-RBF-enabled node can broadcast a replacement and get it relayed all
> the way
> to a miner in a reliable manner (ie. with high-enough probability).
>
> Even if we deployed opt-out (or mandatory!) full-RBF now and miners
> adopted it
> immediately, it would take almost a year (assuming normal deployment
> times) for
> it to be sufficiently deployed in the relaying layer to be considered
> reliable.
> An opt-in full-RBF deployment, as currently proposed (ie. without #25600)=
,
> has
> very little chance of getting us nowhere near that kind of adoption.
>
> Notice that #26323 (option 5 in the OP) has the advantage of getting us t=
o
> a
> reliable full-RBF network the fastest (in particular, much faster than th=
e
> current opt-in deployment) while not threatening zero-conf applications
> until
> the activation time. That is, #26323 gives us a way in which we don't nee=
d
> to
> choose between the security of one use case versus the other. We can have
> both.
>
> > I'm still looking forward to having more forums and communication
> channels
> > between business/services operators and protocol developers, it sounds
> like
> > functional responsibilities between protocol and application layers
> could be
> > better clarified. However, I don't know if it should be the
> responsibility of
> > developers to solve every operational risk encumbered by a Bitcoin
> business,
> > like FX risk. I don't deny the interdependency between network policy
> rules
> > and business risk, I'm just saying Bitcoin protocol developers have
> already
> > heavily loaded engineering priorities between solving the half of dozen
> of
> > Lightning vulnerabilities, working on the next consensus changes or
> reviewing
> > modularity refactoring of Bitcoin Core to extend the feature set in a
> soft way
> > (among tons of other examples).
>
> I don't think asking for a predictable deployment timeline for a change
> that
> would put some applications at increased risk could be described as
> burdening
> the developers with solving every operational risk. This deployment metho=
d
> comparison's goal was precisely to soften the burden on core devs.
>
> Cheers,
> Dario
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033=
.html
>
--000000000000cf6bd105ebbbc71a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Dario,<br><br>Thanks for providing more thoughts to the=
discussion!<br><br>> Notice that #26323 (option 5 in the OP) has the ad=
vantage of getting us to a<br>> reliable full-RBF network the fastest (i=
n particular, much faster than the<br>> current opt-in deployment) while=
not threatening zero-conf applications<br>> until<br>> the activatio=
n time. That is, #26323 gives us a way in which we don't need<br>> t=
o<br>> choose between the security of one use case versus the other. We =
can have<br>> both.<br><br>For sure, contracting protocols and multi-par=
ty applications exposed by the lack of full-rbf are still young overall, th=
ough as they attract more volume they're also likely to become honeypot=
s for any competing services providers interested to hijack economic traffi=
c (kinda the same concern than channel jamming...) At the same time, we sti=
ll have 0confs services more exposed by full-rbf, a bit stuck between Scyll=
a and Charybdis.<br><br>As commented on #26323, I'm personally fine wit=
h this approach, and I fully opine that providing a clear and predictable t=
ime point to 0confs operators is very valuable. Even more, I think May 1st =
2023, is a bit too early, 10-12 months sounds more reasonable.<br><br>At th=
e same time, I believe it's the opinion of a few developers and other B=
itcoin service operators that the Core project is taking too much responsib=
ility in taking for the network by shipping full-rbf=3Dtrue.<br><br>(Really=
I'm 50/50 between those 2 opinions, as I'm the author of both #263=
05 and #25600 and concept ACK on #26323, and any process forward would soun=
ds good to me)<br><br>> I don't think asking for a predictable deplo=
yment timeline for a change that<br>> would put some applications at inc=
reased risk could be described as<br>> burdening<br>> the developers =
with solving every operational risk. This deployment method<br>> compari=
son's goal was precisely to soften the burden on core devs.<br><br>I ca=
n understand the confusion here. As it has been discussed on your original =
thread, from my comprehension, the idea has been raised of a optech working=
group or something to build collaboration between wallet devs, merchant de=
vs and protocol devs around "Bitcoin payment" issues like FX risk=
, additional layers of security for 0confs, RBF and CPFP, etc [0]. While ag=
ain, I reassert that such a multi-stakeholder forum could be really fruitfu=
l for the ecosystem at large, I don't know if it should be a prerequisi=
te that we solve all the potential payment issues before proceeding with fu=
ll-rbf deployment. However I'm keeping aware about the interdependency =
between full-rbf and operational, legal and business issues that one encoun=
ters running a Bitcoin merchant/service, not easy to make everything works =
I can guess.<br><br>[0] <a href=3D"https://lists.linuxfoundation.org/piperm=
ail/bitcoin-dev/2022-October/021076.html">https://lists.linuxfoundation.org=
/pipermail/bitcoin-dev/2022-October/021076.html</a><br><br>Best,<br>Antoine=
<br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_at=
tr">Le=C2=A0ven. 21 oct. 2022 =C3=A0=C2=A017:13, Dario Sneidermanis <<a =
href=3D"mailto:dario@muun.com">dario@muun.com</a>> a =C3=A9crit=C2=A0:<b=
r></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"><div dir=3D"ltr">=
Hello Antoine,<br><br>Thanks for taking the time to answer every email with=
detailed analysis! I can<br>see it's a lot of work. I'll answer in=
line.<br><br>On Thu, Oct 20, 2022 at 10:50 PM Antoine Riard <<a href=3D"=
mailto:antoine.riard@gmail.com" target=3D"_blank">antoine.riard@gmail.com</=
a>> wrote:<br>> Personally, I still think deferring full-rbf deployme=
nt, while it sounds<br>> reasonable to let existing services and applica=
tions adapt their software and<br>> business models, doesn't come ri=
sk-free for the contracting protocols and<br>> multi-party applications =
affected by the pinning DoS vector. Deferring ad<br>> vitam aeternam lef=
t them exposed to disruptions when their traffic volume<br>> would start=
to be significant. While those use-cases<br>> (splicing/dual-channels/c=
ollaborative constructions) were mostly vaporware a<br>> year ago when I=
raised the issue, it turns out they have become a far more<br>> tangibl=
e reality today. Beyond the 3 coinjoins services<br>> (Wasabi/Joinmarket=
/Whirlpool), we have new things like ln-vortex, or Phoenix<br>> wallet a=
nd some LDK users planning to use dual-funded soon.<br><br>To solve the att=
ack you described in [0], collaborative transaction protocols<br>(such as d=
ual-funded channels) need a *reliable* way to replace transactions.<br>Othe=
rwise, protocol parties using full-RBF may see replacements succeed in thei=
r<br>own mempool, only to find out they weren't relayed to a miner once=
it's too late<br>(ie. once the replacement that won is mined).<br><br>=
I'm calling a full-RBF deployment reliable to the point at which any<br=
>full-RBF-enabled node can broadcast a replacement and get it relayed all t=
he way<br>to a miner in a reliable manner (ie. with high-enough probability=
).<br><br>Even if we deployed opt-out (or mandatory!) full-RBF now and mine=
rs adopted it<br>immediately, it would take almost a year (assuming normal =
deployment times) for<br>it to be sufficiently deployed in the relaying lay=
er to be considered reliable.<br>An opt-in full-RBF deployment, as currentl=
y proposed (ie. without #25600), has<br>very little chance of getting us no=
where near that kind of adoption.<br><br>Notice that #26323 (option 5 in th=
e OP) has the advantage of getting us to a<br>reliable full-RBF network the=
fastest (in particular, much faster than the<br>current opt-in deployment)=
while not threatening zero-conf applications until<br>the activation time.=
That is, #26323 gives us a way in which we don't need to<br>choose bet=
ween the security of one use case versus the other. We can have both.<br><b=
r>> I'm still looking forward to having more forums and communicatio=
n channels<br>> between business/services operators and protocol develop=
ers, it sounds like<br>> functional responsibilities between protocol an=
d application layers could be<br>> better clarified. However, I don'=
t know if it should be the responsibility of<br>> developers to solve ev=
ery operational risk encumbered by a Bitcoin business,<br>> like FX risk=
. I don't deny the interdependency between network policy rules<br>>=
and business risk, I'm just saying Bitcoin protocol developers have al=
ready<br>> heavily loaded engineering priorities between solving the hal=
f of dozen of<br>> Lightning vulnerabilities, working on the next consen=
sus changes or reviewing<br>> modularity refactoring of Bitcoin Core to =
extend the feature set in a soft way<br>> (among tons of other examples)=
.<br><br>I don't think asking for a predictable deployment timeline for=
a change that<br>would put some applications at increased risk could be de=
scribed as burdening<br>the developers with solving every operational risk.=
This deployment method<br>comparison's goal was precisely to soften th=
e burden on core devs.<br><br>Cheers,<br>Dario<br><br>[0] <a href=3D"https:=
//lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html" t=
arget=3D"_blank">https://lists.linuxfoundation.org/pipermail/lightning-dev/=
2021-May/003033.html</a><br></div>
</blockquote></div>
--000000000000cf6bd105ebbbc71a--
|