path: root/4a/822b7e1ff1e0b4c563dc03fda675a12ab78f46

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 8868BC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Oct 2022 14:25:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 5797D4099F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Oct 2022 14:25:49 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 5797D4099F
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=WtlpQHFf
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 rPyur3JkEfag
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Oct 2022 14:25:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org F235A41763
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [IPv6:2a00:1450:4864:20::629])
 by smtp4.osuosl.org (Postfix) with ESMTPS id F235A41763
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Oct 2022 14:25:46 +0000 (UTC)
Received: by mail-ej1-x629.google.com with SMTP id w18so25294109ejq.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Oct 2022 07:25:46 -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=Q+kmFAO8BltFncrZEulw8bQX4M28BEyTAz+BRv6iP3c=;
 b=WtlpQHFf/FncugJALSI1YraMkgxBVqBt/miOTuXU1pECUCc0HfBaylucoptwI5dVey
 z/ccetfrcTtTMbcACsDvt9yYaTanhX0oWUyGTDlyySNF5tdoYVpfT3dXE+vQtV+4h9gz
 BZ179vy92Vo22Boo+WpAwf019ZMyPAQpzlIdpnTFgPPYP/7aYkcY+f42A4DR1O31YU72
 2JoeUfgG89toqwPJtu5u6lplyEnzkipUjqXRMOB+rsmLZgpLJgVhoxc6A0TxssKr/oE+
 IKUAyo+Qvfagk7OndzMUhWYrQrpW4h7mNiA2efSodcXHgkJ2EvrD004x1BYf3syWsW3O
 UjEA==
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=Q+kmFAO8BltFncrZEulw8bQX4M28BEyTAz+BRv6iP3c=;
 b=SxSfKp6IdBg5xuH2qoFrvbPUolYAVYt7OrpC36lncYk/HCgpGku/AkmC0FSOKCNsOq
 /vzpz+8MgFFOwCPozuB0KVEocsgzqGi63mQfljzLuiBbaIVqGLj2DkQzb9qdeUSP7N0y
 6SM6HL6W4ESFD3RD82Gs5JjRP0VwMDFFL9oJt5zc2Qan1n8rAPnA1+1LGUzqOiuEGAk8
 IgnmHBBGNh01JFdMfwdyVm1zyyaooQLQGhTHXc93KoSP2GGTN5QGIGRZZAfkXZCmTlud
 JFhmyTaZnv9UCJsvEINRXqBEiWmE+F4Cj8VIYxcd9Ri5FZZa8jb2nvdXnUtodtPRAXYa
 5sxw==
X-Gm-Message-State: ACrzQf1EP6z4Mk8aIQ2erCRSqNtsnECVRavcOz7XMNAB59Q6bnDCjzos
 BB1HpWmfd9+1i6oGSLGaG/CcDDbPXx7NMF9gD1W69v09ZHs=
X-Google-Smtp-Source: AMsMyM5lXnvrKP66wb0uqPbMukDnXxForaR84rBjQQs3U3vEdCuiKvqnffQpTc6xkxxD37ifAMao1psgFhEuqWtMAP4=
X-Received: by 2002:a17:907:2702:b0:78e:e94:2ac4 with SMTP id
 w2-20020a170907270200b0078e0e942ac4mr8843110ejk.679.1666016744846; Mon, 17
 Oct 2022 07:25:44 -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: Greg Sanders <gsanders87@gmail.com>
Date: Mon, 17 Oct 2022 10:25:33 -0400
Message-ID: <CAB3F3Du2K--1MLWaTRKZZns0LQZ_PdWT67EwSkUGstbt2V77Pw@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000443ada05eb3bc0fd"
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 14:25:49 -0000

--000000000000443ada05eb3bc0fd
Content-Type: text/plain; charset="UTF-8"

 AJ,

Thanks for the latest PR and discussion, even if we know we're all (very,
very, very) tired of it running almost 10 years now. I think we're close to
a resolution, (2), or (3) as you note.

As ariard notes in
https://github.com/bitcoin/bitcoin/pull/26323#issuecomment-1280071572 we
seem to have sketched out the sane design space for the transition, so now
it's time to choose how we want to spend our energy and time on this.

I do think patch complexity is a real concern, which
means fullrbf-signalling PR has a harder road to deployment and gets push
back from fullrbf-default-now folks who correctly argue this. It seems
useful to "prove a point" on the nature of these schemes, but not much else.

Personally I have no qualms with kicking back flag-day-fullrbf another
release cycle and 6 additional months to obviate the need for a 24.0
backport(however small!) and to give a bit more time to weigh choices.
People can begin testing with their node software on an opt-in basis(but
not the required ~10% of nodes), 25.0+ nodes will flag-day, then a year
from now the community can start testing if miners have picked up said
changes.

Speaking to no one in particular, there's no virtue in dragging on the
discussion to "prove a point" to "merchants"/"Core devs" when we could be
spending our time more wisely fixing the many other issues with our mempool
and wallet ecosystem.

Best,
Greg

On Sun, Oct 16, 2022 at 4:09 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 notion
> > > 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 over
> > 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/020981.html
> [11]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021006.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/021007.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 touching
> > 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
>

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

<div dir=3D"ltr">=C2=A0AJ,<div><br></div><div>Thanks for the latest PR and =
discussion, even if we know we&#39;re all (very, very, very) tired of it ru=
nning almost 10 years now. I think we&#39;re close to a resolution, (2), or=
 (3) as you note.</div><div><br></div><div>As ariard notes in=C2=A0<a href=
=3D"https://github.com/bitcoin/bitcoin/pull/26323#issuecomment-1280071572">=
https://github.com/bitcoin/bitcoin/pull/26323#issuecomment-1280071572</a> w=
e seem to have sketched out the sane design space for the transition, so no=
w it&#39;s time to choose how we want to spend our energy and time on this.=
</div><div><br></div><div>I do think patch complexity is a real concern, wh=
ich means=C2=A0fullrbf-signalling=C2=A0PR has a harder road to deployment a=
nd gets push back from fullrbf-default-now=C2=A0folks who correctly argue t=
his. It seems useful to &quot;prove a point&quot; on the nature of these sc=
hemes, but not much else.<br></div><div><br></div><div>Personally I have no=
 qualms with kicking back flag-day-fullrbf another release cycle and 6 addi=
tional months to obviate the need for a 24.0 backport(however small!) and t=
o give a bit more time to weigh choices. People can begin testing with thei=
r node software on an opt-in basis(but not the required ~10% of nodes), 25.=
0+ nodes will flag-day, then a year from now the community can start testin=
g if miners have picked up said changes.</div><div><br></div><div>Speaking =
to no one in particular, there&#39;s no virtue in dragging on the discussio=
n to &quot;prove a point&quot; to &quot;merchants&quot;/&quot;Core devs&quo=
t; when we could be spending our time more wisely fixing the many other iss=
ues with our mempool and wallet ecosystem.</div><div><br></div><div>Best,</=
div><div>Greg</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cl=
ass=3D"gmail_attr">On Sun, Oct 16, 2022 at 4:09 AM Anthony Towns via bitcoi=
n-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-=
dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">On Thu, Oct 13, 2022 at 02:35:22PM +1000, Anth=
ony 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>

--000000000000443ada05eb3bc0fd--