summaryrefslogtreecommitdiff
path: root/5c/8d3d18c990a0e1f81793fd01c506e0ccf8ba78
blob: 317b0eeb6178f61db26e94ee47ff8151f38cd400 (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
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
Return-Path: <aymeric@peersm.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id EE8FEC002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Apr 2023 20:06:29 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id B660F400EF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Apr 2023 20:06:29 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org B660F400EF
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 7iOK86ldahLO
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Apr 2023 20:06:27 +0000 (UTC)
X-Greylist: delayed 04:30:01 by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 29209404BF
Received: from 4.mo548.mail-out.ovh.net (4.mo548.mail-out.ovh.net
 [188.165.42.229])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 29209404BF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Apr 2023 20:06:27 +0000 (UTC)
Received: from mxplan6.mail.ovh.net (unknown [10.108.20.243])
 by mo548.mail-out.ovh.net (Postfix) with ESMTPS id D7DAB20541;
 Wed, 19 Apr 2023 15:17:03 +0000 (UTC)
Received: from peersm.com (37.59.142.103) by DAG6EX2.mxp6.local (172.16.2.52)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Wed, 19 Apr
 2023 17:17:03 +0200
Authentication-Results: garm.ovh; auth=pass
 (GARM-103G005f66d372a-1cb3-47b4-8aaa-d4bf91264c87,
 10553A8F8EAAD79A4F34D62EC79DDEE74908F878) smtp.auth=aymeric@peersm.com
X-OVh-ClientIp: 92.184.112.229
To: Michael Folkson <michaelfolkson@protonmail.com>, Bitcoin Protocol
 Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <uuq_VbxJp50_-m4ufKpEhJOknhZ0pvK8ioDabCkxtDjBYauO3gLKrj2O2tjS6YIFOnJLyaZg6-LENzom1DyQQ3TyMLIIaGz5IRrzrKB8gRs=@protonmail.com>
From: Aymeric Vitte <aymeric@peersm.com>
Message-ID: <514d39eb-4ebe-b2cf-a976-d1c80c15b422@peersm.com>
Date: Wed, 19 Apr 2023 17:17:02 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <uuq_VbxJp50_-m4ufKpEhJOknhZ0pvK8ioDabCkxtDjBYauO3gLKrj2O2tjS6YIFOnJLyaZg6-LENzom1DyQQ3TyMLIIaGz5IRrzrKB8gRs=@protonmail.com>
Content-Type: multipart/alternative;
 boundary="------------8D9DC305332CDD520009B867"
X-Originating-IP: [37.59.142.103]
X-ClientProxiedBy: DAG8EX1.mxp6.local (172.16.2.71) To DAG6EX2.mxp6.local
 (172.16.2.52)
X-Ovh-Tracer-GUID: 169329ec-22f6-49d3-9526-4a6577d53196
X-Ovh-Tracer-Id: 427560491800486810
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvhedrfedttddgkeekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhkffffgggjggtihesrgdtreertdefheenucfhrhhomhepteihmhgvrhhitgcugghithhtvgcuoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqnecuggftrfgrthhtvghrnhepteejgfelfeffgefhtddtfeehvdejfeeuveduuedvfefhjedukeffffekieejvedunecuffhomhgrihhnpehgihhthhhusgdrtghomhdpuhhtgihoshdrohhrghdplhhinhhugihfohhunhgurghtihhonhdrohhrghdpphhrohhtohhnmhgrihhlrdgtohhmpdhpvggvrhhsmhdrtghomhdplhhinhhkvgguihhnrdgtohhmnecukfhppeduvdejrddtrddtrddupdefjedrheelrddugedvrddutdefpdelvddrudekgedrudduvddrvddvleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqpdhnsggprhgtphhtthhopedupdhrtghpthhtohepsghithgtohhinhdquggvvheslhhishhtshdrlhhinhhugihfohhunhgurghtihhonhdrohhrghdpmhhitghhrggvlhhfohhlkhhsohhnsehprhhothhonhhmrghilhdrtghomhdpoffvte
 fjohhsthepmhhoheegkedpmhhouggvpehsmhhtphhouhht
X-Mailman-Approved-At: Wed, 19 Apr 2023 20:08:46 +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 20:06:30 -0000

--------------8D9DC305332CDD520009B867
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable

The different emails are overlong, it's difficult to follow

It is super surprising to see that Bitcoin has only 4 maintainers funded
by Brink and Blockstream, but I think the decisions are taken elsewhere

And I think the job of the maintainers is not only to be maintainers but
to do the PR sometimes, since the process is too complicate and they are
supposed to know well the code

And it seems like bitcoin is betting its future on lightning and/or
super clever (non understandble) changes to bitcoin scripting

While some simple changes can allow bitcoin to surpass ethereum, as
usual, like "Allow several OP_RETURN in one tx and no limited size"
https://github.com/bitcoin/bitcoin/issues/27043

How long it will take remains mysterious


Le 18/04/2023 =E0 14:40, Michael Folkson via bitcoin-dev a =E9crit :
>
> Communication has been a challenge on Bitcoin Core for what I can tell
> the entire history of the project. Maintainers merge a pull request
> and provide no commentary on why they=92ve merged it. Maintainers leave=

> a pull request with many ACKs and few (if any) NACKs for months and
> provide 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 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 and 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 many ACKs
> from other maintainers and other long term contributors two
> maintainers (fanquake and Gloria) refused to discuss 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=92t attend.
>
>
> A pull request to add a maintainer isn=92t a normal pull request.
> Generally 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 maintainers and long term contributors don=92t comment
> on the pull request and the pull request is stuck in =93rebase hell=94.=

> Clearly it is the lesser 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 solv=
es.
>
>
> 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 when it was clear it was contentious [3] but if you
> look at the pull request comments it certainly isn=92t clear it was.
> Maintainers and long term contributors (if they commented at all) were
> gently enthusiastic (Concept ACKing etc) without ACKing that it was
> ready to merge. A long term observer of the Core repo would have known

> that it wasn=92t ready to merge or 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 =93the one and only=94 staging ground for consens=
us
> changes is dangerous [6] if the maintainer(s) on that project have the
> same inclinations as a subset of the Core maintainers.=20
>
>
> 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
> actors 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 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.
>
>
> [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/0203=
86.html
>
> [3]:
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718=

>
> [4]: https://utxos.org/signals/
>
> [5]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/=
020921.html
>
> [6]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/=
020948.html
>
> -- Michael Folkson Email: michaelfolkson at protonmail.com
> <http://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

--=20
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ay=
ms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3b=
eed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transac=
tions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.p=
eersm.com
Peersm : http://www.peersm.com


--------------8D9DC305332CDD520009B867
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    The different emails are overlong, it's difficult to follow
    <p>It is super surprising to see that Bitcoin has only 4 maintainers
      funded by Brink and Blockstream, but I think the decisions are
      taken elsewhere</p>
    <p>And I think the job of the maintainers is not only to be
      maintainers but to do the PR sometimes, since the process is too
      complicate and they are supposed to know well the code<br>
    </p>
    <p>And it seems like bitcoin is betting its future on lightning
      and/or super clever (non understandble) changes to bitcoin
      scripting</p>
    <p>While some simple changes can allow bitcoin to surpass ethereum,
      as usual, like "Allow several OP_RETURN in one tx and no limited
      size" <a class="moz-txt-link-freetext" href="https://github.com/bitcoin/bitcoin/issues/27043">https://github.com/bitcoin/bitcoin/issues/27043</a></p>
    <p>How long it will take remains mysterious<br>
    </p>
    <br>
    <div class="moz-cite-prefix">Le 18/04/2023 à 14:40, Michael Folkson
      via bitcoin-dev a écrit :<br>
    </div>
    <blockquote
cite="mid:uuq_VbxJp50_-m4ufKpEhJOknhZ0pvK8ioDabCkxtDjBYauO3gLKrj2O2tjS6YIFOnJLyaZg6-LENzom1DyQQ3TyMLIIaGz5IRrzrKB8gRs=@protonmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <div style="font-family: Arial, sans-serif; font-size: 14px;">
        <p style="margin:0px;font:12px Helvetica">Communication has been
          a challenge on Bitcoin Core for what I can tell the entire
          history of the project. Maintainers merge a pull request and
          provide no commentary on why they’ve merged it. Maintainers
          leave a pull request with many ACKs and few (if any) NACKs for
          months and provide 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 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 and 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 many ACKs
          from other maintainers and other long term contributors two
          maintainers (fanquake and Gloria) refused to discuss 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’t
          attend.</p>
        <p style="margin:0px;font:12px Helvetica;min-height:14px"><br>
        </p>
        <p style="margin:0px;font:12px Helvetica">A pull request to add
          a maintainer isn’t a normal pull request. Generally 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 maintainers and long term contributors
          don’t comment on the pull request and the pull request is
          stuck in “rebase hell”. Clearly it is the lesser 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.</p>
        <p style="margin:0px;font:12px Helvetica;min-height:14px"><br>
        </p>
        <p style="margin:0px;font:12px Helvetica">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 when it was clear it was contentious [3] but if you
          look at the pull request comments it certainly isn’t clear it
          was. Maintainers and long term contributors (if they commented
          at all) were gently enthusiastic (Concept ACKing etc) without
          ACKing that it was ready to merge. A long term observer of the
          Core repo would have known that it wasn’t ready to merge or
          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.</p>
        <p style="margin:0px;font:12px Helvetica;min-height:14px"><br>
        </p>
        <p style="margin:0px;font:12px Helvetica">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 “the one and only”
          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. </p>
        <p style="margin:0px;font:12px Helvetica"><br>
        </p>
        <p style="margin:0px;font:12px Helvetica">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 actors 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.<span> 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 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="margin:0px;font:12px Helvetica"><span><br>
          </span></p>
        <p style="margin:0px;font:12px Helvetica">[0]:
          <a class="moz-txt-link-freetext" href="https://github.com/bitcoin/bitcoin/pull/25871">https://github.com/bitcoin/bitcoin/pull/25871</a></p>
        <p style="margin:0px;font:12px Helvetica">[1]:
          <a class="moz-txt-link-freetext" href="https://github.com/bitcoin/bitcoin/pull/21702">https://github.com/bitcoin/bitcoin/pull/21702</a></p>
        <p style="margin:0px;font:12px Helvetica">[2]:
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html</a></p>
        <p style="margin:0px;font:12px Helvetica">[3]:
          <a class="moz-txt-link-freetext" href="https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718">https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718</a></p>
        <p style="margin:0px;font:12px Helvetica">[4]:
          <a class="moz-txt-link-freetext" href="https://utxos.org/signals/">https://utxos.org/signals/</a></p>
        <p style="margin:0px;font:12px Helvetica">[5]:
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html</a></p>
        <p style="margin:0px;font:12px Helvetica">[6]:
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020948.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020948.html</a></p>
      </div>
      <div class="protonmail_signature_block" style="font-family: Arial,
        sans-serif; font-size: 14px;">
        <div class="protonmail_signature_block-user">
          <div style="font-family:arial;font-size:14px;"><span style="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="font-family:'SFMono-Regular', Consolas, 'Liberation Mono', Menlo, monospace, monospace;" class="font"><span style="font-size:14px;" class="size">--
Michael Folkson
Email: michaelfolkson at </span></span></span><a moz-do-not-send="true" href="http://protonmail.com/" style="line-height:normal;text-decoration:underline;font-family:'SFMono-Regular', Consolas, 'Liberation Mono', Menlo, monospace, monospace;font-size:14px;font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:pre-wrap;word-spacing:0px;" rel="noopener noreferrer" target="_blank">protonmail.com</a><span style="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="font-family:'SFMono-Regular', Consolas, 'Liberation Mono', Menlo, monospace, monospace;" class="font"><span style="font-size:14px;" class="size"> </span></span></span><br>
          </div>
          <div style="font-family:arial;font-size:14px;"><span style="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="font-family:'SFMono-Regular', Consolas, 'Liberation Mono', Menlo, monospace, monospace;" class="font"><span style="font-size:14px;" class="size">Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3</span></span></span><br>
          </div>
        </div>
        <div class="protonmail_signature_block-proton
          protonmail_signature_block-empty"> </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Sophia-Antipolis, France
CV: <a class="moz-txt-link-freetext" href="https://www.peersm.com/CVAV.pdf">https://www.peersm.com/CVAV.pdf</a>
LinkedIn: <a class="moz-txt-link-freetext" href="https://fr.linkedin.com/in/aymeric-vitte-05855b26">https://fr.linkedin.com/in/aymeric-vitte-05855b26</a>
GitHub : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms">https://www.github.com/Ayms</a>
A Universal Coin Swap system based on Bitcoin: <a class="moz-txt-link-freetext" href="https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7">https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7</a>
A bitcoin NFT system: <a class="moz-txt-link-freetext" href="https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7">https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7</a>
Move your coins by yourself (browser version): <a class="moz-txt-link-freetext" href="https://peersm.com/wallet">https://peersm.com/wallet</a>
Bitcoin transactions made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/bitcoin-transactions">https://github.com/Ayms/bitcoin-transactions</a>
torrent-live: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/torrent-live">https://github.com/Ayms/torrent-live</a>
node-Tor : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms/node-Tor">https://www.github.com/Ayms/node-Tor</a>
Anti-spies and private torrents, dynamic blocklist: <a class="moz-txt-link-freetext" href="http://torrent-live.peersm.com">http://torrent-live.peersm.com</a>
Peersm : <a class="moz-txt-link-freetext" href="http://www.peersm.com">http://www.peersm.com</a></pre>
  </body>
</html>

--------------8D9DC305332CDD520009B867--