path: root/a7/80d104f079cf5da9ae987f9a318ba07280f4e9

Return-Path: <antoine.riard@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6B3D3C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Oct 2022 21:42:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 3F83F40136
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Oct 2022 21:42:03 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 3F83F40136
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=M8ksrTlV
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 ldvO79xG3y_2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Oct 2022 21:42:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 33F30400BF
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com
 [IPv6:2607:f8b0:4864:20::d31])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 33F30400BF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Oct 2022 21:42:01 +0000 (UTC)
Received: by mail-io1-xd31.google.com with SMTP id b79so10107519iof.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Oct 2022 14:42:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=cYHkkNIinjd26Ehsunf5aTg82C5+zu8Ly4A3I6aHJes=;
 b=M8ksrTlV/7Z8XcP3lamb5m65mJJIBYVz5kTJXBWIQwrKeZ47R9YH2bw+Fjcwgd2SpX
 6hvNJHBGlBrLy4aV0kM+nlw2iq/GDxu3CzttxbVbMuav11xOK0ZwRU1oDTvaokwvcS87
 uT//1gaQ3bYJBaKDeV04FY4JYIKGxDs8WTE4MVsxLCnfgLNqSV+SBlKYQ6zzRShNmlkR
 o7DaY4+haII4x7OPXxtSMvrwdRFtZzMWQlz/QK+maDbzHMciYO/PiGXdiIHbGl9Heqvh
 KomSK4DbJ0P74+RGb8LOESqFX92BOKt5TF3ZP1tV59RshK3xUeIp8AcI254tMme2Zxei
 3hxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=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=cYHkkNIinjd26Ehsunf5aTg82C5+zu8Ly4A3I6aHJes=;
 b=VgcbF9e7cJgutNfsUIAtWYAeIGV+ZvUq7Fz9dkDHhzbcTd8FQhHWWxbfLgxHzOL1+j
 msrar/13SZBeFxKVKojGdoClpriUPvIXMqRB6d/tDj254Nfz8k/31cSTvBvf9GdFs/pa
 Tdq0A+zXTIrupUkojj/Mar6FJjRDsIMZYiqgL0OjB5rwrvXL+j4/FBKUFiYJUk8ulkRw
 Cn3WPNkchJmIPq0X4gIDzmnmN/WfdCu6V5RFR9qFk5+3BV3Rl0YT96+1EPDgAhl0VaO7
 qbfNsz+z4xnT0911jE4zgGRntHqARV8sBXUPvLBGEqJH2vr3hAWDXPOL7sLwdR1Uj3mp
 ls0g==
X-Gm-Message-State: ACrzQf3IIqNiTQ7DOKucxh7LMP9qN2c+iPuzU5OI5j+FrT2JqXU+lwX8
 Ah7Xlo+I+mh0bsdi6n1jqgPjrMwgcQW9Kf8BBlyQMDbXaZ91Ug==
X-Google-Smtp-Source: AMsMyM6Sd44mhpX681Ka8Zz0WlOg+PGOV5IAkYVLbg1t1rtKx+HkcTZs26DBV9T6hDDubBNpBAabVKObytxaSG2YHI8=
X-Received: by 2002:a6b:f605:0:b0:6bb:cafc:ec27 with SMTP id
 n5-20020a6bf605000000b006bbcafcec27mr5823422ioh.194.1666042920118; Mon, 17
 Oct 2022 14:42:00 -0700 (PDT)
MIME-Version: 1.0
References: <Y0ZTtlRSBihNN9+v@erisian.com.au>
 <0hpdGx-1WbZdG31xaMXGHKTCjJ2-0eB5aIXUdsp3bqI1MlCx6TMZWROwpl1TVI5irrBqRN2-ydM6hmf3M5L-7ZQfazbx66oameiWTHayr6w=@wuille.net>
 <Y0d/e2sEoNRgD7KP@erisian.com.au> <Y0u8Ee2Ao375z8UD@erisian.com.au>
