diff options
| author | Dario Sneidermanis <dario@muun.com> | 2022-10-20 13:51:24 -0300 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-10-20 16:51:39 +0000 |
| commit | d3c0744a33782be23bd806dd59b2ad7b3b138a9b (patch) | |
| tree | 8dafcbfdd956bee17fb03508c81a74836ce9ea43 /fc | |
| parent | c58705f76cf4cbb9201ae9d310dd6bd19891d683 (diff) | |
| download | pi-bitcoindev-d3c0744a33782be23bd806dd59b2ad7b3b138a9b.tar.gz pi-bitcoindev-d3c0744a33782be23bd806dd59b2ad7b3b138a9b.zip | |
[bitcoin-dev] Analysis of full-RBF deployment methods
Diffstat (limited to 'fc')
| -rw-r--r-- | fc/b132d010e8ba37b8f6d6125916114a50c09450 | 364 |
1 files changed, 364 insertions, 0 deletions
diff --git a/fc/b132d010e8ba37b8f6d6125916114a50c09450 b/fc/b132d010e8ba37b8f6d6125916114a50c09450 new file mode 100644 index 000000000..857dbbac6 --- /dev/null +++ b/fc/b132d010e8ba37b8f6d6125916114a50c09450 @@ -0,0 +1,364 @@ +Return-Path: <dario@muun.com> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 5A8A8C002D + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 20 Oct 2022 16:51:39 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp3.osuosl.org (Postfix) with ESMTP id 3B7A260C02 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 20 Oct 2022 16:51:39 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 3B7A260C02 +Authentication-Results: smtp3.osuosl.org; + dkim=pass (2048-bit key) header.d=muun-com.20210112.gappssmtp.com + header.i=@muun-com.20210112.gappssmtp.com header.a=rsa-sha256 + header.s=20210112 header.b=v2olytMb +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -1.899 +X-Spam-Level: +X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, + SPF_PASS=-0.001] autolearn=ham autolearn_force=no +Received: from smtp3.osuosl.org ([127.0.0.1]) + by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id W8QeEdghLdYg + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 20 Oct 2022 16:51:37 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 7968760BDF +Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com + [IPv6:2a00:1450:4864:20::334]) + by smtp3.osuosl.org (Postfix) with ESMTPS id 7968760BDF + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 20 Oct 2022 16:51:37 +0000 (UTC) +Received: by mail-wm1-x334.google.com with SMTP id + m29-20020a05600c3b1d00b003c6bf423c71so2901842wms.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 20 Oct 2022 09:51:37 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=muun-com.20210112.gappssmtp.com; s=20210112; + h=to:subject:message-id:date:from:mime-version:from:to:cc:subject + :date:message-id:reply-to; + bh=yV59/6ilX9cIWt708ycAxh9MBjkNbiRH3FTR8TWmC9U=; + b=v2olytMbbaZLhgoUxYoouPs7FWxg3RZKSD/s60e/nyITB8z2d4n+re1VY7o9/AuZXe + CkzIIXNLP6Ot+xpRSO1tOYYjo4oOxrvYiQe6YKEqOomNru5ucAtIz+k7ScWE8fF/jc/t + Y+HcuRMiZF/PHZb0PukQvii/rUUQlFXbEvqgA+p5sPLuZwkGO2AP24Lpx0AyPsKJi5hB + FwPh69G1xDNXytoMBqYbSmh1fbdO+HuPiYcefz2Z3VD67rV9HgnMtIEwju24Q2NmQ5Zc + Ds4dmnLRs/baOwmYA42kFmtimyP6p3W8kVCA8xdPxFjkaI6GNOJobJGqyU0/sfEkTxKX + lyew== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20210112; + h=to:subject:message-id:date:from:mime-version:x-gm-message-state + :from:to:cc:subject:date:message-id:reply-to; + bh=yV59/6ilX9cIWt708ycAxh9MBjkNbiRH3FTR8TWmC9U=; + b=c3PqHkGwwTnX79jb9mcY+55qEFCpb5j7POp8CZEZt5sictLcalwKwpFK+CLTK6N0Ne + beLWNqOAaKAUFbiyJXWaFsQXLNggBa5gPvJNimh1c+RGJhuMuCUBdpiTGwF9H7DGZyo2 + /hmeEg1pPL/2FLmOrStV/nwO8i+pmy7h9K67D0zw+Q3uAJLDeGFXKwlABR1v7wADbbV3 + kc4C44oOIhy37yQvKhSgnnFr3Puf01oPddxNW51XN48v6UP7GGagEH/bfNgnLdlbfBeb + 34II25AQ7cj9YzwB83S61mFESu7xJ1p1AXb9RbeEA5UbU6r+/nlfOvrfGTIe+ICBQ4rq + +qNA== +X-Gm-Message-State: ACrzQf0HkAOAAoA/ea48nMA5pfRs2B363LoSAbppFyZrUHhZwOQ/xm3t + nRT3Q9k+cay2ZduUEpt3JcycRNbqSLu9LFDLKAtBHkX48XRzYw== +X-Google-Smtp-Source: AMsMyM4K8IBsbqhkzpgJWMi6xnBhFto53iByraEkSMD79n/a5OnGgJyESrorLxz9XkLqTPQZGXbQ1I6+5M1O+4v/XMs= +X-Received: by 2002:a05:600c:3592:b0:3c6:f9db:a954 with SMTP id + p18-20020a05600c359200b003c6f9dba954mr10050496wmq.170.1666284695132; Thu, 20 + Oct 2022 09:51:35 -0700 (PDT) +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" +X-Mailman-Approved-At: Thu, 20 Oct 2022 16:56:24 +0000 +Subject: [bitcoin-dev] Analysis of full-RBF deployment methods +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Thu, 20 Oct 2022 16:51:39 -0000 + +--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'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's PR #26287: revert opt-in full-RBF in 24.0, and give more time = +to<br>=C2=A0 =C2=A0figure out what's next.<br>3. Marco's PR #26287 = ++ Antoine'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's PR #26287 + Anthony= +'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'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'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 "we'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's a deployment mechanism that, as far= + as I<br>=C2=A0 =C2=A0 know, hasn'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'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'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'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's PR #26287] <a href=3D= +"https://github.com/bitcoin/bitcoin/pull/26287">https://github.com/bitcoin/= +bitcoin/pull/26287</a><br>[Antoine's PR #26305] <a href=3D"https://gith= +ub.com/bitcoin/bitcoin/pull/26305">https://github.com/bitcoin/bitcoin/pull/= +26305</a><br>[Anthony'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-- + |