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