In-Reply-To: <Y0u8Ee2Ao375z8UD@erisian.com.au>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Mon, 17 Oct 2022 17:41:48 -0400
Message-ID: <CALZpt+GSYBFxajSyZS19sQi4_6zHjkA5sP00V-pR=_NEVVUnkg@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000006f2eb005eb41d836"
X-Mailman-Approved-At: Mon, 17 Oct 2022 21:52:10 +0000
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: Mon, 17 Oct 2022 21:42:03 -0000

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

Hi AJ,

>  1) Continue supporting and encouraging accepting unconfirmed "on-chain"
>     payments indefinitely
>
>  2) Draw a line in the sand now, but give people who are currently
>     accepting unconfirmed txs time to update their software and business
>     model
>
>  3) Encourage mainnet miners and relay nodes to support unconditional
>     RBF immediately, no matter how much that increases the risk to
>     existing businesses that are still accepting unconfirmed txs

To give more context, the initial approach of enabling full RBF through
#25353 + #25600 wasn't making the assumption the enablement itself would
reach agreement of the economic majority or unanimity. Rather, it would
give the tools to node operators to build full-rbf relay paths and as such
to fulfill their applications requirements (e.g lightning dual-funding).
Without denying that such equilibrium would be unstable, it was designed to
remove the responsibility of the Core project itself to "draw a hard line"
on the subject. Moreover, relying on node operators turning on the setting
provides a smoother approach offering time to zero-conf services to react
in consequence.

So the current path definitely belongs more to a 3) approach. While this
way cannot be denied to be a zero-risk deployment for business accepting
unconfirmed transactions, it should be weighed in face of multi-party
contracting protocols encumbering an annoying pinning vector. It sounds to
me that an adequate way to resolve such a "split-risk" situation has been
to adopt a "micro" release practice rather than a "macro" one, namely offer
the options to node operators and let them vote with their respective
economic traffics.

Since Dario's mail, I think we have learnt new data points, a) on the long
term full RBF to align miner incentives is acknowledged and b) a clear
timeline based on e.g a block height is favored over the pollination
deployment.

As such, I think it makes sense to revise the full RBF deployment approach,
concentrating the discussion on the reasonable time buffer we should adopt
before activating full RBF on mainet. A time buffer realistic with respect
to the engineering,
operational and vendoring needs of the zero-conf businesses/applications. I
hope both #26305 and #26323 answer those criterias. Tie-breaking between
both, I believe I would favor something like #26323 though only post 24.0
to avoid introducing a bikeshedding precedent in terms of release process,
and with a longer timeline to be sure we ship 25.0 before the activation
day. Though listening to more feedback and decision factors, if we have
more things to consider.

> But if (3) *is* what we're really trying to do, I think it's a bit
> disingenuous to assume that that effort will fail, and tell people that
> nothing's going to change on mainnet in the near future [8] [9] [10]
> [11]. If pools are starting to allow replacements of txs that didn't
> signal according to BIP 125 and mine blocks including those replacements,
> then it's true that zero-conf apps are in much more immediate danger
> than they were a month ago, and as far as I can see, we shouldn't be
> pretending otherwise.

Concerning my statement only, it should be re-contextualize with the other
statements calling the zero-conf operators to adapt their services, or
raise concerns, or be proactive at least [0]. On the other hand, from my
perspective, a status quo situation is also unsafe, as we left things like
multi-party coinjoins being DoSed by deanonymizing attackers. So in case of
risk arbitrage situation, as developers, best we can do is be vocal about
it and if possible find a common ground among all stakeholders. And I think
this is what this current thread aims to achieve, which I would say is a
healthy release process.

Best,
Antoine

