MIME-Version: 1.0
References: <CAKiPDnTPyduCm2Db0v51m_hbCSGbZcUcCwg9=hwJGKeiFeTWBg@mail.gmail.com>
 <1ee5a4e7ecffa0f638bbd45b195ecca6@dtrt.org>
In-Reply-To: <1ee5a4e7ecffa0f638bbd45b195ecca6@dtrt.org>
From: Dario Sneidermanis <dario@muun.com>
Date: Fri, 7 Oct 2022 18:37:38 -0300
Message-ID: <CAKiPDnQzJBZ6cCRCFM7j01cNz=BcU_-_AcTh3jVo-Metpnek3w@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="0000000000001b825305ea789f0f"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate
	danger
Precedence: list

--0000000000001b825305ea789f0f
Content-Type: text/plain; charset="UTF-8"

Hello David,

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).

On Fri, Oct 7, 2022 at 2:21 PM David A. Harding <dave@dtrt.org> wrote:

> On 2022-10-07 06:20, Dario Sneidermanis via bitcoin-dev wrote:
> > Hello list,
> >
> > I'm Dario, from Muun wallet [...] we've been reviewing the latest
> > bitcoin core release
> > candidate [...] we understood we had at least a year from the initial
> > opt-in  deployment until opt-out was deployed, giving us enough time to
> > adapt
> > Muun to the new policies. However, when reviewing the 24.0 release
> > candidate
> > just a few  days ago, we realized that zero-conf apps (like Muun) must
> > *immediately turn off* their zero-conf features.
>
> Hi Dario,
>
> I'm wondering if there's been some confusion.  There are two RBF-related
> items in the current release notes draft:[1]
>
> 1. "A new mempoolfullrbf option has been added, which enables the
> mempool to accept transaction replacement without enforcing BIP125
> replaceability signaling. (#25353)"
>
> 2. "The -walletrbf startup option will now default to true. The wallet
> will now default to opt-in RBF on transactions that it creates.
> (#25610)"
>
> The first item (from PR #25353) does allow a transaction without a
> BIP125 signal to be replaced, but this configuration option is set to
> disabled by default.[2]  There have been software forks of Bitcoin Core
> since at least 2015 which have allowed replacement of non-signaling
> transactions, so this option just makes that behavior a little bit more
> accessible to users of Bitcoin Core.


The "activation" of full-RBF after deployment works in a pretty interesting
way:

1. If no miner is running full-RBF or there aren't easily accessible
connected
   components of nodes running full-RBF connected to the miners, then
full-RBF
   is mostly ineffective since replacements aren't relayed and/or mined.
2. There's a middle ground where *some* connected components of full-RBF
nodes
   can relay and mine replacements, where some full-RBF nodes will be able
to
   replace via full-RBF and some won't (depending on their peers).
3. With high enough adoption, the relay graph has enough density of full-RBF
   nodes that almost all full-RBF nodes can replace transactions via
full-RBF.

While there have been forks of Bitcoin Core (like Bitcoin Knots) running
full-RBF for a while, today most nodes (by far) are running Bitcoin Core.
So,
Bitcoin Core adding an opt-in flag (ie. off by default) makes it easier to
be
picked up by most node operators. Making the flag opt-out (ie. on by
default)
would make it easier still. We are dealing with a gradient going from hard
enough that we are still in 1, to easy enough that we get to 3.

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).

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

<div dir=3D"ltr"><div dir=3D"ltr">Hello David,<br><br>Thanks for the fast a=
nswer! It seems I missed the link to the PR,=C2=A0sorry for the</div><div d=
ir=3D"ltr">confusion. I&#39;m referring to the opt-in flag for full-RBF fro=
m #25353<br>(<a href=3D"https://github.com/bitcoin/bitcoin/pull/25353">http=
s://github.com/bitcoin/bitcoin/pull/25353</a>).<br></div><br><div class=3D"=
gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Oct 7, 2022 at 2=
:21 PM David A. Harding &lt;<a href=3D"mailto:dave@dtrt.org">dave@dtrt.org<=
/a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">O=
n 2022-10-07 06:20, Dario Sneidermanis via bitcoin-dev wrote:<br>
&gt; Hello list,<br>
&gt; <br>
&gt; I&#39;m Dario, from Muun wallet [...] we&#39;ve been reviewing the lat=
est <br>
&gt; bitcoin core release<br>
&gt; candidate [...] we understood we had at least a year from the initial<=
br>
&gt; opt-in=C2=A0 deployment until opt-out was deployed, giving us enough t=
ime to <br>
&gt; adapt<br>
&gt; Muun to the new policies. However, when reviewing the 24.0 release <br=
>
&gt; candidate<br>
&gt; just a few=C2=A0 days ago, we realized that zero-conf apps (like Muun)=
 must<br>
&gt; *immediately turn off* their zero-conf features.<br>
<br>
Hi Dario,<br>
<br>
I&#39;m wondering if there&#39;s been some confusion.=C2=A0 There are two R=
BF-related <br>
items in the current release notes draft:[1]<br>
<br>
1. &quot;A new mempoolfullrbf option has been added, which enables the <br>
mempool to accept transaction replacement without enforcing BIP125 <br>
replaceability signaling. (#25353)&quot;<br>
<br>
2. &quot;The -walletrbf startup option will now default to true. The wallet=
 <br>
will now default to opt-in RBF on transactions that it creates. <br>
(#25610)&quot;<br>
<br>
The first item (from PR #25353) does allow a transaction without a <br>
BIP125 signal to be replaced, but this configuration option is set to <br>
disabled by default.[2]=C2=A0 There have been software forks of Bitcoin Cor=
e <br>
since at least 2015 which have allowed replacement of non-signaling <br>
transactions, so this option just makes that behavior a little bit more <br=
>
accessible to users of Bitcoin Core.</blockquote><div><br></div>The &quot;a=
ctivation&quot; of full-RBF after deployment works in a pretty interesting =
way:<br><br>1. If no miner is running full-RBF or there aren&#39;t easily a=
ccessible connected<br>=C2=A0 =C2=A0components of nodes running full-RBF co=
nnected to the miners, then full-RBF<br>=C2=A0 =C2=A0is mostly ineffective =
since replacements aren&#39;t relayed and/or mined.<br>2. There&#39;s a mid=
dle ground where *some* connected components of full-RBF nodes<br>=C2=A0 =
=C2=A0can relay and mine replacements, where some full-RBF nodes will be ab=
le to<br>=C2=A0 =C2=A0replace via full-RBF and some won&#39;t (depending on=
 their peers).<br>3. With high enough adoption, the relay graph has enough =
density of full-RBF<br>=C2=A0 =C2=A0nodes that almost all full-RBF nodes ca=
n replace transactions via full-RBF.<br><br>While there have been forks of =
Bitcoin Core (like Bitcoin Knots) running<br>full-RBF for a while, today mo=
st nodes (by far) are running Bitcoin Core. So,<br>Bitcoin Core adding an o=
pt-in flag (ie. off by default) makes it easier to be<br>picked up by most =
node operators. Making the flag opt-out (ie. on by default)<br>would make i=
t easier still. We are dealing with a gradient going from hard<br>enough th=
at we are still in 1, to easy enough that we get to 3.<br><br>The question =
then is whether an opt-in flag for full-RBF will have enough<br>adoption to=
 get us from 1 to 2. If it isn&#39;t, then #25353 won&#39;t meet its<br>obj=
ective of allowing nodes participating in multi-party funding protocols to<=
br>assume that they can rely on full-RBF. If it is, then zero-conf applicat=
ions<br><div>will be at severe risk (per the logic in the initial email).</=
div><div><br></div></div></div>

--0000000000001b825305ea789f0f--