MIME-Version: 1.0
References: <CAKiPDnSsKPhL9-0pJBNav6SYJ45qiuxB6X-NMa1i65vHrxK2bA@mail.gmail.com>
In-Reply-To: <CAKiPDnSsKPhL9-0pJBNav6SYJ45qiuxB6X-NMa1i65vHrxK2bA@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Thu, 20 Oct 2022 21:50:30 -0400
Message-ID: <CALZpt+FPWSFbr6r-5J0YO1o3SvMQC4Gyj-QWTJ4yA3ZbJtOUxQ@mail.gmail.com>
To: Dario Sneidermanis <dario@muun.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000005b487d05eb81abf6"
Subject: Re: [bitcoin-dev] Analysis of full-RBF deployment methods
Precedence: list

--0000000000005b487d05eb81abf6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Dario,

Thanks for this analysis of full-RBF deployment methods!

The subject was widely discussed at today Bitcoin Core IRC meetings:
https://gnusha.org/bitcoin-core-dev/2022-10-20.log

Personally, I still think deferring full-rbf deployment, while it sounds
reasonable to let existing services and applications adapt their software
and business models, doesn't come risk-free for the contracting protocols
and multi-party applications affected by the pinning DoS vector. Deferring
ad vitam aeternam left them exposed to disruptions when their traffic
volume would start to be significant. While those use-cases
(splicing/dual-channels/collaborative constructions) were mostly vaporware
a year ago when I raised the issue, it turns out they have become a far
more tangible reality today. Beyond the 3 coinjoins services
(Wasabi/Joinmarket/Whirlpool), we have new things like ln-vortex, or
Phoenix wallet and some LDK users planning to use dual-funded soon.

I'm fully aware we still have community stakeholders opposing full-rbf on
principle, I think this is highly valuable to exchange more perspectives on
the subject, hopefully to harmonize understandings, and work altogether on
creative solutions to accommodate as many use-cases as we can, in a
compatible way.

I don't know what the best full-rbf deployment method is, though one
offering clear visibility and predictability to node operators, with a flag
day activation like #26323 sounds like a reasonable one. As you said, I
believe 6 months from now is far too short, maybe something like 12 months
or 16 months (or more ?) is adequate. At least I fully rejoin on the risk
of merchants centralization if we favor a timeline only favoring entities
with sufficient manpower.

I'm still looking forward to having more forums and communication channels
between business/services operators and protocol developers, it sounds like
functional responsibilities between protocol and application layers could
be better clarified. However, I don't know if it should be the
responsibility of developers to solve every operational risk encumbered by
a Bitcoin business, like FX risk. I don't deny the interdependency between
network policy rules and business risk, I'm just saying Bitcoin protocol
developers have already heavily loaded engineering priorities between
solving the half of dozen of Lightning vulnerabilities, working on the next
consensus changes or reviewing modularity refactoring of Bitcoin Core to
extend the feature set in a soft way (among tons of other examples).

All speaking for myself, looking forward to having more perspective
expressed!

Best,
Antoine

Le jeu. 20 oct. 2022 =C3=A0 12:56, Dario Sneidermanis via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :

> Hello list,
>
> Given that the release of 24.0 is upon us and there is little time to mak=
e
> 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 f=
or
>    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 hav=
e
> 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 mo=
re
>     clearly [0], they would be in danger as soon as a relatively big mini=
ng
>     pool operator enables the full-RBF flag.
>
>     It turns out that the class of apps that could be immediately affecte=
d
> (ie.
>     apps that were directly or indirectly relying on the first-seen polic=
y
> 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 a=
s
> 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 disjoin=
t
>     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 firs=
t
>     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#compari=
son
>
> # 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 migh=
t
> 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 ca=
n
> 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, tw=
o
> 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/0210=
31.html
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/0210=
56.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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Hi Dario,<br><br>Thanks for this analysis of full-RBF depl=
oyment methods!<br><br>The subject was widely discussed at today Bitcoin Co=
re IRC meetings:<br><a href=3D"https://gnusha.org/bitcoin-core-dev/2022-10-=
20.log">https://gnusha.org/bitcoin-core-dev/2022-10-20.log</a><br><br>Perso=
nally, I still think deferring full-rbf deployment, while it sounds reasona=
ble to let existing services and applications adapt their software and busi=
ness models, doesn&#39;t come risk-free for the contracting protocols and m=
ulti-party applications affected by the pinning DoS vector. Deferring ad vi=
tam aeternam left them exposed to disruptions when their traffic volume wou=
ld start to be significant. While those use-cases (splicing/dual-channels/c=
ollaborative constructions) were mostly vaporware a year ago when I raised =
the issue, it turns out they have become a far more tangible reality today.=
 Beyond the 3 coinjoins services (Wasabi/Joinmarket/Whirlpool), we have new=
 things like ln-vortex, or Phoenix wallet and some LDK users planning to us=
e dual-funded soon.<br><br>I&#39;m fully aware we still have community stak=
eholders opposing full-rbf on principle, I think this is highly valuable to=
 exchange more perspectives on the subject, hopefully to harmonize understa=
ndings, and work altogether on creative solutions to accommodate as many us=
e-cases as we can, in a compatible way.<br><br>I don&#39;t know what the be=
st full-rbf deployment method is, though one offering clear visibility and =
predictability to node operators, with a flag day activation like #26323 so=
unds like a reasonable one. As you said, I believe 6 months from now is far=
 too short, maybe something like 12 months or 16 months (or more ?) is adeq=
uate. At least I fully rejoin on the risk of merchants centralization if we=
 favor a timeline only favoring entities with sufficient manpower.<br><br>I=
&#39;m still looking forward to having more forums and communication channe=
ls between business/services operators and protocol developers, it sounds l=
ike functional responsibilities between protocol and application layers cou=
ld be better clarified. However, I don&#39;t know if it should be the respo=
nsibility of developers to solve every operational risk encumbered by a Bit=
coin business, like FX risk. I don&#39;t deny the interdependency between n=
etwork policy rules and business risk, I&#39;m just saying Bitcoin protocol=
 developers have already heavily loaded engineering priorities between solv=
ing the half of dozen of Lightning vulnerabilities, working on the next con=
sensus changes or reviewing modularity refactoring of Bitcoin Core to exten=
d the feature set in a soft way (among tons of other examples).<br><br>All =
speaking for myself, looking forward to having more perspective expressed!<=
br><br>Best,<br>Antoine<br></div><br><div class=3D"gmail_quote"><div dir=3D=
"ltr" class=3D"gmail_attr">Le=C2=A0jeu. 20 oct. 2022 =C3=A0=C2=A012:56, Dar=
io Sneidermanis via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.lin=
uxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; a =C3=A9cri=
t=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div di=
r=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 deployment=
 method of full-RBF, we&#39;ve documented<br>the different alternatives and=
 their trade-offs. I hope this helps get to the<br>best possible deployment=
!<br><br>Gist: <a href=3D"https://gist.github.com/esneider/4eb16fcd959cb8c6=
b657c314442801ee" target=3D"_blank">https://gist.github.com/esneider/4eb16f=
cd959cb8c6b657c314442801ee</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 l=
ater.<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<b=
r>=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 full-RBF in 24.0, and commit in 24.0 to a<br>=C2=A0 =C2=A0later date=
 for opt-out 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 on=
ly hurt yourself by missing some<br>transactions. Maybe options 4 and 5 cou=
ld 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 a=
ny<br>consensus, so I trimmed them down to make it easier to process.<br><b=
r><br># Dimensions of analysis<br><br>1. Zero-conf apps immediately affecte=
d<br><br>=C2=A0 =C2=A0 If we leave the flag for full-rbf in 24.0, zero-conf=
 apps could 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 as soon as a relatively big mining<br>=C2=A0 =C2=A0 pool operator e=
nables the full-RBF flag.<br><br>=C2=A0 =C2=A0 It turns out that the class =
of apps that could be immediately affected (ie.<br>=C2=A0 =C2=A0 apps that =
were directly 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 b=
y Sergej<br>=C2=A0 =C2=A0 [1]. Namely, the apps committing to an exchange r=
ate before on-chain funds<br>=C2=A0 =C2=A0 are sent/finalized would start o=
ffering a free(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 fl=
ag in 25.0&quot;) has the benefit of being flexible in<br>=C2=A0 =C2=A0 the=
 event of new data points but becomes less predictable (both for<br>=C2=A0 =
=C2=A0 applications and for full-rbf proponents).<br><br>=C2=A0 =C2=A0 Comm=
itting to an 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 i=
s set in stone,<br>=C2=A0 =C2=A0 and we can reason about when full-RBF will=
 be fully deployed and usable.<br><br>3. Code complexity<br><br>=C2=A0 =C2=
=A0 Handling the commitment to a date in the code introduces further code<b=
r>=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 w=
e should be careful.<br><br>4. Smooth deployment<br><br>=C2=A0 =C2=A0 Full-=
RBF deployment 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. Eventual=
ly, we&#39;ll get to a<br>=C2=A0 =C2=A0 single(ish) connected component of =
full-RBF nodes.<br><br>=C2=A0 =C2=A0 The first deployment phase is a bit ch=
aotic and difficult to reason about:<br>=C2=A0 =C2=A0 nobody can rely on fu=
ll-RBF actually 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 other issues and unreliability in the relaying and application l=
ayers.<br><br>=C2=A0 =C2=A0 I&#39;m calling smooth deployment to a deployme=
nt that minimizes the first<br>=C2=A0 =C2=A0 phase, eg. by activating full-=
RBF simultaneously in as many<br>=C2=A0 =C2=A0 transaction-relaying nodes a=
s possible.<br><br>5. Time to figure out the right deployment<br><br>=C2=A0=
 =C2=A0 Figuring out the right deployment method and timeline to activate f=
ull-rbf<br>=C2=A0 =C2=A0 might be more time-consuming than what we are will=
ing 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 m=
ethod and an 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>trade-offs between the different approaches.<br><br><br># Comparison=
<br><br>Gist: <a href=3D"https://gist.github.com/esneider/4eb16fcd959cb8c6b=
657c314442801ee#comparison" target=3D"_blank">https://gist.github.com/esnei=
der/4eb16fcd959cb8c6b657c314442801ee#comparison</a><br><br># Timeline for f=
ull-RBF activation<br><br>If we make some UX trade-offs, Muun can be produc=
tion ready with the required<br>changes in 6 months. Having more time to av=
oid 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 having been working on the required changes for a =
while<br>already. Ideally, there should be enough time to reach out to affe=
cted<br>applications and let them make time to understand the impact, desig=
n solutions,<br>implement them, and deploy them.<br><br>Finally, if a smoot=
h deployment (as previously defined) is desired, we can lock<br>an activati=
on date in the code and give relaying nodes enough time to upgrade<br>befor=
e activation. Assuming that the 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% adop=
tion.<br>Assuming a uniform adoption distribution, the probability of an 8-=
connection<br>relaying node not being connected to any full-RBF node after =
one release cycle<br>will be 0.14. After two cycles, it will be 0.00054, an=
d after three cycles, it<br>will be 0.0000038. Looking at these numbers, it=
 would seem that a single release<br>cycle will be too little time, but two=
 release cycles may be enough.<br><br>Cheers,<br>Dario<br><br><br>[0] <a hr=
ef=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/=
021031.html" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/=
bitcoin-dev/2022-October/021031.html</a><br>[1] <a href=3D"https://lists.li=
nuxfoundation.org/pipermail/bitcoin-dev/2022-October/021056.html" target=3D=
"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Octob=
er/021056.html</a><br>[2] <a href=3D"https://luke.dashjr.org/programs/bitco=
in/files/charts/software.html" target=3D"_blank">https://luke.dashjr.org/pr=
ograms/bitcoin/files/charts/software.html</a><br>[Marco&#39;s PR #26287] <a=
 href=3D"https://github.com/bitcoin/bitcoin/pull/26287" target=3D"_blank">h=
ttps://github.com/bitcoin/bitcoin/pull/26287</a><br>[Antoine&#39;s PR #2630=
5] <a href=3D"https://github.com/bitcoin/bitcoin/pull/26305" target=3D"_bla=
nk">https://github.com/bitcoin/bitcoin/pull/26305</a><br>[Anthony&#39;s PR =
#26323] <a href=3D"https://github.com/bitcoin/bitcoin/pull/26323" target=3D=
"_blank">https://github.com/bitcoin/bitcoin/pull/26323</a><br></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000005b487d05eb81abf6--