[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.ht=
ml

Le dim. 16 oct. 2022 =C3=A0 04:09, Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :

> On Thu, Oct 13, 2022 at 02:35:22PM +1000, Anthony Towns via bitcoin-dev
> wrote:
> > On Wed, Oct 12, 2022 at 04:11:05PM +0000, Pieter Wuille via bitcoin-dev
> wrote:
> > > In my view, it is just what I said: a step towards getting full RBF
> > > on the network, by allowing experimentation and socializing the notio=
n
> > > that developers believe it is time.
> > We "believe it is time" for what exactly, though? (a) To start
> > deprerecating accepting zeroconf txs on mainnet, over the next 6, 12 or
> > 18 months; or (b) to start switching mainnet mining and relay nodes ove=
r
> > to full RBF?
>
> For what it's worth, that was a serious question: I don't feel like I
> know what other people's answer to it is.
>
> Seems to me like there's fundamentally maybe three approaches:
>
>  1) Continue supporting and encouraging accepting unconfirmed "on-chain"
>     payments indefinitely
>
>  2) Draw a line in the sand now, but give people who are currently
>     accepting unconfirmed txs time to update their software and business
>     model
>
>  3) Encourage mainnet miners and relay nodes to support unconditional
>     RBF immediately, no matter how much that increases the risk to
>     existing businesses that are still accepting unconfirmed txs
>
> I think Antoine gave a pretty decent rationale for why we shouldn't
> indefinitely continue with conditional RBF in [0] [1] -- it makes it
> easy to disrupt decentralised pooling protocols, whether that be for
> establishing lightning channels or coinjoins or anything else.
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033=
.html
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.=
html
>
> It's also an unstable equilibrium -- if everyone does first-seen-is-final
> at the mempool level, everything is fine; but it only takes a few
> defectors to start relaying and mining full RBF txs to spoil zeroconf
> for everyone -- so even if it were desirable to maintain it forever,
> it's probably not actually possible to maintain it indefinitely.
>
> If so, that leaves the choice between (2) and (3). You might argue
> that there's a 4th option: ignore the problem and think about it later;
> but to me that seems like it will just eventually result in outcome (3).
>
>
> At least a few people are already running full RBF relay nodes [2] [3]
> [4], and there's a report that non-signalling RBF txs are now getting
> mined [5] when they weren't a few months ago [6]. I wasn't able to
> confirm the latter to my satisfaction: looking at mempool.observer, the
> non-RBF signalling conflicting txs don't seem to have been consistently
> paying a higher feerate, so I couldn't rule out the possibility that
> the difference might just be due to inconsistent relaying.
>
> [2] https://twitter.com/murchandamus/status/1552488955328831492
> [3] https://twitter.com/LukeDashjr/status/977211607947317254
> [4]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.=
html
> [5]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.=
html
> [6]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.=
html
>
> It seems to me that the best approach for implementing (3) would be
> to change the default for -mempoolfullrbf to true immediately, which
> is both what Knots has been doing for years, and what #26305 proposes
> [7].  So from seeing what people are actually *doing*, I could easily
> be convinced that (3) is the goal people are actually working towards.
>
> [7] https://github.com/bitcoin/bitcoin/pull/26305
>
> But if (3) *is* what we're really trying to do, I think it's a bit
> disingenuous to assume that that effort will fail, and tell people that
> nothing's going to change on mainnet in the near future [8] [9] [10]
> [11]. If pools are starting to allow replacements of txs that didn't
> signal according to BIP 125 and mine blocks including those replacements,
> then it's true that zero-conf apps are in much more immediate danger
> than they were a month ago, and as far as I can see, we shouldn't be
> pretending otherwise.
>
> [8] https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1274953204
> [9] https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1276682043
> [10]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/0209=
81.html
> [11]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/0210=
06.html
>
> Personally, I prefer an approach like (2) -- commit to doing something
> first, give people time to prepare for it, and then do it, and outside
> of Knots, I don't think there's been any clear commitment to deprecating
> zeroconf txs up until now. But what we're currently doing is suboptimal
> for that in two ways:
>
>  - there's no real commitment that the change will actually happen
>  - even if it does, there's no indication when that will be
>  - it's not easy to test your apps against the new world order, because
>    it's not well supported on either testnet or signet, being disabled
>    by default on both those networks
>
> Dario suggested an approach [12] that seems like it would resolve all
> these issues:
>
> ] This could be one such proposal:
> ] 1. We activate [..] full-RBF on testnet now.
> ] 2. We commit now (in the code) to a block height in the future at
> ]    which [..] full-RBF will activate on mainnet.
>
> (I've delted the words "opt-in" and "opt-out" from the quote above,
> because they didn't make sense to me)
>
> [12]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/0210=
07.html
>
> I've made up a patch along these lines [13]; it's easy to use a timestamp
> rather than a block height, so I've arbitrarily picked 1st May (slightly
> over 6 months away) as the changeover time. If people are willing to
> give zeroconf businesses some time to adapt, including something along
> those lines in 24.0 seems a better approach to me:
>
>  * it gives a clear deadline for businesses to adapt, so that they don't
>    defer it and suddenly complain "oh no, we didn't think you were
>    serious, please give us more time" later
>
>  * it gives plenty(?) of time to update your code and test it, as well
>    as teach customers and customer support about the new behaviour
>
>  * when the deadline hits, presumably plenty of nodes and miners will
>    immediately start supporting the new behaviour on mainnet, so that
>    protocols can quickly start relying on that method of tx pinning no
>    longer being applicable
>
>  * nodes on signet and testnet will quickly adopt the new behaviour,
>    well before it's available on mainnet, making testing easier
>
> [13] https://github.com/bitcoin/bitcoin/pull/26323
>
> To me, this seems like a good way of achieving what I said previously:
>
> > If we're trying to socialise the idea that zeroconf deprecation is
> > happening and that your business now has a real deadline for migrating
> > away from accepting unconfirmed txs if the risk of being defrauded
> > concerns you, then enabling experimentation on test nets and not touchi=
ng
> > mainnet until a later release seems fairly fine to me -- similar to
> > activating soft forks on test nets prior to activating it on mainnet.
>
> Cheers,
> aj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Hi AJ,<br><br>&gt; =C2=A01) Continue supporting and encour=
aging accepting unconfirmed &quot;on-chain&quot;<br>&gt; =C2=A0 =C2=A0 paym=
ents indefinitely<br>&gt; <br>&gt; =C2=A02) Draw a line in the sand now, bu=
t give people who are currently<br>&gt; =C2=A0 =C2=A0 accepting unconfirmed=
 txs time to update their software and business<br>&gt; =C2=A0 =C2=A0 model=
