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
|
Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 4B87FC000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Feb 2022 02:54:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 2A36A82862
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Feb 2022 02:54:48 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id oNCe57BZ9gb7
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Feb 2022 02:54:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
[IPv6:2a00:1450:4864:20::631])
by smtp1.osuosl.org (Postfix) with ESMTPS id 83256827CA
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Feb 2022 02:54:46 +0000 (UTC)
Received: by mail-ej1-x631.google.com with SMTP id h8so1405182ejy.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 15 Feb 2022 18:54:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=ccBIAYaF5YF6SQyQAJ5wA8e5Jp6MMdcWuHN+9Dt7cdw=;
b=afz9lnXXNOMjkbR3oG7HoTSTtsupoAyJZrSqQzcmhClGFAsXkBLrENbgrwk3u+Xj+m
jTr83iHFJ4yKFvyGbbBC59mcVadqIucxSFEIe7PYDcpdJZzj9UH+5ePb3d/YV9m7YZr9
xuVPD7znLJU7tTwgTpZAtDrh4LydGbJbgneRJK1bfOyFe9RRUuWF2VyGvNt3JzZSHAdT
RVvTDJt55FQHvYDBlb/9jE/Xt8XOOtnU5zeox9U4WAlozucDQTJs8djdL3Qf8r7RwVva
EX5/Va6EmsJDhe1iTI5sGtFbG6G5U/gM3LI5/1fC5PiX+qt5kSPL1LW9FgbqpwvyvA/y
UeKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=ccBIAYaF5YF6SQyQAJ5wA8e5Jp6MMdcWuHN+9Dt7cdw=;
b=X8PkgRYxu7ZSyoT4W+WigOrKW1nR6rTkFKcgVMA6hchjGS1in+AZfWSaU5eqKTY3Z7
E3lG5IG6LLmnEuJF+S4JeX2XlYGBkdevN0SPk4tS1DNpBlCBoTBs2BrtngzfJYZXdQ2T
Y5A1s/qTZOlOTndTKIKh7c1zb3eHDx5ApLgVCC0/OQemyU/DAo2BptZ+AdMDPKbB/Xi/
EJTepnjHSX46t77QE0gPyL3vWHNJfwF46eckTcUd8NcZOuADWFzbCVXY9ajJewuXZZe9
rRt6tAAg5u4w1afA0NNCfamgOK6crUEIHCTGsWXIF1ZWD+HDgCm5PRx5aKaLGK5wujIy
iVYg==
X-Gm-Message-State: AOAM5310kLTwnO3VSqA04exYyFB2kSpBWbsHLJQ8GXcB7cBz0rYK4xpG
3D9Xt9Wab6IV+ExsFh1FtSkSsrEB+A5oZOkfmFNaEmPu
X-Google-Smtp-Source: ABdhPJwthjU1v7Rpdh16iZL++cXe0fXgGinIWD2mS8gRLBXckDWwjJBdC8eDif82KEch7VMTBVZg0xAOk3kTp8ayehQ=
X-Received: by 2002:a17:906:93f7:b0:6cc:6319:6c43 with SMTP id
yl23-20020a17090693f700b006cc63196c43mr718168ejb.176.1644980084199; Tue, 15
Feb 2022 18:54:44 -0800 (PST)
MIME-Version: 1.0
References: <CAPfvXfKrnju1fzxOKs3Fx00NOPWHjedF7e4xMSGs8buwc0O2kw@mail.gmail.com>
<CALZpt+FwZTXEYYiJ=1XTXbDVECW41e9rNq8rn8AYr6m3yLAkPA@mail.gmail.com>
<CAPfvXfJN9zeJDYka8BycU102xGdwQ2O9=Khgjag-eYLmXRdsdA@mail.gmail.com>
<CALZpt+G0uXL04onty2N++6tWeX7Y=5KWw3x8-A0MvyUgZR-4Xw@mail.gmail.com>
<CAGpPWDaZ=Qx_phzjFJXzQc0ePWfuJmGKsPrsvj9X1pBTBrRgWA@mail.gmail.com>
<CAMZUoKnhyzJ=6W-=hxpmCyjiPyYMuS=eKjLN+bu5cuLRQ42nxA@mail.gmail.com>
<CAD5xwhjGqEu5z1O0ho9pHnUD+woSKeGUxh+7rdHq5fPZU+mzww@mail.gmail.com>
In-Reply-To: <CAD5xwhjGqEu5z1O0ho9pHnUD+woSKeGUxh+7rdHq5fPZU+mzww@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Tue, 15 Feb 2022 20:54:28 -0600
Message-ID: <CAGpPWDa0hs2FWiE3VZ9Y4hKkEt6Up0oTgfKu3+N04h1Fn33DsA@mail.gmail.com>
To: Jeremy Rubin <jeremy.l.rubin@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000094d69905d819c52a"
X-Mailman-Approved-At: Wed, 16 Feb 2022 13:35:05 +0000
Subject: Re: [bitcoin-dev] Thoughts on fee bumping
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: Wed, 16 Feb 2022 02:54:48 -0000
--00000000000094d69905d819c52a
Content-Type: text/plain; charset="UTF-8"
@Jeremy
> there are technical reasons for sponsors to not be monotone. Mostly that
it requires the maintenance of an additional permanent TX-Index, making
Bitcoin's state grow at a much worse rate
What do you mean by monotone in the context of sponsor transactions? And when
you say tx-index, do you mean an index for looking up a transaction by its
ID? Is that not already something nodes do?
> The sponsors proposal is a change from Epsilon-Strong Reorgability to
Epsilon-Weak Reorgability
It doesn't look like you defined that term in your list. Did you mean what
you listed as "Epsilon: Simple Existential Reorgability"? If so, I would
say that should be sufficient. I'm not sure I would even distinguish
between the "strong" and "simple" versions of these things, tho you could
talk about things that make reorgs more or less computationally difficult
on a spectrum. As long as the computational difficulty isn't significant
for miners vs their other computational costs, the computation isn't really
a problem.
@Russell
> The current consensus threshold for transactions to become invalid is a
100 block reorg
What do you mean by this? The only 100 block period I'm aware of is the
coinbase cooldown period.
> I promise to personally build a wallet that always creates transactions
on the verge of becoming invalid should anyone ever implement a feature
that violates this tx validity principle.
Could you explain how you would build a wallet like that with a sponsor
transaction as described by Jeremy? What damage do you think such a wallet
could do? As far as I can tell, such a wallet is very unlikely to do more
damage to the network than it does to the user of that wallet.
On Tue, Feb 15, 2022 at 3:39 PM Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> The difference between sponsors and this issue is more subtle. The issue
> Suhas raised was with a variant of sponsors trying to address a second
> criticism, not sponsors itself, which is secure against this.
>
> I think I can make this clear by defining a few different properties:
>
> Strong Reorgability: The transaction graph can be arbitrarily reorged into
> any series of blocks as long as dependency order/timelocks are respected.
> Simple Existential Reorgability: The transaction graph can be reorged into
> a different series of blocks, and it is not computationally difficult to
> find such an ordering.
> Epsilon-Strong Reorgability: The transaction graph can be arbitrarily
> reorged into any series of blocks as long as dependency order/timelocks are
> respected, up to Epsilon blocks.
> Epsilon: Simple Existential Reorgability: The transaction graph can be
> reorged into a different series of blocks, and it is not computationally
> difficult to find such an ordering, up to epsilon blocks.
> Perfect Reorgability: The transaction graph can be reorged into a
> different series of blocks, but the transactions themselves are already
> locked in.
>
> Perfect Reorgability doesn't exist in Bitcoin because unconfirmed
> transactions can be double spent which invalidates descendants. Notably,
> for a subset of the graph which is CTV Congestion control tree expansions,
> perfect reorg ability would exist, so it's not just a bullshit concept to
> think about :)
>
> The sponsors proposal is a change from Epsilon-Strong Reorgability to
> Epsilon-Weak Reorgability. It's not clear to me that there is any
> functional reason to rely on Strongness when Bitcoin's reorgability is
> already not Perfect, so a reorg generator with malicious intent can already
> disturb the tx graph. Epsion-Weak Reorgability seems to be a sufficient
> property.
>
> Do you disagree with that?
>
> Best,
>
> Jeremy
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
>
> On Tue, Feb 15, 2022 at 12:25 PM Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>>
>>> >> 2. (from Suhas) "once a valid transaction is created, it should not
>>> become invalid later on unless the inputs are double-spent."
>>> > This doesn't seem like a huge concern to me
>>>
>>> I agree that this shouldn't be a concern. In fact, I've asked numerous
>>> people in numerous places what practical downside there is to transactions
>>> that become invalid, and I've heard basically radio silence other than one
>>> off hand remark by satoshi at the dawn of time which didn't seem to me to
>>> have good reasoning. I haven't seen any downside whatsoever of transactions
>>> that can become invalid for anyone waiting the standard 6 confirmations -
>>> the reorg risks only exists for people not waiting for standard
>>> finalization. So I don't think we should consider that aspect of a
>>> sponsorship transaction that can only be mined with the transaction it
>>> sponsors to be a problem unless a specific practical problem case can be
>>> identified. Even if a significant such case was identified, an easy
>>> solution would be to simply allow sponsorship transactions to be mined on
>>> or after the sponsored transaction is mined.
>>>
>>
>> The downside is that in a 6 block reorg any transaction that is moved
>> past its expiration date becomes invalid and all its descendants become
>> invalid too.
>>
>> The current consensus threshold for transactions to become invalid is a
>> 100 block reorg, and I see no reason to change this threshold. I promise
>> to personally build a wallet that always creates transactions on the verge
>> of becoming invalid should anyone ever implement a feature that violates
>> this tx validity principle.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--00000000000094d69905d819c52a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">@Jeremy<div><br></div><div>=C2=A0>=C2=A0<span style=3D"=
color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">there are technica=
l reasons for sponsors to not be monotone. Mostly that it requires the main=
tenance=C2=A0of an additional permanent TX-Index, making Bitcoin's stat=
e grow at a much worse=C2=A0rate</span></div><div><span style=3D"color:rgb(=
0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div><div><span =
style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">What do y=
ou mean by monotone in the context of sponsor transactions? And w</span><sp=
an style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">hen yo=
u say tx-index, do you mean an index for looking up a transaction by its ID=
? Is that not already something nodes do?=C2=A0</span></div><div><br><div>&=
gt;=C2=A0<span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-s=
erif">The sponsors proposal is a change from Epsilon-Strong Reorgability to=
Epsilon-Weak Reorgability</span></div><div><span style=3D"color:rgb(0,0,0)=
;font-family:arial,helvetica,sans-serif"><br></span></div><div><span style=
=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">It doesn't=
look like you defined that term in your list.</span>=C2=A0Did you mean wha=
t you listed as "<span style=3D"color:rgb(0,0,0);font-family:arial,hel=
vetica,sans-serif">Epsilon: Simple Existential Reorgability"? If so, I=
would say that should be sufficient. I'm not sure I would even disting=
uish between the "strong" and "simple" versions of thes=
e things, tho you could talk about things that make reorgs more or less com=
putationally difficult on a spectrum. As long as the computational difficul=
ty isn't significant for miners vs their other computational costs, the=
computation isn't really a problem.</span></div><div><span style=3D"co=
lor:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div><di=
v><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">@=
Russell</span></div><div>> The current consensus threshold for transacti=
ons to become invalid is a 100 block reorg</div><div><br></div><div>What do=
you mean by this? The only 100 block period I'm aware of is the coinba=
se cooldown period.=C2=A0</div><div><br></div><div>>=C2=A0 I promise to =
personally build a wallet that always creates transactions on the verge of =
becoming invalid should anyone ever implement a feature that violates this =
tx validity principle.</div><div><br></div><div>Could you explain how you w=
ould build a wallet like that with a sponsor transaction as described by Je=
remy? What damage do you think such a wallet could do? As far as I can tell=
, such a wallet is very unlikely to do more damage to the network than it d=
oes to the user of that wallet.=C2=A0</div></div></div><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Feb 15, 2022 at 3:=
39 PM Jeremy Rubin via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.=
linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.or=
g</a>> wrote:<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 dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><div class=3D"gmail_d=
efault">The difference between sponsors and this issue is more subtle. The =
issue Suhas raised was with a variant of sponsors trying to address a secon=
d criticism, not sponsors itself, which is secure against this.</div><div c=
lass=3D"gmail_default"><br></div><div class=3D"gmail_default">I think I can=
make this clear by defining a few different properties:</div><div class=3D=
"gmail_default"><br></div><div class=3D"gmail_default">Strong Reorgability:=
The transaction graph can be arbitrarily reorged into any series of blocks=
as long as dependency order/timelocks are respected.</div><div class=3D"gm=
ail_default">Simple Existential Reorgability: The=C2=A0transaction graph ca=
n be reorged into a different series of blocks, and it is not computational=
ly difficult to find such an ordering.</div><div class=3D"gmail_default">Ep=
silon-Strong Reorgability: The transaction graph can be arbitrarily reorged=
into any series of blocks as long as dependency order/timelocks are respec=
ted, up to Epsilon blocks.</div><div class=3D"gmail_default"><div class=3D"=
gmail_default">Epsilon: Simple Existential Reorgability: The=C2=A0transacti=
on graph can be reorged into a different series of blocks, and it is not co=
mputationally difficult to find such an ordering, up to epsilon blocks.</di=
v><div class=3D"gmail_default">Perfect Reorgability: The transaction graph =
can be reorged into a different series of blocks, but the transactions them=
selves are already locked in.</div><div class=3D"gmail_default"><br></div><=
div class=3D"gmail_default">Perfect Reorgability doesn't exist in Bitco=
in because unconfirmed transactions can be double spent which invalidates d=
escendants. Notably, for a subset of the graph which is CTV Congestion cont=
rol tree expansions, perfect reorg ability would exist, so it's not jus=
t a bullshit concept to think about :)</div><div class=3D"gmail_default"><b=
r></div><div class=3D"gmail_default">The sponsors proposal is a change from=
Epsilon-Strong Reorgability to Epsilon-Weak Reorgability. It's not cle=
ar to me that there is any functional reason to rely on Strongness when Bit=
coin's reorgability is already not Perfect,=C2=A0so a reorg generator w=
ith malicious intent can already disturb the tx graph. Epsion-Weak Reorgabi=
lity=C2=A0seems to be a sufficient property.</div><div class=3D"gmail_defau=
lt"><br></div><div class=3D"gmail_default">Do you disagree with that?</div>=
<div class=3D"gmail_default"><br></div><div class=3D"gmail_default">Best,</=
div><div class=3D"gmail_default"><br></div><div class=3D"gmail_default">Jer=
emy</div></div></div><br clear=3D"all"><div><div dir=3D"ltr"><div dir=3D"lt=
r">--<br><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@Jer=
emyRubin</a><br></div></div></div></div><br><div class=3D"gmail_quote"><div=
dir=3D"ltr" class=3D"gmail_attr">On Tue, Feb 15, 2022 at 12:25 PM Russell =
O'Connor via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxf=
oundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr"><div class=3D"gmail_quote"><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>>> 2. (from Su=
has) "once a valid transaction is created, it should not become invali=
d later on unless the inputs are double-spent."</div>> This doesn&#=
39;t seem like a huge concern to me=C2=A0<div><br></div><div>I agree that t=
his shouldn't be a concern. In fact, I've asked numerous people in =
numerous places what practical downside there is to transactions that becom=
e invalid, and I've heard basically radio silence other than one off ha=
nd remark by satoshi at the dawn of time which didn't seem to me to hav=
e good reasoning. I haven't seen any downside whatsoever of transaction=
s that can become invalid for anyone waiting the standard 6 confirmations -=
the reorg risks only exists for people not waiting for standard finalizati=
on. So I don't think we should consider that aspect of a sponsorship tr=
ansaction that can only be mined with the transaction it sponsors to be a p=
roblem unless a specific=C2=A0practical problem case can be identified. Eve=
n if a significant such=C2=A0case was identified, an easy solution would be=
to simply allow sponsorship transactions to be mined on or after the spons=
ored transaction is mined. <br></div></div></blockquote><div><br></div><div=
>The downside is that in a 6 block reorg any transaction that is moved past=
its expiration date becomes invalid and all its descendants become invalid=
too.<br></div><div><br></div><div>The current consensus threshold for tran=
sactions to become invalid is a 100 block reorg, and I see no reason to cha=
nge this threshold.=C2=A0 I promise to personally build a wallet that alway=
s creates transactions on the verge of becoming invalid should anyone ever =
implement a feature that violates this tx validity principle.<br></div></di=
v></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>
_______________________________________________<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>
--00000000000094d69905d819c52a--
|