Hello list,

Given that the release of 24.0 is upon us and there is little time to make a
complex decision regarding the deployment method of full-RBF, we've
documented
the different alternatives and their trade-offs. I hope this helps get to
the
best possible deployment!

Gist: https://gist.github.com/esneider/4eb16fcd959cb8c6b657c314442801ee

# Current deployment options

1. Antoine's PR #26305: leave 24.0 as is, and merge opt-out in 25.0 or
later.
2. Marco's PR #26287: revert opt-in full-RBF in 24.0, and give more time to
   figure out what's next.
3. Marco's PR #26287 + Antoine's PR #26305: revert opt-in full-RBF in 24.0,
and
   merge opt-out in 25.0 or later.
4. Marco's PR #26287 + Anthony's PR #26323 (just the date commitment):
revert
   opt-in full-RBF in 24.0, and commit in 25.0 or later to a later date for
   opt-out activation.
5. Anthony's PR #26323: revert opt-in full-RBF in 24.0, and commit in 24.0
to a
   later date for opt-out activation.

Notice that once full-RBF is fully deployed, having a config option to
disable
it is mostly a foot gun: you will only hurt yourself by missing some
transactions. Maybe options 4 and 5 could remove the flag altogether
instead of
making it opt-out.

There are a few more options, but I don't think they would reasonably have
any
consensus, so I trimmed them down to make it easier to process.


# Dimensions of analysis

1. Zero-conf apps immediately affected

    If we leave the flag for full-rbf in 24.0, zero-conf apps could be
    immediately affected. More specifically, as Anthony explained much more
    clearly [0], they would be in danger as soon as a relatively big mining
    pool operator enables the full-RBF flag.

    It turns out that the class of apps that could be immediately affected
(ie.
    apps that were directly or indirectly relying on the first-seen policy
in an
    adversarial setting) is larger than zero-conf apps, as exposed by Sergej
    [1]. Namely, the apps committing to an exchange rate before on-chain
funds
    are sent/finalized would start offering a free(ish) american call
option.

2. Predictable deployment date

    Committing to an activation date for full-rbf on the social layer (eg.
    "we'll merge the opt-out flag in 25.0") has the benefit of being
flexible in
    the event of new data points but becomes less predictable (both for
    applications and for full-rbf proponents).

    Committing to an activation date for full-rbf on the code has the
benefit
    that once node operators start deploying the code, the date is set in
stone,
    and we can reason about when full-RBF will be fully deployed and usable.

3. Code complexity

    Handling the commitment to a date in the code introduces further code
    complexity. In particular, it's a deployment mechanism that, as far as I
    know, hasn't been tried before, so we should be careful.

4. Smooth deployment

    Full-RBF deployment has two distinct phases when analyzing the adoption
in
    the transaction relaying layer. First, there will be multiple disjoint
    connected components of full-RBF nodes. Eventually, we'll get to a
    single(ish) connected component of full-RBF nodes.

    The first deployment phase is a bit chaotic and difficult to reason
about:
    nobody can rely on full-RBF actually working; if it coincides with a
    high-fees scenario, we'll get a big mempool divergence event, causing
many
    other issues and unreliability in the relaying and application layers.

    I'm calling smooth deployment to a deployment that minimizes the first
    phase, eg. by activating full-RBF simultaneously in as many
    transaction-relaying nodes as possible.

5. Time to figure out the right deployment

    Figuring out the right deployment method and timeline to activate
full-rbf
    might be more time-consuming than what we are willing to wait for the
stable
    release of 24.0. Decoupling the protection to zero-conf apps from
choosing a
    deployment method and an activation date for opt-out might be a good
idea.

I'm probably forgetting some dimensions here, but it may be enough to grasp
the
trade-offs between the different approaches.


# Comparison

Gist:
https://gist.github.com/esneider/4eb16fcd959cb8c6b657c314442801ee#comparison

# Timeline for full-RBF activation

If we make some UX trade-offs, Muun can be production ready with the
required
changes in 6 months. Having more time to avoid those trade-offs would be
preferable, but we can manage.

The larger application ecosystem may need a bit more time since they might
not
have the advantage of having been working on the required changes for a
while
already. Ideally, there should be enough time to reach out to affected
applications and let them make time to understand the impact, design
solutions,
implement them, and deploy them.

Finally, if a smooth deployment (as previously defined) is desired, we can
lock
an activation date in the code and give relaying nodes enough time to
upgrade
before activation. Assuming that the adoption of future releases remains
similar
to previous ones [2], one release cycle should get us to 22% adoption, two
release cycles to 61% adoption, and three release cycles to 79% adoption.
Assuming a uniform adoption distribution, the probability of an 8-connection
relaying node not being connected to any full-RBF node after one release
cycle
will be 0.14. After two cycles, it will be 0.00054, and after three cycles,
it
will be 0.0000038. Looking at these numbers, it would seem that a single
release
cycle will be too little time, but two release cycles may be enough.

Cheers,
Dario


[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021031.html
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021056.html
[2] https://luke.dashjr.org/programs/bitcoin/files/charts/software.html
[Marco's PR #26287] https://github.com/bitcoin/bitcoin/pull/26287
[Antoine's PR #26305] https://github.com/bitcoin/bitcoin/pull/26305
[Anthony's PR #26323] https://github.com/bitcoin/bitcoin/pull/26323