<br>&gt; <br>&gt; =C2=A03) Encourage mainnet miners and relay nodes to supp=
ort unconditional<br>&gt; =C2=A0 =C2=A0 RBF immediately, no matter how much=
 that increases the risk to<br>&gt; =C2=A0 =C2=A0 existing businesses that =
are still accepting unconfirmed txs<br><br>To give more context, the initia=
l approach of enabling full RBF through #25353 + #25600 wasn&#39;t making t=
he assumption the enablement itself would reach agreement of the economic m=
ajority or unanimity. Rather, it would give the tools to node operators to =
build full-rbf relay paths and as such to fulfill their applications requir=
ements (e.g lightning dual-funding). Without denying that such equilibrium =
would be unstable, it was designed to remove the responsibility of the Core=
 project itself to &quot;draw a hard line&quot; on the subject. Moreover, r=
elying on node operators turning on the setting provides a smoother approac=
h offering time to zero-conf services to react in consequence.<br><br>So th=
e current path definitely belongs more to a 3) approach. While this way can=
not be denied to be a zero-risk deployment for business accepting unconfirm=
ed transactions, it should be weighed in face of multi-party contracting pr=
otocols encumbering an annoying pinning vector. It sounds to me that an ade=
quate way to resolve such a &quot;split-risk&quot; situation has been to ad=
opt a &quot;micro&quot; release practice rather than a &quot;macro&quot; on=
e, namely offer the options to node operators and let them vote with their =
respective economic traffics.<br><br>Since Dario&#39;s mail, I think we hav=
e learnt new data points, a) on the long term full RBF to align miner incen=
tives is acknowledged and b) a clear timeline based on e.g a block height i=
s favored over the pollination deployment.<br><br>As such, I think it makes=
 sense to revise the full RBF deployment approach, concentrating the discus=
