Dario Sneidermanis [ARCHIVE] on Nostr: 📅 Original date posted:2022-10-20 📝 Original message:Hello list, Given that the ...

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