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
|
Return-Path: <earonesty@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 244C8C002A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Apr 2023 00:57:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id ED05B83F25
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Apr 2023 00:57:02 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org ED05B83F25
Authentication-Results: smtp1.osuosl.org;
dkim=pass (2048-bit key) header.d=q32-com.20221208.gappssmtp.com
header.i=@q32-com.20221208.gappssmtp.com header.a=rsa-sha256
header.s=20221208 header.b=Hl/6OYqr
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=no autolearn_force=no
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 NDJ4omsBbLG2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Apr 2023 00:57:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 5E8E883F18
Received: from mail-yw1-x112e.google.com (mail-yw1-x112e.google.com
[IPv6:2607:f8b0:4864:20::112e])
by smtp1.osuosl.org (Postfix) with ESMTPS id 5E8E883F18
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Apr 2023 00:57:01 +0000 (UTC)
Received: by mail-yw1-x112e.google.com with SMTP id
00721157ae682-54fa1deb61dso4398777b3.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Apr 2023 17:57:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=q32-com.20221208.gappssmtp.com; s=20221208; t=1681865820; x=1684457820;
h=to:subject:message-id:date:from:in-reply-to:references:mime-version
:from:to:cc:subject:date:message-id:reply-to;
bh=/W66dQUi6Wx5zfcZAUoyQUT0XihjTEMNHuJQIIq52O8=;
b=Hl/6OYqrAMG3yfCWe4RvCkKPoIWMlWm/TAppkLT/0seukopg0ZzSErTxtxHKh2uopK
41ZfaZNlnHb9Oyw4AOnJ/iY2CUHZzPlqzcQBEPPVfZZbavjKMDihH105GWKz5838gZCt
zWmK5o/jja/ZjkgHHZmafsWHnQe9Um1J4ikTBEMMyLSj7LSWmKXVHRb/ZBgUNI35F+qJ
A3R/8f9apSXfCxPji8bAko8D4GUN5+65hnyilAh3d/Cb98O6o6016t1DwsS7jVUYLN/w
d+/zQeOuUZgqo7xjD21USpoT35MLZTpSzbWwOpaDbXp4LBSWDvYSyegvTvilLl/cckRJ
pdxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20221208; t=1681865820; x=1684457820;
h=to:subject:message-id:date:from:in-reply-to:references:mime-version
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=/W66dQUi6Wx5zfcZAUoyQUT0XihjTEMNHuJQIIq52O8=;
b=h8JBEymJiEfq+x74myNUBS3Xm/vsYBGPKEYnPBBf8KfZZjNimvADgzUwFTEQC0L4/v
Zwif9Nd/qoZs/X/tqduFiW0Tjmm23vtF9G7kaSUmsiu22IsjNOSRYr6qAY/tTQgfR/CD
LpK2yLxoUQ5g3iKzpIW61Fumc6XAx8MIFbbmmhXE3tQOyVE/ZYbBbEBpLDb5aJ1vbSiL
3tXO2M5qw1YOzdiXdTT8jOpK+y8kRVOWv6VXSH8eN3gJ3QQbBrsQn8TQz99I6UJ6d3w1
haRBlw05iTgb4wvWqB4FKNFkUPk7Q+6BMka3iXfwGu4sP2Fw5aJ7dqjZ8yS2VuNOemPj
J+6g==
X-Gm-Message-State: AAQBX9e5iWJLojDN5GRlcORAi0kZ9QUMGK9nWH8LMbsEMMO/Eyobgzmi
iLjO30AGygTsV4p1ROmrCwRnYfWuS5vM8mXZlw6OWeExC8vg
X-Google-Smtp-Source: AKy350ar43g/9lhOWoSgwHdrPF+XHu/eJ61DohGNbbgId7ClQX+tbiO6O0JJ0tyMVFNUnx7VbiH4dc+2ESIt2YXrG1E=
X-Received: by 2002:a81:f88:0:b0:54f:b503:6e69 with SMTP id
130-20020a810f88000000b0054fb5036e69mr14585753ywp.5.1681865819912; Tue, 18
Apr 2023 17:56:59 -0700 (PDT)
MIME-Version: 1.0
References: <uuq_VbxJp50_-m4ufKpEhJOknhZ0pvK8ioDabCkxtDjBYauO3gLKrj2O2tjS6YIFOnJLyaZg6-LENzom1DyQQ3TyMLIIaGz5IRrzrKB8gRs=@protonmail.com>
In-Reply-To: <uuq_VbxJp50_-m4ufKpEhJOknhZ0pvK8ioDabCkxtDjBYauO3gLKrj2O2tjS6YIFOnJLyaZg6-LENzom1DyQQ3TyMLIIaGz5IRrzrKB8gRs=@protonmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Tue, 18 Apr 2023 20:56:48 -0400
Message-ID: <CAJowKgLU1OiMsDWn5A894=+szQKrQrr6HcwUU8bhXwDwSHN83w@mail.gmail.com>
To: Michael Folkson <michaelfolkson@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c182ea05f9a5e67d"
X-Mailman-Approved-At: Wed, 19 Apr 2023 08:12:28 +0000
Subject: Re: [bitcoin-dev] Bitcoin Core maintainers and communication on
merge decisions
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, 19 Apr 2023 00:57:03 -0000
--000000000000c182ea05f9a5e67d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
yes, the code itself was far less contentious than the weird stab at
forking the network
there remains a real chance that bip 119 is the simplest and most flexible
and reasonably safe covenant tech for many use cases
although im partial to 118 as well because lightning is a killer app and it
makes batch channels more efficient
On Tue, Apr 18, 2023, 7:39 PM Michael Folkson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Communication has been a challenge on Bitcoin Core for what I can tell th=
e
> entire history of the project. Maintainers merge a pull request and provi=
de
> no commentary on why they=E2=80=99ve merged it. Maintainers leave a pull =
request
> with many ACKs and few (if any) NACKs for months and provide no commentar=
y
> on why they haven't merged it. I can only speculate on why and it probabl=
y
> depends on the individual maintainer. Sometimes it will be poor
> communication skills, sometimes it will be a desire to avoid
> accountability, sometimes it will be fear of unreasonable and spiteful
> legal action if they mistakenly merge a pull request that ends up
> containing a bug. But search through the pull requests on Bitcoin Core an=
d
> you will rarely see a rationale for a merge decision. The difference
> between say previous maintainers like Wladimir and some of the current
> maintainers is that previous maintainers were extremely responsive on IRC=
.
> If you disagreed with a merge decision or thought it had been merged
> prematurely they would be happy to discuss it on IRC. In present times at
> least a subset of the current maintainers are not responsive on IRC and
> will refuse to discuss a merge decision. One farcical recent example [0]
> was the pull request to add Vasil Dimov as a maintainer where despite man=
y
> ACKs from other maintainers and other long term contributors two
> maintainers (fanquake and Gloria) refused to discuss it on the pull reque=
st
> or on IRC. It took almost 5 months for Gloria to comment on the pull
> request despite many requests from me on the PR and on IRC. I even
> requested that they attend the weekly Core Dev IRC meeting to discuss it
> which they didn=E2=80=99t attend.
>
>
> A pull request to add a maintainer isn=E2=80=99t a normal pull request. G=
enerally
> pull requests contain a lot more lines of code than a single line adding =
a
> trusted key. Not merging a pull request for a long period of time can be
> extremely frustrating for a pull request author especially when maintaine=
rs
> and long term contributors don=E2=80=99t comment on the pull request and =
the pull
> request is stuck in =E2=80=9Crebase hell=E2=80=9D. Clearly it is the less=
er evil when
> compared to merging a harmful or bug ridden pull request but poor
> non-existent communication is not the only way to prevent this. Indeed it
> creates as many problems as it solves.
>
>
> Another farcical recent(ish) example was the CTV pull request [1] that
> ultimately led to a contentious soft fork activation attempt that was
> called off at the last minute. If you look at the comments on the pull
> request there were 3 individuals (including myself) who NACKed the pull
> request and I think it is fair to say that none of us would be considered
> long term contributors to Bitcoin Core. I have criticised Jeremy Rubin
> multiple times for continuing to pursue a soft fork activation attempt wh=
en
> it was clear it was contentious [3] but if you look at the pull request
> comments it certainly isn=E2=80=99t clear it was. Maintainers and long te=
rm
> contributors (if they commented at all) were gently enthusiastic (Concept
> ACKing etc) without ACKing that it was ready to merge. A long term observ=
er
> of the Core repo would have known that it wasn=E2=80=99t ready to merge o=
r ready to
> attempt to activate (especially given it was a consensus change) but a
> casual observer would have only seen Concept ACKs and ACKs with 3 stray
> NACKs. Many of these casual observers inflated the numbers on the
> utxos.org site [4] signalling support for a soft fork activation attempt.
>
>
> I set out originally to write about the controls and processes around
> merges on the default signet (bitcoin-inquisition [5]) but it quickly
> became obvious to me that if communication around Core merges/non-merges =
is
> this weak you can hardly expect it to be any better on
> bitcoin-inquisition/default signet where there is no real monetary value =
at
> stake. I will probably write about bitcoin-inquisition/default signet in =
a
> future email as I do think the perception that it is =E2=80=9Cthe one and=
only=E2=80=9D
> staging ground for consensus changes is dangerous [6] if the maintainer(s=
)
> on that project have the same inclinations as a subset of the Core
> maintainers.
>
>
> As I stated at the beginning there is an element to this which is not
> individual(s) specific and an adverse reaction to outright malicious acto=
rs
> external to any of these projects. I do not think any of the current
> maintainers on Core or bitcoin-inquisition are outright malicious even if=
a
> subset of them consistently frustrate me with their lack of transparency
> and accountability. But this issue isn't going away and I'm sure we'll
> hear more on this from others in the coming months. To me it is a straigh=
t
> choice of taking transparency and accountability much more seriously or
> failing that investing more heavily (time and resources) in consensus
> compatible forks of Core and treating Core like it is a proprietary "open
> source" project where merge decisions are not explained or justified in t=
he
> open.
>
>
> [0]: https://github.com/bitcoin/bitcoin/pull/25871
>
> [1]: https://github.com/bitcoin/bitcoin/pull/21702
>
> [2]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386=
.html
>
> [3]:
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>
> [4]: https://utxos.org/signals/
>
> [5]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/02=
0921.html
>
> [6]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/02=
0948.html
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--000000000000c182ea05f9a5e67d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">yes, the code itself was far less contentious than the we=
ird stab at=C2=A0 forking the network=C2=A0<div dir=3D"auto"><br></div><div=
dir=3D"auto">there remains a real chance that bip 119 is the simplest and =
most flexible and reasonably safe covenant tech for many use cases</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">although im partial to 118 as we=
ll because lightning is a killer app and it makes batch channels more effic=
ient</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div></div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, A=
pr 18, 2023, 7:39 PM Michael Folkson via bitcoin-dev <<a href=3D"mailto:=
bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.or=
g</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"font=
-family:Arial,sans-serif;font-size:14px"><p style=3D"margin:0px;font:12px H=
elvetica">Communication has been a challenge on Bitcoin Core for what I can=
tell the entire history of the project. Maintainers merge a pull request a=
nd provide no commentary on why they=E2=80=99ve merged it. Maintainers leav=
e a pull request with many ACKs and few (if any) NACKs for months and provi=
de no commentary on why they haven't merged it. I can only speculate on=
why and it probably depends on the individual maintainer. Sometimes it wil=
l be poor communication skills, sometimes it will be a desire to avoid acco=
untability, sometimes it will be fear of unreasonable and spiteful legal ac=
tion if they mistakenly merge a pull request that ends up containing a bug.=
But search through the pull requests on Bitcoin Core and you will rarely s=
ee a rationale for a merge decision. The difference between say previous ma=
intainers like Wladimir and some of the current maintainers is that previou=
s maintainers were extremely responsive on IRC. If you disagreed with a mer=
ge decision or thought it had been merged prematurely they would be happy t=
o discuss it on IRC. In present times at least a subset of the current main=
tainers are not responsive on IRC and will refuse to discuss a merge decisi=
on. One farcical recent example [0] was the pull request to add Vasil Dimov=
as a maintainer where despite many ACKs from other maintainers and other l=
ong term contributors two maintainers (fanquake and Gloria) refused to disc=
uss it on the pull request or on IRC. It took almost 5 months for Gloria to=
comment on the pull request despite many requests from me on the PR and on=
IRC. I even requested that they attend the weekly Core Dev IRC meeting to =
discuss it which they didn=E2=80=99t attend.</p><p style=3D"margin:0px;font=
:12px Helvetica;min-height:14px"><br></p><p style=3D"margin:0px;font:12px H=
elvetica">A pull request to add a maintainer isn=E2=80=99t a normal pull re=
quest. Generally pull requests contain a lot more lines of code than a sing=
le line adding a trusted key. Not merging a pull request for a long period =
of time can be extremely frustrating for a pull request author especially w=
hen maintainers and long term contributors don=E2=80=99t comment on the pul=
l request and the pull request is stuck in =E2=80=9Crebase hell=E2=80=9D. C=
learly it is the lesser evil when compared to merging a harmful or bug ridd=
en pull request but poor non-existent communication is not the only way to =
prevent this. Indeed it creates as many problems as it solves.</p><p style=
=3D"margin:0px;font:12px Helvetica;min-height:14px"><br></p><p style=3D"mar=
gin:0px;font:12px Helvetica">Another farcical recent(ish) example was the C=
TV pull request [1] that ultimately led to a contentious soft fork activati=
on attempt that was called off at the last minute. If you look at the comme=
nts on the pull request there were 3 individuals (including myself) who NAC=
Ked the pull request and I think it is fair to say that none of us would be=
considered long term contributors to Bitcoin Core. I have criticised Jerem=
y Rubin multiple times for continuing to pursue a soft fork activation atte=
mpt when it was clear it was contentious [3] but if you look at the pull re=
quest comments it certainly isn=E2=80=99t clear it was. Maintainers and lon=
g term contributors (if they commented at all) were gently enthusiastic (Co=
ncept ACKing etc) without ACKing that it was ready to merge. A long term ob=
server of the Core repo would have known that it wasn=E2=80=99t ready to me=
rge or ready to attempt to activate (especially given it was a consensus ch=
ange) but a casual observer would have only seen Concept ACKs and ACKs with=
3 stray NACKs. Many of these casual observers inflated the numbers on the =
<a href=3D"http://utxos.org" target=3D"_blank" rel=3D"noreferrer">utxos.org=
</a> site [4] signalling support for a soft fork activation attempt.</p><p =
style=3D"margin:0px;font:12px Helvetica;min-height:14px"><br></p><p style=
=3D"margin:0px;font:12px Helvetica">I set out originally to write about the=
controls and processes around merges on the default signet (bitcoin-inquis=
ition [5]) but it quickly became obvious to me that if communication around=
Core merges/non-merges is this weak you can hardly expect it to be any bet=
ter on bitcoin-inquisition/default signet where there is no real monetary v=
alue at stake. I will probably write about bitcoin-inquisition/default sign=
et in a future email as I do think the perception that it is =E2=80=9Cthe o=
ne and only=E2=80=9D staging ground for consensus changes is dangerous [6] =
if the maintainer(s) on that project have the same inclinations as a subset=
of the Core maintainers.=C2=A0</p><p style=3D"margin:0px;font:12px Helveti=
ca"><br></p><p style=3D"margin:0px;font:12px Helvetica">As I stated at the =
beginning there is an element to this which is not individual(s) specific a=
nd an adverse reaction to outright malicious actors external to any of thes=
e projects. I do not think any of the current maintainers on Core or bitcoi=
n-inquisition are outright malicious even if a subset of them consistently =
frustrate me with their lack of transparency and accountability.<span>=C2=
=A0But this issue isn't going away and I'm sure we'll hear more=
on this from others in the coming months. To me it is a straight choice of=
taking transparency and accountability much more seriously or failing that=
investing more heavily (time and resources) in consensus compatible forks =
of Core and treating Core like it is a proprietary "open source" =
project where merge decisions are not explained or justified in the open.</=
span></p><p style=3D"margin:0px;font:12px Helvetica"><span><br></span></p><=
p style=3D"margin:0px;font:12px Helvetica">[0]: <a href=3D"https://github.c=
om/bitcoin/bitcoin/pull/25871" target=3D"_blank" rel=3D"noreferrer">https:/=
/github.com/bitcoin/bitcoin/pull/25871</a></p><p style=3D"margin:0px;font:1=
2px Helvetica">[1]: <a href=3D"https://github.com/bitcoin/bitcoin/pull/2170=
2" target=3D"_blank" rel=3D"noreferrer">https://github.com/bitcoin/bitcoin/=
pull/21702</a></p><p style=3D"margin:0px;font:12px Helvetica">[2]: <a href=
=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/0203=
86.html" target=3D"_blank" rel=3D"noreferrer">https://lists.linuxfoundation=
.org/pipermail/bitcoin-dev/2022-April/020386.html</a></p><p style=3D"margin=
:0px;font:12px Helvetica">[3]: <a href=3D"https://gist.github.com/michaelfo=
lkson/352a503f4f9fc5de89af528d86a1b718" target=3D"_blank" rel=3D"noreferrer=
">https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718</=
a></p><p style=3D"margin:0px;font:12px Helvetica">[4]: <a href=3D"https://u=
txos.org/signals/" target=3D"_blank" rel=3D"noreferrer">https://utxos.org/s=
ignals/</a></p><p style=3D"margin:0px;font:12px Helvetica">[5]: <a href=3D"=
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/0209=
21.html" target=3D"_blank" rel=3D"noreferrer">https://lists.linuxfoundation=
.org/pipermail/bitcoin-dev/2022-September/020921.html</a></p><p style=3D"ma=
rgin:0px;font:12px Helvetica">[6]: <a href=3D"https://lists.linuxfoundation=
.org/pipermail/bitcoin-dev/2022-September/020948.html" target=3D"_blank" re=
l=3D"noreferrer">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/20=
22-September/020948.html</a></p></div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px">
<div>
<div style=3D"font-family:arial;font-size:14px"><span style=3D"colo=
r:rgb(38,42,51);font-style:normal;font-weight:400;letter-spacing:normal;tex=
t-indent:0px;text-transform:none;white-space:pre-wrap;word-spacing:0px;back=
ground-color:rgb(255,255,255);float:none;display:inline"><span style=3D"fon=
t-family:'SFMono-Regular',Consolas,'Liberation Mono',Menlo,=
monospace,monospace"><span style=3D"font-size:14px">--<br>Michael Folkson<b=
r>Email: michaelfolkson at </span></span></span><a href=3D"http://protonmai=
l.com/" style=3D"line-height:normal;text-decoration:underline;font-family:&=
#39;SFMono-Regular',Consolas,'Liberation Mono',Menlo,monospace,=
monospace;font-size:14px;font-style:normal;font-weight:400;letter-spacing:n=
ormal;text-indent:0px;text-transform:none;white-space:pre-wrap;word-spacing=
:0px" rel=3D"noopener noreferrer noreferrer" target=3D"_blank">protonmail.c=
om</a><span style=3D"color:rgb(38,42,51);font-style:normal;font-weight:400;=
letter-spacing:normal;text-indent:0px;text-transform:none;white-space:pre-w=
rap;word-spacing:0px;background-color:rgb(255,255,255);float:none;display:i=
nline"><span style=3D"font-family:'SFMono-Regular',Consolas,'Li=
beration Mono',Menlo,monospace,monospace"><span style=3D"font-size:14px=
"> </span></span></span><br></div><div style=3D"font-family:arial;font-size=
:14px"><span style=3D"color:rgb(38,42,51);font-style:normal;font-weight:400=
;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:pre-=
wrap;word-spacing:0px;background-color:rgb(255,255,255);float:none;display:=
inline"><span style=3D"font-family:'SFMono-Regular',Consolas,'L=
iberation Mono',Menlo,monospace,monospace"><span style=3D"font-size:14p=
x">Keybase: michaelfolkson<br>PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 =
214C FEE3</span></span></span><br></div>
</div>
=20
<div>
=20
</div>
</div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--000000000000c182ea05f9a5e67d--
|