sion on the reasonable time buffer we should adopt before activating full R=
BF on mainet. A time buffer realistic with respect to the engineering,<br>o=
perational and vendoring needs of the zero-conf businesses/applications. I =
hope both #26305 and #26323 answer those criterias. Tie-breaking between bo=
th, I believe I would favor something like #26323 though only post 24.0 to =
avoid introducing a bikeshedding precedent in terms of release process, and=
 with a longer timeline to be sure we ship 25.0 before the activation day. =
Though listening to more feedback and decision factors, if we have more thi=
ngs to consider.<br><br>&gt; But if (3) *is* what we&#39;re really trying t=
o do, I think it&#39;s a bit<br>&gt; disingenuous to assume that that effor=
t will fail, and tell people that<br>&gt; nothing&#39;s going to change on =
mainnet in the near future [8] [9] [10]<br>&gt; [11]. If pools are starting=
 to allow replacements of txs that didn&#39;t<br>&gt; signal according to B=
IP 125 and mine blocks including those replacements,<br>&gt; then it&#39;s =
true that zero-conf apps are in much more immediate danger<br>&gt; than the=
y were a month ago, and as far as I can see, we shouldn&#39;t be<br>&gt; pr=
etending otherwise.<br><br>Concerning my statement only, it should be re-co=
ntextualize with the other statements calling the zero-conf operators to ad=
apt their services, or raise concerns, or be proactive at least [0]. On the=
 other hand, from my perspective, a status quo situation is also unsafe, as=
 we left things like multi-party coinjoins being DoSed by deanonymizing att=
ackers. So in case of risk arbitrage situation, as developers, best we can =
do is be vocal about it and if possible find a common ground among all stak=
eholders. And I think this is what this current thread aims to achieve, whi=
ch I would say is a healthy release process.<br><br>Best,<br>Antoine<br><br=
>[0] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/202=
2-June/020557.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev=
/2022-June/020557.html</a><br></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">Le=C2=A0dim. 16 oct. 2022 =C3=A0=C2=A004:09, =
Anthony Towns via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linux=
foundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; a =C3=A9crit=
=C2=A0:<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 Thu, =
Oct 13, 2022 at 02:35:22PM +1000, Anthony Towns via bitcoin-dev wrote:<br>
&gt; On Wed, Oct 12, 2022 at 04:11:05PM +0000, Pieter Wuille via bitcoin-de=
v wrote:<br>
&gt; &gt; In my view, it is just what I said: a step towards getting full R=
BF<br>
&gt; &gt; on the network, by allowing experimentation and socializing the n=
otion<br>
&gt; &gt; that developers believe it is time.<br>
&gt; We &quot;believe it is time&quot; for what exactly, though? (a) To sta=
rt<br>
&gt; deprerecating accepting zeroconf txs on mainnet, over the next 6, 12 o=
r<br>
&gt; 18 months; or (b) to start switching mainnet mining and relay nodes ov=
er<br>
&gt; to full RBF?<br>
<br>
For what it&#39;s worth, that was a serious question: I don&#39;t feel like=
 I<br>
