MIME-Version: 1.0
From: Dario Sneidermanis <dario@muun.com>
Date: Thu, 20 Oct 2022 13:51:24 -0300
Message-ID: <CAKiPDnSsKPhL9-0pJBNav6SYJ45qiuxB6X-NMa1i65vHrxK2bA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000005933c205eb7a23ab"
Subject: [bitcoin-dev] Analysis of full-RBF deployment methods
Precedence: list

--0000000000005933c205eb7a23ab
Content-Type: text/plain; charset="UTF-8"

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

--0000000000005933c205eb7a23ab
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello list,<br><br>Given that the release of 24.0 is upon =
us and there is little time to make a<br>complex decision regarding the dep=
loyment method of full-RBF, we&#39;ve documented<br>the different alternati=
ves and their trade-offs. I hope this helps get to the<br>best possible dep=
loyment!<br><br>Gist: <a href=3D"https://gist.github.com/esneider/4eb16fcd9=
59cb8c6b657c314442801ee">https://gist.github.com/esneider/4eb16fcd959cb8c6b=
657c314442801ee</a><br><br># Current deployment options<br><br>1. Antoine&#=
39;s PR #26305: leave 24.0 as is, and merge opt-out in 25.0 or later.<br>2.=
 Marco&#39;s PR #26287: revert opt-in full-RBF in 24.0, and give more time =
to<br>=C2=A0 =C2=A0figure out what&#39;s next.<br>3. Marco&#39;s PR #26287 =
+ Antoine&#39;s PR #26305: revert opt-in full-RBF in 24.0, and<br>=C2=A0 =
=C2=A0merge opt-out in 25.0 or later.<br>4. Marco&#39;s PR #26287 + Anthony=
&#39;s PR #26323 (just the date commitment): revert<br>=C2=A0 =C2=A0opt-in =
full-RBF in 24.0, and commit in 25.0 or later to a later date for<br>=C2=A0=
 =C2=A0opt-out activation.<br>5. Anthony&#39;s PR #26323: revert opt-in ful=
l-RBF in 24.0, and commit in 24.0 to a<br>=C2=A0 =C2=A0later date for opt-o=
ut activation.<br><br>Notice that once full-RBF is fully deployed, having a=
 config option to disable<br>it is mostly a foot gun: you will only hurt yo=
urself by missing some<br>transactions. Maybe options 4 and 5 could remove =
the flag altogether instead of<br>making it opt-out.<br><br>There are a few=
 more options, but I don&#39;t think they would reasonably have any<br>cons=
ensus, so I trimmed them down to make it easier to process.<br><br><br># Di=
mensions of analysis<br><br>1. Zero-conf apps immediately affected<br><br>=
=C2=A0 =C2=A0 If we leave the flag for full-rbf in 24.0, zero-conf apps cou=
ld be<br>=C2=A0 =C2=A0 immediately affected. More specifically, as Anthony =
explained much more<br>=C2=A0 =C2=A0 clearly [0], they would be in danger a=
s soon as a relatively big mining<br>=C2=A0 =C2=A0 pool operator enables th=
e full-RBF flag.<br><br>=C2=A0 =C2=A0 It turns out that the class of apps t=
hat could be immediately affected (ie.<br>=C2=A0 =C2=A0 apps that were dire=
ctly or indirectly relying on the first-seen policy in an<br>=C2=A0 =C2=A0 =
adversarial setting) is larger than zero-conf apps, as exposed by Sergej<br=
>=C2=A0 =C2=A0 [1]. Namely, the apps committing to an exchange rate before =
on-chain funds<br>=C2=A0 =C2=A0 are sent/finalized would start offering a f=
ree(ish) american call option.<br><br>2. Predictable deployment date<br><br=
>=C2=A0 =C2=A0 Committing to an activation date for full-rbf on the social =
layer (eg.<br>=C2=A0 =C2=A0 &quot;we&#39;ll merge the opt-out flag in 25.0&=
quot;) has the benefit of being flexible in<br>=C2=A0 =C2=A0 the event of n=
ew data points but becomes less predictable (both for<br>=C2=A0 =C2=A0 appl=
ications and for full-rbf proponents).<br><br>=C2=A0 =C2=A0 Committing to a=
n activation date for full-rbf on the code has the benefit<br>=C2=A0 =C2=A0=
 that once node operators start deploying the code, the date is set in ston=
e,<br>=C2=A0 =C2=A0 and we can reason about when full-RBF will be fully dep=
loyed and usable.<br><br>3. Code complexity<br><br>=C2=A0 =C2=A0 Handling t=
he commitment to a date in the code introduces further code<br>=C2=A0 =C2=
=A0 complexity. In particular, it&#39;s a deployment mechanism that, as far=
 as I<br>=C2=A0 =C2=A0 know, hasn&#39;t been tried before, so we should be =
