summaryrefslogtreecommitdiff
path: root/3c/48bd820449b8a0fc24506545bfeeb60649d1e4
blob: e78b7886ad1a4dcec7d9f6f615acce2dfbebc16b (plain)
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
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
Return-Path: <dario@muun.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C8A44C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 12 Oct 2022 21:44:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 969FF402F2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 12 Oct 2022 21:44:28 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 969FF402F2
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=muun-com.20210112.gappssmtp.com
 header.i=@muun-com.20210112.gappssmtp.com header.a=rsa-sha256
 header.s=20210112 header.b=cghomvvO
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 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 YR851mp4wny5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 12 Oct 2022 21:44:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org C9666400AF
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com
 [IPv6:2a00:1450:4864:20::332])
 by smtp2.osuosl.org (Postfix) with ESMTPS id C9666400AF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 12 Oct 2022 21:44:26 +0000 (UTC)
Received: by mail-wm1-x332.google.com with SMTP id
 c3-20020a1c3503000000b003bd21e3dd7aso1983905wma.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 12 Oct 2022 14:44:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=muun-com.20210112.gappssmtp.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=Fyp/Jqwj3UxKumsbv4I4WsWK6ecT5BOEwiyiUawyjEQ=;
 b=cghomvvOPTaL5h8nQ2+bMWcEBiGIjBasNZbENk0cHY6Pg23y93zUyQbaar1THpv2uH
 uL0hcjFx+mFiZ7rGkViKvohVMgxLj1z84NxdGMMOSx7X+upVr1PnxrFtdwnvk6qitWA0
 WG0dVeI7Y/3SkBVR0MgSqTATsfIS9h1WFIwPCYJS6B/22PQJ5rvhDbXiby/g9NPhcafM
 /dDTycyzMLJXSX9N5T+oQBc75Wlszrfz21vkbd/vu9GJbjJbUXKGML0GjediZBiN/bvY
 NdJybY+oelsgepl+FacNzLxAGCBrnILHO8WpeCeZBrjgKz6OZm4qz4VAeW72gfkPNwLA
 CTww==
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=Fyp/Jqwj3UxKumsbv4I4WsWK6ecT5BOEwiyiUawyjEQ=;
 b=vAw25UOuywKw17p9TpHY08AlTyRgc8nVxc5jfB2KB6FI5ZG+41wfamZkN2FW9d0tLt
 Dmk2h3od6X+PzZPVn/z7s6dvABfE6L9958FBGM8rXLL2fRgc4xkQJ/yke74P3lcbHNgD
 CNGm0ZhB1+k0UM/qb7c2DlKzKjNvGH0NRuBHSilqUPXduu8TDxwffOM+GuLsvHz+bn0f
 ZHi+1tAFpksuYo9/k69XZ4Jbydf79hWedJWVL480BWNTEtef9qwWzkeQKEVR/oEejqGv
 xkSia/H8HMnqrhwi7bwrVHkyuOy+RkyXJUGJsn72fcnQNJM6eJ1Ubi69zxt8p+tfCbP4
 Ks5A==
X-Gm-Message-State: ACrzQf3EpA+Z29QKtuHCEpu+YG8W67/6JJtJnl5XS0dTp6ls6EYK5FZp
 dHb+Q20mqsqwoNTfNzD1pa9lftD4pOkU9OADlequhvVPkbB0fg==
X-Google-Smtp-Source: AMsMyM5Q9VZkOOww8PC/uqyXeVJ6EEQuJYOyZ6HbY8XfUA+dSdSya6yfqU92jY17SArojDh58k90lxdLuG8vmILXDek=
X-Received: by 2002:a7b:c303:0:b0:3b4:6e89:e5d5 with SMTP id
 k3-20020a7bc303000000b003b46e89e5d5mr4144483wmj.111.1665611064906; Wed, 12
 Oct 2022 14:44:24 -0700 (PDT)