know what other people&#39;s answer to it is.<br>
<br>
Seems to me like there&#39;s fundamentally maybe three approaches:<br>
<br>
=C2=A01) Continue supporting and encouraging accepting unconfirmed &quot;on=
-chain&quot;<br>
=C2=A0 =C2=A0 payments indefinitely<br>
<br>
=C2=A02) Draw a line in the sand now, but give people who are currently<br>
=C2=A0 =C2=A0 accepting unconfirmed txs time to update their software and b=
usiness<br>
=C2=A0 =C2=A0 model<br>
<br>
=C2=A03) Encourage mainnet miners and relay nodes to support unconditional<=
br>
=C2=A0 =C2=A0 RBF immediately, no matter how much that increases the risk t=
o<br>
=C2=A0 =C2=A0 existing businesses that are still accepting unconfirmed txs<=
br>
<br>
I think Antoine gave a pretty decent rationale for why we shouldn&#39;t<br>
indefinitely continue with conditional RBF in [0] [1] -- it makes it<br>
easy to disrupt decentralised pooling protocols, whether that be for<br>
establishing lightning channels or coinjoins or anything else.<br>
<br>
[0] <a href=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/20=
21-May/003033.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linu=
xfoundation.org/pipermail/lightning-dev/2021-May/003033.html</a><br>
[1] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022=
-June/020557.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linux=
foundation.org/pipermail/bitcoin-dev/2022-June/020557.html</a><br>
<br>
It&#39;s also an unstable equilibrium -- if everyone does first-seen-is-fin=
al<br>
at the mempool level, everything is fine; but it only takes a few<br>
defectors to start relaying and mining full RBF txs to spoil zeroconf<br>
for everyone -- so even if it were desirable to maintain it forever,<br>
it&#39;s probably not actually possible to maintain it indefinitely.<br>
<br>
If so, that leaves the choice between (2) and (3). You might argue<br>
that there&#39;s a 4th option: ignore the problem and think about it later;=
<br>
but to me that seems like it will just eventually result in outcome (3).<br=
>
<br>
<br>
At least a few people are already running full RBF relay nodes [2] [3]<br>
[4], and there&#39;s a report that non-signalling RBF txs are now getting<b=
r>
mined [5] when they weren&#39;t a few months ago [6]. I wasn&#39;t able to<=
br>
confirm the latter to my satisfaction: looking at mempool.observer, the<br>
non-RBF signalling conflicting txs don&#39;t seem to have been consistently=
<br>
paying a higher feerate, so I couldn&#39;t rule out the possibility that<br=
>
the difference might just be due to inconsistent relaying.<br>
<br>
[2] <a href=3D"https://twitter.com/murchandamus/status/1552488955328831492"=
 rel=3D"noreferrer" target=3D"_blank">https://twitter.com/murchandamus/stat=
us/1552488955328831492</a><br>
[3] <a href=3D"https://twitter.com/LukeDashjr/status/977211607947317254" re=
l=3D"noreferrer" target=3D"_blank">https://twitter.com/LukeDashjr/status/97=
7211607947317254</a><br>
[4] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022=
-June/020592.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linux=
foundation.org/pipermail/bitcoin-dev/2022-June/020592.html</a><br>
[5] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022=
-June/020592.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linux=
foundation.org/pipermail/bitcoin-dev/2022-June/020592.html</a><br>
[6] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022=
-June/020592.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linux=
foundation.org/pipermail/bitcoin-dev/2022-June/020592.html</a><br>
<br>
It seems to me that the best approach for implementing (3) would be<br>
to change the default for -mempoolfullrbf to true immediately, which<br>
is both what Knots has been doing for years, and what #26305 proposes<br>
[7].=C2=A0 So from seeing what people are actually *doing*, I could easily<=
br>
be convinced that (3) is the goal people are actually working towards.<br>
<br>
[7] <a href=3D"https://github.com/bitcoin/bitcoin/pull/26305" rel=3D"norefe=
rrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/26305</a><b=
r>
<br>
But if (3) *is* what we&#39;re really trying to do, I think it&#39;s a bit<=
br>
disingenuous to assume that that effort will fail, and tell people that<br>
nothing&#39;s going to change on mainnet in the near future [8] [9] [10]<br=
>
[11]. If pools are starting to allow replacements of txs that didn&#39;t<br=
>
signal according to BIP 125 and mine blocks including those replacements,<b=
r>
then it&#39;s true that zero-conf apps are in much more immediate danger<br=
>
than they were a month ago, and as far as I can see, we shouldn&#39;t be<br=
>
pretending otherwise.<br>
<br>
[8] <a href=3D"https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1=
274953204" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/=
bitcoin/pull/26287#issuecomment-1274953204</a><br>
[9] <a href=3D"https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1=
276682043" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/=
bitcoin/pull/26287#issuecomment-1276682043</a><br>
[10] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/202=
2-October/020981.html" rel=3D"noreferrer" target=3D"_blank">https://lists.l=
inuxfoundation.org/pipermail/bitcoin-dev/2022-October/020981.html</a><br>
[11] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/202=
2-October/021006.html" rel=3D"noreferrer" target=3D"_blank">https://lists.l=
inuxfoundation.org/pipermail/bitcoin-dev/2022-October/021006.html</a><br>
<br>
Personally, I prefer an approach like (2) -- commit to doing something<br>
first, give people time to prepare for it, and then do it, and outside<br>
of Knots, I don&#39;t think there&#39;s been any clear commitment to deprec=
ating<br>
zeroconf txs up until now. But what we&#39;re currently doing is suboptimal=
<br>
for that in two ways:<br>
<br>
=C2=A0- there&#39;s no real commitment that the change will actually happen=
<br>
=C2=A0- even if it does, there&#39;s no indication when that will be<br>
=C2=A0- it&#39;s not easy to test your apps against the new world order, be=
cause<br>
=C2=A0 =C2=A0it&#39;s not well supported on either testnet or signet, being=
 disabled<br>
