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