MIME-Version: 1.0
References: <Y0ZTtlRSBihNN9+v@erisian.com.au>
 <0hpdGx-1WbZdG31xaMXGHKTCjJ2-0eB5aIXUdsp3bqI1MlCx6TMZWROwpl1TVI5irrBqRN2-ydM6hmf3M5L-7ZQfazbx66oameiWTHayr6w=@wuille.net>
In-Reply-To: <0hpdGx-1WbZdG31xaMXGHKTCjJ2-0eB5aIXUdsp3bqI1MlCx6TMZWROwpl1TVI5irrBqRN2-ydM6hmf3M5L-7ZQfazbx66oameiWTHayr6w=@wuille.net>
From: Dario Sneidermanis <dario@muun.com>
Date: Wed, 12 Oct 2022 18:44:13 -0300
Message-ID: <CAKiPDnQqEQd+tcPo+PVDvyHW6kz+7Q2HikyzVtjnzpRFT4qa2Q@mail.gmail.com>
To: Pieter Wuille <bitcoin-dev@wuille.net>
Content-Type: multipart/alternative; boundary="000000000000dbaec805eadd4b93"
X-Mailman-Approved-At: Wed, 12 Oct 2022 22:13:23 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate
	danger
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: Wed, 12 Oct 2022 21:44:28 -0000

--000000000000dbaec805eadd4b93
Content-Type: text/plain; charset="UTF-8"

Hello Pieter,

Thanks for taking the time to comment! I'll answer inline.

On Wed, Oct 12, 2022 at 2:51 PM Pieter Wuille <bitcoin-dev@wuille.net>
wrote:
> I certainly recognize that adding the flag is a likely step towards, over
> time, the full RBF policy becoming more widely adopted on the network.
That is
> presumably the reason why people are in favor of having the flag, even
default
> off - including me. I believe that policy's adoption is inevitable
eventually,
> but the speed at which that is achieved is certainly a function of
> availability and adopted of software which provides the option.

As stated in the original posting, I believe too that a full-RBF network is
not
only inevitable but also desirable. Miner incentives will eventually win,
so we
should address them before they fully kick in (ie. before transaction fees
become a meaningful portion of the block reward).

> So I have a hard time imagining how it would change anything
*immediately* on
> the network at large (without things like default on and/or preferential
> peering, ...), but I still believe it's an important step.

Notice that I'm not saying this changes anything immediately on the network
at
large. In fact, it is unlikely that the opt-in flag alone would be enough to
migrate the network at large to full-RBF.