=C2=A0 =C2=A0by default on both those networks<br>
<br>
Dario suggested an approach [12] that seems like it would resolve all<br>
these issues:<br>
<br>
] This could be one such proposal:<br>
] 1. We activate [..] full-RBF on testnet now.<br>
] 2. We commit now (in the code) to a block height in the future at<br>
]=C2=A0 =C2=A0 which [..] full-RBF will activate on mainnet.<br>
<br>
(I&#39;ve delted the words &quot;opt-in&quot; and &quot;opt-out&quot; from =
the quote above,<br>
because they didn&#39;t make sense to me)<br>
<br>
[12] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/202=
2-October/021007.html" rel=3D"noreferrer" target=3D"_blank">https://lists.l=
inuxfoundation.org/pipermail/bitcoin-dev/2022-October/021007.html</a><br>
<br>
I&#39;ve made up a patch along these lines [13]; it&#39;s easy to use a tim=
estamp<br>
rather than a block height, so I&#39;ve arbitrarily picked 1st May (slightl=
y<br>
over 6 months away) as the changeover time. If people are willing to<br>
give zeroconf businesses some time to adapt, including something along<br>
those lines in 24.0 seems a better approach to me:<br>
<br>
=C2=A0* it gives a clear deadline for businesses to adapt, so that they don=
&#39;t<br>
=C2=A0 =C2=A0defer it and suddenly complain &quot;oh no, we didn&#39;t thin=
k you were<br>
=C2=A0 =C2=A0serious, please give us more time&quot; later<br>
<br>
=C2=A0* it gives plenty(?) of time to update your code and test it, as well=
<br>
=C2=A0 =C2=A0as teach customers and customer support about the new behaviou=
r<br>
<br>
=C2=A0* when the deadline hits, presumably plenty of nodes and miners will<=
br>
=C2=A0 =C2=A0immediately start supporting the new behaviour on mainnet, so =
that<br>
=C2=A0 =C2=A0protocols can quickly start relying on that method of tx pinni=
ng no<br>
=C2=A0 =C2=A0longer being applicable<br>
<br>
=C2=A0* nodes on signet and testnet will quickly adopt the new behaviour,<b=
r>
=C2=A0 =C2=A0well before it&#39;s available on mainnet, making testing easi=
er<br>
<br>
[13] <a href=3D"https://github.com/bitcoin/bitcoin/pull/26323" rel=3D"noref=
errer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/26323</a><=
br>
<br>
To me, this seems like a good way of achieving what I said previously:<br>
<br>
&gt; If we&#39;re trying to socialise the idea that zeroconf deprecation is=
<br>
&gt; happening and that your business now has a real deadline for migrating=
<br>
&gt; away from accepting unconfirmed txs if the risk of being defrauded<br>
&gt; concerns you, then enabling experimentation on test nets and not touch=
ing<br>
&gt; mainnet until a later release seems fairly fine to me -- similar to<br=
>
&gt; activating soft forks on test nets prior to activating it on mainnet.<=
br>
<br>
Cheers,<br>
aj<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>

--0000000000006f2eb005eb41d836--