summaryrefslogtreecommitdiff
path: root/fc/b132d010e8ba37b8f6d6125916114a50c09450
blob: 857dbbac62c1be648386d649a36e0dd4959fcbcb (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
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&#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--