There's a real possibility that, after deployment of the opt-in flag,
either no
meaningful hashing power adopts it or no connected component of
transaction-relaying nodes adopts it. If that's the case, the deployment
won't
help nodes participating in multi-party funded transactions protect against
the
class of attacks described in [1] (which was, as I understand, the original
intention of #25353).

If that's not the case, it means that at least some meaningful hashing power
adopted it and that there exist some connected components of
transaction-relaying nodes that adopted it. This is certainly far from
having
wide adoption of full-RBF in the network at large. However, once we reach
that
minimal level of adoption in the mining and relaying layers, any node on a
full-RBF connected component can send an on-chain payment to an application
and
then get a replacement mined. That is, applications that accept incoming
on-chain payments from untrusted parties can be immediately exposed to
full-RBF
transaction replacements, even if they didn't opt into full-RBF in their
nodes.

In an adversarial setting, such as the one for zero-conf applications (as
defined in the original posting), this increases the risk of an attack
substantially, making the entire strategy moot.

> In my view, it is just what I said: a step towards getting full RBF on the
> network, by allowing experimentation and socializing the notion that
> developers believe it is time.

Those are worthy goals. I believe we can design a deployment strategy for
full-RBF that takes them into account and, at the same time, gives a clear
timeline for any affected application to adapt.

This could be one such proposal:

1. We activate opt-in full-RBF on testnet now.
2. We commit now (in the code) to a block height in the future at which
opt-out
   full-RBF will activate on mainnet.

The first point will allow for experimentation and give a testing ground to
all
affected applications. The second point socializes the notion that
developers
believe it is time, giving a clear message and timeline for anyone affected
to
adapt. It also has the benefit that many more nodes will have upgraded by
the
time we reach the activation block height, making the transition to a
full-RBF
network much more predictable and easy to reason about.

There's an argument to be made that the miner incentive incompatibility
problem
of a non-full-RBF network gets measurably worse at the time of the next
halving.
To fix this, we could choose any block height before that, giving a clear
and
predictable transition timeline.

[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html

On Wed, Oct 12, 2022 at 1:11 PM Pieter Wuille <bitcoin-dev@wuille.net>
wrote:

> On Wednesday, October 12th, 2022 at 1:42 AM, Anthony Towns <
> aj@erisian.com.au> wrote:
>
> > On Tue, Oct 11, 2022 at 04:18:10PM +0000, Pieter Wuille via bitcoin-dev
> wrote:
> >
> > > On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via
> bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
> > >
> > > > Thanks for the fast answer! It seems I missed the link to the PR,
> sorry for the
> > > > confusion. I'm referring to the opt-in flag for full-RBF from #25353
> > > > (https://github.com/bitcoin/bitcoin/pull/25353).
> > > > It is not clear to me why you believe the merging of this particular
> pull request poses an immediate risk to you.
> >
> >
> > Did you see the rest of Dario's reply, bottom-posted after the quoted
> > text? Namely:
>
> Oh, my mail client for some reason chose to hide all that. Dario, I'm
> sorry for missing this; I see now that you were certainly aware of what the
> PR under consideration did.
>
> Further comments inline.
>
> > On Fri, Oct 07, 2022 at 06:37:38PM -0300, Dario Sneidermanis via
>
> > > The question then is whether an opt-in flag for full-RBF will have
> enough
> > > adoption to get us from 1 to 2. If it isn't, then #25353 won't meet its
> > > objective of allowing nodes participating in multi-party funding
> protocols
> > > to assume that they can rely on full-RBF. If it is, then zero-conf
> applications
> > > will be at severe risk (per the logic in the initial email).
>
> >
> >
> > That logic seems reasonably sound to me:
> >
> > - if adding the option does nothing, then there's no point adding it,
> > and no harm in restricting it to test nets only
> >
> > - if adding the option does do something, then businesses using zero-conf
> > need to react immediately, or will go from approximately zero risk of
> > losing funds, to substantial risk
> >
> > (I guess having the option today may allow you to manually switch your
> > node over to supporting fullrbf in future when the majority of the
> network
> > supports it, without needing to do an additional upgrade in the meantime;
> > but that seems like a pretty weak benefit)
>
> I certainly recognize that adding the flag is a likely step towards, over
> time, the full RBF policy becoming more widely adopted on the network. That
> is presumably the reason why people are in favor of having the flag, even
> default off - including me. I believe that policy's adoption is inevitable
> eventually, but the speed at which that is achieved is certainly a function
> of availability and adopted of software which provides the option.
>
> That said, I think it's a bit of a jump to conclude that the only two
> options are that either the existence of the flag either has no effect at
> all, or poses an immediate threat to those relying on its absence. In my
> view, it is just what I said: a step towards getting full RBF on the
> network, by allowing experimentation and socializing the notion that
> developers believe it is time. So I have a hard time imagining how it would
> change anything *immediately* on the network at large (without things like
> default on and/or preferential peering, ...), but I still believe it's an
> important step.
>
> Cheers,
>
> --
> Pieter
>
>

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

<div dir=3D"ltr">Hello Pieter,<br><br>Thanks for taking the time to comment=
! I&#39;ll answer inline.<br><br>On Wed, Oct 12, 2022 at 2:51 PM Pieter Wui=
lle &lt;<a href=3D"mailto:bitcoin-dev@wuille.net">bitcoin-dev@wuille.net</a=
>&gt; wrote:<br>&gt; I certainly recognize that adding the flag is a likely=
 step towards, over<br>&gt; time, the full RBF policy becoming more widely =
adopted on the network. That is<br>&gt; presumably the reason why people ar=
e in favor of having the flag, even default<br>&gt; off - including me. I b=
elieve that policy&#39;s adoption is inevitable eventually,<br>&gt; but the=
 speed at which that is achieved is certainly a function of<br>&gt; availab=
ility and adopted of software which provides the option.<br><br>As stated i=
n the original posting, I believe too that a full-RBF network is not<br>onl=
y inevitable but also desirable. Miner incentives will eventually win, so w=
e<br>should address them before they fully kick in (ie. before transaction =
fees<br>become a meaningful portion of the block reward).<br><br>&gt; So I =
have a hard time imagining how it would change anything *immediately* on<br=
>&gt; the network at large (without things like default on and/or preferent=
ial<br>&gt; peering, ...), but I still believe it&#39;s an important step.<=
br><br>Notice that I&#39;m not saying this changes anything immediately on =
the network at<br>large. In fact, it is unlikely that the opt-in flag alone=
 would be enough to<br>migrate the network at large to full-RBF.<br><br>The=
re&#39;s a real possibility that, after deployment of the opt-in flag, eith=
er no<br>meaningful hashing power adopts it or no connected component of<br=
>transaction-relaying nodes adopts it. If that&#39;s the case, the deployme=
nt won&#39;t<br>help nodes participating in multi-party funded transactions=
 protect against the<br>class of attacks described in [1] (which was, as I =
understand, the original<br>intention of #25353).<br><br>If that&#39;s not =
the case, it means that at least some meaningful hashing power<br>adopted i=
t and that there exist some connected components of<br>transaction-relaying=
 nodes that adopted it. This is certainly far from having<br>wide adoption =
of full-RBF in the network at large. However, once we reach that<br>minimal=
 level of adoption in the mining and relaying layers, any node on a<br>full=
-RBF connected component can send an on-chain payment to an application and=
<br>then get a replacement mined. That is, applications that accept incomin=
g<br>on-chain payments from untrusted parties can be immediately exposed to=
 full-RBF<br>transaction replacements, even if they didn&#39;t opt into ful=
l-RBF in their nodes.<br><br>In an adversarial setting, such as the one for=
 zero-conf applications (as<br>defined in the original posting), this incre=
ases the risk of an attack<br>substantially, making the entire strategy moo=
t.<br><br>&gt; In my view, it is just what I said: a step towards getting f=
ull RBF on the<br>&gt; network, by allowing experimentation and socializing=
 the notion that<br>&gt; developers believe it is time.<br><br>Those are wo=
rthy goals. I believe we can design a deployment strategy for<br>full-RBF t=
hat takes them into account and, at the same time, gives a clear<br>timelin=
e for any affected application to adapt.<br><br>This could be one such prop=
osal:<br><br>1. We activate opt-in full-RBF on testnet now.<br>2. We commit=
 now (in the code) to a block height in the future at which opt-out<br>=C2=
=A0 =C2=A0full-RBF will activate on mainnet.<br><br>The first point will al=
low for experimentation and give a testing ground to all<br>affected applic=
ations. The second point socializes the notion that developers<br>believe i=
t is time, giving a clear message and timeline for anyone affected to<br>ad=
apt. It also has the benefit that many more nodes will have upgraded by the=
<br>time we reach the activation block height, making the transition to a f=
ull-RBF<br>network much more predictable and easy to reason about.<br><br>T=
here&#39;s an argument to be made that the miner incentive incompatibility =
problem<br>of a non-full-RBF network gets measurably worse at the time of t=
he next halving.<br>To fix this, we could choose any block height before th=
at, giving a clear and<br>predictable transition timeline.<br><br>[1] <a hr=
ef=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/00=
3033.html">https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-M=
ay/003033.html</a><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
 class=3D"gmail_attr">On Wed, Oct 12, 2022 at 1:11 PM Pieter Wuille &lt;<a =
href=3D"mailto:bitcoin-dev@wuille.net">bitcoin-dev@wuille.net</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">On Wednesday, =
October 12th, 2022 at 1:42 AM, Anthony Towns &lt;<a href=3D"mailto:aj@erisi=
an.com.au" target=3D"_blank">aj@erisian.com.au</a>&gt; wrote:<br>
<br>
&gt; On Tue, Oct 11, 2022 at 04:18:10PM +0000, Pieter Wuille via bitcoin-de=
v wrote:<br>
&gt; <br>
&gt; &gt; On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via b=
itcoin-dev <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a> wrote:<br>
&gt; &gt; <br>
&gt; &gt; &gt; Thanks for the fast answer! It seems I missed the link to th=
e PR, sorry for the<br>
&gt; &gt; &gt; confusion. I&#39;m referring to the opt-in flag for full-RBF=
 from #25353<br>
&gt; &gt; &gt; (<a href=3D"https://github.com/bitcoin/bitcoin/pull/25353" r=
el=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull=
/25353</a>).<br>
&gt; &gt; &gt; It is not clear to me why you believe the merging of this pa=
rticular pull request poses an immediate risk to you.<br>
&gt; <br>
&gt; <br>
&gt; Did you see the rest of Dario&#39;s reply, bottom-posted after the quo=
ted<br>
&gt; text? Namely:<br>
<br>
Oh, my mail client for some reason chose to hide all that. Dario, I&#39;m s=
orry for missing this; I see now that you were certainly aware of what the =
PR under consideration did.<br>
<br>
Further comments inline.<br>
<br>
&gt; On Fri, Oct 07, 2022 at 06:37:38PM -0300, Dario Sneidermanis via<br>
<br>
&gt; &gt; The question then is whether an opt-in flag for full-RBF will hav=
e enough<br>
&gt; &gt; adoption to get us from 1 to 2. If it isn&#39;t, then #25353 won&=
#39;t meet its<br>
&gt; &gt; objective of allowing nodes participating in multi-party funding =
protocols<br>
&gt; &gt; to assume that they can rely on full-RBF. If it is, then zero-con=
f applications<br>
&gt; &gt; will be at severe risk (per the logic in the initial email).<br>
<br>
&gt; <br>
&gt; <br>
&gt; That logic seems reasonably sound to me:<br>
&gt; <br>
&gt; - if adding the option does nothing, then there&#39;s no point adding =
it,<br>
&gt; and no harm in restricting it to test nets only<br>
&gt; <br>
&gt; - if adding the option does do something, then businesses using zero-c=
onf<br>
&gt; need to react immediately, or will go from approximately zero risk of<=
br>
&gt; losing funds, to substantial risk<br>
&gt; <br>
&gt; (I guess having the option today may allow you to manually switch your=
<br>
&gt; node over to supporting fullrbf in future when the majority of the net=
work<br>
&gt; supports it, without needing to do an additional upgrade in the meanti=
me;<br>
&gt; but that seems like a pretty weak benefit)<br>
<br>
I certainly recognize that adding the flag is a likely step towards, over t=
ime, the full RBF policy becoming more widely adopted on the network. That =
is presumably the reason why people are in favor of having the flag, even d=
efault off - including me. I believe that policy&#39;s adoption is inevitab=
le eventually, but the speed at which that is achieved is certainly a funct=
ion of availability and adopted of software which provides the option.<br>
<br>
That said, I think it&#39;s a bit of a jump to conclude that the only two o=
ptions are that either the existence of the flag either has no effect at al=
l, or poses an immediate threat to those relying on its absence. In my view=
, it is just what I said: a step towards getting full RBF on the network, b=
y allowing experimentation and socializing the notion that developers belie=
ve it is time. So I have a hard time imagining how it would change anything=
 *immediately* on the network at large (without things like default on and/=
or preferential peering, ...), but I still believe it&#39;s an important st=
ep.<br>
<br>
Cheers,<br>
<br>
-- <br>
Pieter<br>
<br>
</blockquote></div>

--000000000000dbaec805eadd4b93--