Dario Sneidermanis [ARCHIVE] on Nostr: 📅 Original date posted:2022-10-07 📝 Original message:Hello David, Thanks for ...

📅 Original date posted:2022-10-07
📝 Original message: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 at 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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221007/a17e3454/attachment.html>;