careful.<br><br>4. Smooth deployment<br><br>=C2=A0 =C2=A0 Full-RBF deployme=
nt has two distinct phases when analyzing the adoption in<br>=C2=A0 =C2=A0 =
the transaction relaying layer. First, there will be multiple disjoint<br>=
=C2=A0 =C2=A0 connected components of full-RBF nodes. Eventually, we&#39;ll=
 get to a<br>=C2=A0 =C2=A0 single(ish) connected component of full-RBF node=
s.<br><br>=C2=A0 =C2=A0 The first deployment phase is a bit chaotic and dif=
ficult to reason about:<br>=C2=A0 =C2=A0 nobody can rely on full-RBF actual=
ly working; if it coincides with a<br>=C2=A0 =C2=A0 high-fees scenario, we&=
#39;ll get a big mempool divergence event, causing many<br>=C2=A0 =C2=A0 ot=
her issues and unreliability in the relaying and application layers.<br><br=
>=C2=A0 =C2=A0 I&#39;m calling smooth deployment to a deployment that minim=
izes the first<br>=C2=A0 =C2=A0 phase, eg. by activating full-RBF simultane=
ously in as many<br>=C2=A0 =C2=A0 transaction-relaying nodes as possible.<b=
r><br>5. Time to figure out the right deployment<br><br>=C2=A0 =C2=A0 Figur=
ing out the right deployment method and timeline to activate full-rbf<br>=
=C2=A0 =C2=A0 might be more time-consuming than what we are willing to wait=
 for the stable<br>=C2=A0 =C2=A0 release of 24.0. Decoupling the protection=
 to zero-conf apps from choosing a<br>=C2=A0 =C2=A0 deployment method and a=
n activation date for opt-out might be a good idea.<br><br>I&#39;m probably=
 forgetting some dimensions here, but it may be enough to grasp the<br>trad=
e-offs between the different approaches.<br><br><br># Comparison<br><br>Gis=
t: <a href=3D"https://gist.github.com/esneider/4eb16fcd959cb8c6b657c3144428=
01ee#comparison">https://gist.github.com/esneider/4eb16fcd959cb8c6b657c3144=
42801ee#comparison</a><br><br># Timeline for full-RBF activation<br><br>If =
we make some UX trade-offs, Muun can be production ready with the required<=
br>changes in 6 months. Having more time to avoid those trade-offs would be=
<br>preferable, but we can manage.<br><br>The larger application ecosystem =
may need a bit more time since they might not<br>have the advantage of havi=
ng been working on the required changes for a while<br>already. Ideally, th=
ere should be enough time to reach out to affected<br>applications and let =
them make time to understand the impact, design solutions,<br>implement the=
m, and deploy them.<br><br>Finally, if a smooth deployment (as previously d=
efined) is desired, we can lock<br>an activation date in the code and give =
relaying nodes enough time to upgrade<br>before activation. Assuming that t=
he adoption of future releases remains similar<br>to previous ones [2], one=
 release cycle should get us to 22% adoption, two<br>release cycles to 61% =
adoption, and three release cycles to 79% adoption.<br>Assuming a uniform a=
doption distribution, the probability of an 8-connection<br>relaying node n=
ot being connected to any full-RBF node after one release cycle<br>will be =
0.14. After two cycles, it will be 0.00054, and after three cycles, it<br>w=
ill be 0.0000038. Looking at these numbers, it would seem that a single rel=
ease<br>cycle will be too little time, but two release cycles may be enough=
.<br><br>Cheers,<br>Dario<br><br><br>[0] <a href=3D"https://lists.linuxfoun=
dation.org/pipermail/bitcoin-dev/2022-October/021031.html">https://lists.li=
nuxfoundation.org/pipermail/bitcoin-dev/2022-October/021031.html</a><br>[1]=
 <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Oc=
tober/021056.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/=
2022-October/021056.html</a><br>[2] <a href=3D"https://luke.dashjr.org/prog=
rams/bitcoin/files/charts/software.html">https://luke.dashjr.org/programs/b=
itcoin/files/charts/software.html</a><br>[Marco&#39;s PR #26287] <a href=3D=
"https://github.com/bitcoin/bitcoin/pull/26287">https://github.com/bitcoin/=
bitcoin/pull/26287</a><br>[Antoine&#39;s PR #26305] <a href=3D"https://gith=
ub.com/bitcoin/bitcoin/pull/26305">https://github.com/bitcoin/bitcoin/pull/=
26305</a><br>[Anthony&#39;s PR #26323] <a href=3D"https://github.com/bitcoi=
n/bitcoin/pull/26323">https://github.com/bitcoin/bitcoin/pull/26323</a><br>=
</div>

--0000000000005933c205eb7a23ab--