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
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
|
Delivery-date: Tue, 23 Jul 2024 17:44:05 -0700
Received: from mail-yb1-f190.google.com ([209.85.219.190])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBC3PT7FYWAMRBTM4QG2QMGQEYYEBOPA@googlegroups.com>)
id 1sWQ6u-0004qZ-OU
for bitcoindev@gnusha.org; Tue, 23 Jul 2024 17:44:05 -0700
Received: by mail-yb1-f190.google.com with SMTP id 3f1490d57ef6-e05ec8921fdsf12747297276.1
for <bitcoindev@gnusha.org>; Tue, 23 Jul 2024 17:44:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1721781839; x=1722386639; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:sender:from
:to:cc:subject:date:message-id:reply-to;
bh=cxK+8Yz420krABR27or65yBKv0vpAEQVTNSHOeC6DC4=;
b=E5I6+6+2LM2f12xgpBQ1N5LbFwtTQMancXQnIvGWk/RZs2HgDj5fdQk7ouKHFwwOdq
XXaKEUhU8qzOrN3vzUbBjmP4C9KQYRwz2joYS2OeffYMTBdV/z3bSWlkWy7/HuZuAqE3
37tOS2PGAa1upk7qzCY1Gcf/Twu1wRgYoqpHjOoCebIz+0tBQWUnJ2ymg2yis3UVhLEW
e91kWmBO/bZEkNv4EpU/DR9ZNtHAcCC4ByjTrfv2ulh+lCTkHoEeD2ESnTWl6qfCEM8e
2O8i6FuP4JDpZ2gI65PYUlyTfkbZKvbsMp6WfuakvOZh7GIIhQsJILzciEV6tSoWJ4if
9cVg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1721781839; x=1722386639; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:from:to:cc
:subject:date:message-id:reply-to;
bh=cxK+8Yz420krABR27or65yBKv0vpAEQVTNSHOeC6DC4=;
b=XZe31S4rd1f6kkJlm8qRJZIHQ6j5xtdUYnOluE5USBD+b7caVPV4TdvaBMhvSpm7li
C6e741ylZZJwf9VGjtc9MHqbnEBZTm4MWDt7VAqJ2uQr6EPM6NMf5MLIzW9HJQsMYm2E
reggSFMyQOyayAXdo6NSe7WXozpTeycgUsOEbwVLn7xivAxpa4rBL+/r0+ofJwuHLRFt
oZrou0bIeWN2HZecB9MeVk41O2g4lqJPExSyoRQk2Ax0MesbUCYEKpNXSMIayaO404ve
jSa3MMg7rnoV3DHIH4FBhpvZI8KcR/nFVqlxih4kd1MTgwvXI53omMuPbYfhjaQqITa3
KvIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1721781839; x=1722386639;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:x-beenthere
:x-gm-message-state:sender:from:to:cc:subject:date:message-id
:reply-to;
bh=cxK+8Yz420krABR27or65yBKv0vpAEQVTNSHOeC6DC4=;
b=Kpgb4C6VkOt+DKtdlfel8D287wgHTScoKfqPQAuUI8YbmQY/ToWKTMBIogI/O6pozp
U5QHr6lJWv7AqzzD28fWx5exJliVAKNsXpRc07knSHhgkgmSPD8uQElOm4i1fNqpC37B
B3Gt1sQ6IOx0ZRF489Vqw2dBPt9Mi5mbwThdHxg8T+R2fDXXSQXCyRtpsCoAc1I0aT9H
mTzIoMDu7lPtGRlsDVs25APK+Hr/0eWiLzY+GT2HEKeZgs7vgz6YtszHNA1sEfj+O2XB
TC8eV+vQYBKcpGK5E7sJSGar4juEnzXhQX24qNlfvXXRTufRw2IRQImHnhGyKVKTqLNH
2OgQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCWjbqQe+jZrZiVsJTAziCkQW6Pj46zwbkkyG4elRa1D7WIl8e8zesTdjZcNpv4FddLyV5NYHWoawFMCmtB9BPp00Ti+WbI=
X-Gm-Message-State: AOJu0YzMoKhj71RjG/FLQJ+ZTdqHY/Mrc5wZprBqr5CT7YVK2oGUhXKh
/SNWlPYl/0SpK+hLkAVeO4aRdPoHxwF88oTyYcylxswJiNHtU3s/
X-Google-Smtp-Source: AGHT+IHNJvlI5ayToKdkkUEj9Ozs+k3cVISfFkTiJHCVieFbCVJTd1HnSvw85/KNrtZDvwig4yCX8g==
X-Received: by 2002:a25:ae5e:0:b0:e03:601a:1a83 with SMTP id 3f1490d57ef6-e0b0985c9abmr1748809276.39.1721781838687;
Tue, 23 Jul 2024 17:43:58 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:2e07:0:b0:e03:514d:f716 with SMTP id 3f1490d57ef6-e05fdbbe498ls6653639276.2.-pod-prod-07-us;
Tue, 23 Jul 2024 17:43:57 -0700 (PDT)
X-Received: by 2002:a05:690c:d87:b0:615:32e1:d82c with SMTP id 00721157ae682-66a66254672mr9071697b3.6.1721781837315;
Tue, 23 Jul 2024 17:43:57 -0700 (PDT)
Received: by 2002:a05:690c:26c7:b0:627:7f59:2eee with SMTP id 00721157ae682-6691747e85fms7b3;
Tue, 23 Jul 2024 17:38:39 -0700 (PDT)
X-Received: by 2002:a81:ee09:0:b0:651:2eea:4dfe with SMTP id 00721157ae682-672b6a14cb5mr99217b3.0.1721781518530;
Tue, 23 Jul 2024 17:38:38 -0700 (PDT)
Date: Tue, 23 Jul 2024 17:38:38 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <1d64b24e-9ae4-4eac-b93a-c35fdcd26d6en@googlegroups.com>
In-Reply-To: <d57a02a84e756dbda03161c9034b9231@dtrt.org>
References: <Zpk7EYgmlgPP3Y9D@petertodd.org>
<c6593662694f9d4a4fe999dd432f87ff@dtrt.org>
<ZpvRvRybauFFnhQV@petertodd.org>
<d57a02a84e756dbda03161c9034b9231@dtrt.org>
Subject: Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack
of Full-RBF In Core
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_1119486_1116258211.1721781518315"
X-Original-Sender: antoine.riard@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
<https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)
------=_Part_1119486_1116258211.1721781518315
Content-Type: multipart/alternative;
boundary="----=_Part_1119487_287820526.1721781518315"
------=_Part_1119487_287820526.1721781518315
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Dave,
> Weak blocks also provide a decentralized DoS-resistant mechanism for
> voluntarily communicating all sorts of information from miners to other
> miners and relay nodes. That makes them an excellent tool for resolving
> any attack that depends on miners and relay nodes having a divergent set
> of transactions.
I think the mechanism you're describing is plagued by the following=20
vulnerability:
- an attacker mempool-partition all miners by exploiting transaction-relay=
=20
asymmetries (e.g same feerate, same weight, diff txid)
- an attacker broadcast an appealing transaction entering the top of mempoo=
l
- a weak block up to 4MB is generated for each such miner partitioned and=
=20
relayed to the rest of the network
- the whole block-relay network is wasting 4 MB of block-relay bandwidth=20
multiplied by N, the number of miners affected
- the mempool-partitition transaction vector might have paid a sub-minimal=
=20
feerate just to enter in mempool
Bonus point: the attacker has hashrate capabilities to mine the block=20
including the mempool-partition transaction vector
rendering a null gain for the DoSed miners whatever the weak block reward=
=20
mechanism for the "weak block" proposal (unless
the reward is exogeneous to the bitcoin blockchain, a type of in-protocol=
=20
reward one might skeptical relatively to bitcoin
security model).
I don't think the "weak block" proposal as you're presenting it makes=20
sense, at the very least quantitative evaluations
would be necessary to be sure you're not worsening the denial-of-service=20
aspect. In the present layout of the "weak block"
proposal, I really think you saying it's a decentralized DoS-resistant=20
mechanism is deeply misleading and inaccurate for
the rest of the community.
Zooming out, I believe it's an intesresting problem wishing to improve=20
rewarding of miners income if we wish to encourage
solo miners, and improve on the initial financial liquidity incentives that=
=20
are driving miners to gather themselves in pool
since the early days of bitcon, though I don't see how "weak block" can be=
=20
a viable solution.
Best,
Antoine
ots hash: 85636ac4e91bc781bbcdc8c0a24a17ad1c90039c6cabbb4d3ddd334c2c29fc02=
=20
Le dimanche 21 juillet 2024 =C3=A0 19:04:29 UTC+1, David A. Harding a =C3=
=A9crit :
> On 2024-07-20 05:03, Peter Todd wrote:
> > What other "free" relay attacks can you think of that were fixed?
>
> The two you mention were the two I had in mind.
>
> > Did you actually read my One-Shot RBFR proposal?
>
> Yes. It didn't provide any examples of RBFr free relay and I wanted to
> see whether a basic RBFr free relay attack would use significantly more,
> significantly less, or about the same amount of bandwidth per dollar
> spent as other free relay attacks. My conclusion is that it's about the
> same.
>
> > Weak blocks are not a solution to any of the "free" relay attacks I've
> > disclosed and your source does not claim that they are a "free" relay
> > solution.
>
> It does not explicitly say that, but it does say: "bonus use-cases:
> =E2=80=9CForcible insertion=E2=80=9D of transactions that are incentive-c=
ompatible but
> violate anti-DoS rules".
>
> For example, in some of the scenarios you describe, the attacker sends
> an appealing transaction to miners and then sends less appealing
> versions of that transaction to relay nodes. If the appealing
> transaction enters the top mempool and gets included in a weak block,
> relay nodes will stop relaying less appealing variations minutes to
> hours before they otherwise would.
>
> Weak blocks also provide a decentralized DoS-resistant mechanism for
> voluntarily communicating all sorts of information from miners to other
> miners and relay nodes. That makes them an excellent tool for resolving
> any attack that depends on miners and relay nodes having a divergent set
> of transactions.
>
> > 1) Have you've read my One Shot RBFR proposal? In particular, my
> > analysis of DoS attacks *including* existing DoS attacks like
> > simultaneous broadcast.
> >=20
> > 2) Do you agree or disagree with me that these existing DoS attacks
> > are real?
>
> Yes, I've read your proposal, and I agree those attacks are plausible.
> In my mind, the major difference between those free relay attacks
> and RBFR free relay attacks is how solvable they are.
>
> I think it's easy to sketch a significant mitigation to all free relay
> attacks (including RBFR):
>
> - Reduce the maximum size of both relayable transactions and in-mempool
> packages, e.g. from 100,000 vbytes to 1,000 vbytes.
>
> - Reduce the maximum size of the mempool, e.g. from 300 MB to 10 MB.
>
> - Increase the default mempool feerate floor, e.g. from e.g. from 1
> sat/vb to 100 sat/vb.
>
> That would break relay of many existing presigned transactions,
> potentially leading to money loss, and would break other existing
> usecases, not to mention introduce other problems. However, I think
> it's sufficient to prove that a mitigation to free relay is possible
> without rendering the network unusable.
>
> Of course, an ideal solution wouldn't require placing any additional
> constraints on mempool policy. For the case of free relay due to
> divergent mempool policies, maybe it's something that could be done with
> transaction set reconciliation (~erlay), functions for allowing
> independent nodes to come to consistent conclusions about the best
> revenue set of transactions (~cluster mempool), P2P relay of non-obvious
> cluster linearizations[1], and miners voluntarily committing to their
> mempool contents in candidate blocks and P2P relaying those commitments
> in weak blocks.
>
> Innovations like that don't work for RBFR. If mempool policy is kept
> the same, free relay attacks with RBFR remain equally effective no
> matter what mechanisms we implement to improve preconsensus consistency.
>
> If pure RBFR is added and clever protocol developers find ways to
> largely fix other free relay attacks, then devs will either need to
> significantly restrict mempool policy anyway or will need to restrict or
> remove RBFR to make Bitcoin Core safe. Given that, it seems to me like
> a very reasonable decision not to add pure RBFR and to wait until better
> tools like cluster mempool become available before evaluating
> significant changes to RBF policy (like one-shot RBFR).
>
> Thanks,
>
> -Dave
>
> [1]=20
>
> https://github.com/bitcoinops/bitcoinops.github.io/pull/1421#discussion_r=
1415834695
>
--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/1d64b24e-9ae4-4eac-b93a-c35fdcd26d6en%40googlegroups.com.
------=_Part_1119487_287820526.1721781518315
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Dave,<br /><br />> Weak blocks also provide a decentralized DoS-resis=
tant mechanism for<br />> voluntarily communicating all sorts of informa=
tion from miners to other<br />> miners and relay nodes. That makes them=
an excellent tool for resolving<br />> any attack that depends on miner=
s and relay nodes having a divergent set<br />> of transactions.<br /><b=
r />I think the mechanism you're describing is plagued by the following vul=
nerability:<br />- an attacker mempool-partition all miners by exploiting t=
ransaction-relay asymmetries (e.g same feerate, same weight, diff txid)<br =
/>- an attacker broadcast an appealing transaction entering the top of memp=
ool<br />- a weak block up to 4MB is generated for each such miner partitio=
ned and relayed to the rest of the network<br />- the whole block-relay net=
work is wasting 4 MB of block-relay bandwidth multiplied by N, the number o=
f miners affected<br />- the mempool-partitition transaction vector might h=
ave paid a sub-minimal feerate just to enter in mempool<br /><br />Bonus po=
int: the attacker has hashrate capabilities to mine the block including the=
mempool-partition transaction vector<br />rendering a null gain for the Do=
Sed miners whatever the weak block reward mechanism for the "weak block" pr=
oposal (unless<br />the reward is exogeneous to the bitcoin blockchain, a t=
ype of in-protocol reward one might skeptical relatively to bitcoin<br />se=
curity model).<br /><br />I don't think the "weak block" proposal as you're=
presenting it makes sense, at the very least quantitative evaluations<br /=
>would be necessary to be sure you're not worsening the denial-of-service a=
spect. In the present layout of the "weak block"<br />proposal, I really th=
ink you saying it's a decentralized DoS-resistant mechanism is deeply misle=
ading and inaccurate for<br />the rest of the community.<br /><br />Zooming=
out, I believe it's an intesresting problem wishing to improve rewarding o=
f miners income if we wish to encourage<br />solo miners, and improve on th=
e initial financial liquidity incentives that are driving miners to gather =
themselves in pool<br />since the early days of bitcon, though I don't see =
how "weak block" can be a viable solution.<br /><br />Best,<br />Antoine<br=
/>ots hash: 85636ac4e91bc781bbcdc8c0a24a17ad1c90039c6cabbb4d3ddd334c2c29fc=
02=C2=A0<br /><br /><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"g=
mail_attr">Le dimanche 21 juillet 2024 =C3=A0 19:04:29 UTC+1, David A. Hard=
ing a =C3=A9crit=C2=A0:<br/></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding=
-left: 1ex;">On 2024-07-20 05:03, Peter Todd wrote:
<br>> What other "free" relay attacks can you think of that we=
re fixed?
<br>
<br>The two you mention were the two I had in mind.
<br>
<br>> Did you actually read my One-Shot RBFR proposal?
<br>
<br>Yes. It didn't provide any examples of RBFr free relay and I wante=
d to
<br>see whether a basic RBFr free relay attack would use significantly more=
,
<br>significantly less, or about the same amount of bandwidth per dollar
<br>spent as other free relay attacks. My conclusion is that it's abou=
t the
<br>same.
<br>
<br>> Weak blocks are not a solution to any of the "free" rela=
y attacks I've
<br>> disclosed and your source does not claim that they are a "fre=
e" relay
<br>> solution.
<br>
<br>It does not explicitly say that, but it does say: "bonus use-cases=
:
<br>=E2=80=9CForcible insertion=E2=80=9D of transactions that are incentive=
-compatible but
<br>violate anti-DoS rules".
<br>
<br>For example, in some of the scenarios you describe, the attacker sends
<br>an appealing transaction to miners and then sends less appealing
<br>versions of that transaction to relay nodes. If the appealing
<br>transaction enters the top mempool and gets included in a weak block,
<br>relay nodes will stop relaying less appealing variations minutes to
<br>hours before they otherwise would.
<br>
<br>Weak blocks also provide a decentralized DoS-resistant mechanism for
<br>voluntarily communicating all sorts of information from miners to other
<br>miners and relay nodes. That makes them an excellent tool for resolvin=
g
<br>any attack that depends on miners and relay nodes having a divergent se=
t
<br>of transactions.
<br>
<br>> 1) Have you've read my One Shot RBFR proposal? In particular, =
my
<br>> analysis of DoS attacks *including* existing DoS attacks like
<br>> simultaneous broadcast.
<br>>=20
<br>> 2) Do you agree or disagree with me that these existing DoS attack=
s
<br>> are real?
<br>
<br>Yes, I've read your proposal, and I agree those attacks are plausib=
le.
<br>In my mind, the major difference between those free relay attacks
<br>and RBFR free relay attacks is how solvable they are.
<br>
<br>I think it's easy to sketch a significant mitigation to all free re=
lay
<br>attacks (including RBFR):
<br>
<br>- Reduce the maximum size of both relayable transactions and in-mempool
<br> packages, e.g. from 100,000 vbytes to 1,000 vbytes.
<br>
<br>- Reduce the maximum size of the mempool, e.g. from 300 MB to 10 MB.
<br>
<br>- Increase the default mempool feerate floor, e.g. from e.g. from 1
<br> sat/vb to 100 sat/vb.
<br>
<br>That would break relay of many existing presigned transactions,
<br>potentially leading to money loss, and would break other existing
<br>usecases, not to mention introduce other problems. However, I think
<br>it's sufficient to prove that a mitigation to free relay is possibl=
e
<br>without rendering the network unusable.
<br>
<br>Of course, an ideal solution wouldn't require placing any additiona=
l
<br>constraints on mempool policy. For the case of free relay due to
<br>divergent mempool policies, maybe it's something that could be done=
with
<br>transaction set reconciliation (~erlay), functions for allowing
<br>independent nodes to come to consistent conclusions about the best
<br>revenue set of transactions (~cluster mempool), P2P relay of non-obviou=
s
<br>cluster linearizations[1], and miners voluntarily committing to their
<br>mempool contents in candidate blocks and P2P relaying those commitments
<br>in weak blocks.
<br>
<br>Innovations like that don't work for RBFR. If mempool policy is ke=
pt
<br>the same, free relay attacks with RBFR remain equally effective no
<br>matter what mechanisms we implement to improve preconsensus consistency=
.
<br>
<br>If pure RBFR is added and clever protocol developers find ways to
<br>largely fix other free relay attacks, then devs will either need to
<br>significantly restrict mempool policy anyway or will need to restrict o=
r
<br>remove RBFR to make Bitcoin Core safe. Given that, it seems to me like
<br>a very reasonable decision not to add pure RBFR and to wait until bette=
r
<br>tools like cluster mempool become available before evaluating
<br>significant changes to RBF policy (like one-shot RBFR).
<br>
<br>Thanks,
<br>
<br>-Dave
<br>
<br>[1]=20
<br><a href=3D"https://github.com/bitcoinops/bitcoinops.github.io/pull/1421=
#discussion_r1415834695" target=3D"_blank" rel=3D"nofollow" data-saferedire=
cturl=3D"https://www.google.com/url?hl=3Dfr&q=3Dhttps://github.com/bitc=
oinops/bitcoinops.github.io/pull/1421%23discussion_r1415834695&source=
=3Dgmail&ust=3D1721867759933000&usg=3DAOvVaw2X4-nfDVxG2uLXgZHywT3U"=
>https://github.com/bitcoinops/bitcoinops.github.io/pull/1421#discussion_r1=
415834695</a>
<br></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/1d64b24e-9ae4-4eac-b93a-c35fdcd26d6en%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/1d64b24e-9ae4-4eac-b93a-c35fdcd26d6en%40googlegroups.com</a>.=
<br />
------=_Part_1119487_287820526.1721781518315--
------=_Part_1119486_1116258211.1721781518315--
|