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
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
|
Delivery-date: Tue, 17 Jun 2025 15:36:55 -0700
Received: from mail-yb1-f183.google.com ([209.85.219.183])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBC3PT7FYWAMRB6W3Y7BAMGQE3IKMPXI@googlegroups.com>)
id 1uRevD-0005PA-QU
for bitcoindev@gnusha.org; Tue, 17 Jun 2025 15:36:55 -0700
Received: by mail-yb1-f183.google.com with SMTP id 3f1490d57ef6-e81a449767asf7760810276.0
for <bitcoindev@gnusha.org>; Tue, 17 Jun 2025 15:36:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1750199806; x=1750804606; 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=6tFyzSVftuerQnU2RlEliqkrbOqVAK91Y5bP/5dH1pk=;
b=Svoolhj1x/4hSM0nNYmXPqvR5NTsFcvF/AE020mAS8on3DQJFPhpF8ANFzKRy/lx61
GH6DUHvT8Triuy7ON0L81iADDOJpTPa+g2wdEX0WcxaO/tJJbZA2zGsUgQtdyZaWZeeM
g5MCoGmsj8EOZdGfUM4LDQNxA8ZPM+G0QCIV72C9SMG25/32Z6vMY9qMfkRybtxJEz9t
4HhRqDsxldowe7BqCI6Lf4Kcvf7eB9Zg5VljUdYqD9gf893ndDlyQuSHZxe0s1LvRiwa
DFLNH0tYJyqWLt639N/Vx+55w8t0m+i+hhPRcOlrgp3RjthdkZtEz8tCrdD6wGsz28je
ZEyQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1750199806; x=1750804606; 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=6tFyzSVftuerQnU2RlEliqkrbOqVAK91Y5bP/5dH1pk=;
b=Jm6u7vKGzkdtNK30Cfgt8b0GQG7KRU+kETOdJrflyYxSQSRUXbAGMSHN/Z4oDJiw9S
PNE2xfCYwdDn84K/BgT1ShJdgTT+dcZO7jgavpj/7Ndb1XhhkOLqbjpDh+IeLLc5s1B3
yXMN4cd0XTqHnOaSkfLoBanJcbLy+eDosCMvHgbfzLqNDxo/SEzAwmEQBhQgRAPdqvLD
r+G8fXcdKknUHmIlOVIMwKKWi6OVCV/jGNfIA5ks8759fR3+Bt5cF/gnNMTxPYfLz6zs
UQDXP6tNs0S6Ls4Urdb3IzMIx9hZbLS5LeuNXoyxjOCDUI4w96STs/HkRjLdhzYUGtgH
HUKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1750199806; x=1750804606;
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=6tFyzSVftuerQnU2RlEliqkrbOqVAK91Y5bP/5dH1pk=;
b=XExNJNy9SVe5SYdd6rw/O2OQWEBhjqXhzuH9hjnvzG+zEk+oH+NTwmO3GQIxdi/IAJ
/sg4WOVFkltiqT5Q2FNu+NX3N0lp6qRs74bFewsF0FLbj5d6Uxclmxn6O0/XEqu4KbiU
/Fv2zeO9kgHjiObxIlPd7Iv0686LPXzIpS6CuTC6Qsbs2IlAd5cwq3l/wCL3NfpcTDzM
lHg8gLNOLUOfJ/JIAJBe4s5HJYsYP+GeiJySJgtKxIBQhceQibANLjXrMNl1vEoiVV69
JxO1XSmcHd/ZippySli5mjhkcjgLm2wGCFaQnRm6k6ceNDy5ORJ96BdABOdPXUA/WvEB
GulQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCX9P+FrDIpc3o3hv4+7iO5W7+Dg6t+at8xkR6lwQL3jq7WfID4d+ZZI54EMsXFDL6TCPyLDIibo0cer@gnusha.org
X-Gm-Message-State: AOJu0Yz3o6sbSP1hOQ7U/sEJtdExuVZwcTk3ZRi3O1SDLVK0KmBHtxq0
W495gk6rZLYyKlmlXOx1aM+A4iU7e8X7F/6tkEPAskeLfRC5dtDHAFuV
X-Google-Smtp-Source: AGHT+IGYifkBIQyqXDfDlDnberal4n/BfnkNf/5lhcUJaoPFWCP6VV1AJBqeBihNdFAd0wyMncNFVg==
X-Received: by 2002:a05:6902:150c:b0:e7f:7334:3fa2 with SMTP id 3f1490d57ef6-e822acab508mr20545166276.2.1750199805766;
Tue, 17 Jun 2025 15:36:45 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZfkxyX0jpz09Lhi9jpSfwDggVl1Efjmofk1IwNUpfF5LA==
Received: by 2002:a25:d847:0:b0:e7d:804c:d381 with SMTP id 3f1490d57ef6-e820dac7c5als6655976276.2.-pod-prod-00-us;
Tue, 17 Jun 2025 15:36:41 -0700 (PDT)
X-Received: by 2002:a05:690c:4b91:b0:70e:61b:afed with SMTP id 00721157ae682-712a6c2a5c1mr5574227b3.7.1750199801562;
Tue, 17 Jun 2025 15:36:41 -0700 (PDT)
Received: by 2002:a05:690c:3149:b0:711:63b1:720 with SMTP id 00721157ae682-71163b129c5ms7b3;
Sat, 14 Jun 2025 22:41:52 -0700 (PDT)
X-Received: by 2002:a05:690c:112:b0:711:5a8c:e815 with SMTP id 00721157ae682-71172215fb9mr86571307b3.6.1749966110564;
Sat, 14 Jun 2025 22:41:50 -0700 (PDT)
Date: Sat, 14 Jun 2025 22:41:50 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <03dff9ee-5a2f-41d8-93b4-fa6e53109ed8n@googlegroups.com>
In-Reply-To: <4iW61M7NCP-gPHoQZKi8ZrSa2U6oSjziG5JbZt3HKC_Ook_Nwm1PchKguOXZ235xaDlhg35nY8Zn7g1siy3IADHvSHyCcgTHrJorMKcDzZg=@protonmail.com>
References: <CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w@mail.gmail.com>
<4iW61M7NCP-gPHoQZKi8ZrSa2U6oSjziG5JbZt3HKC_Ook_Nwm1PchKguOXZ235xaDlhg35nY8Zn7g1siy3IADHvSHyCcgTHrJorMKcDzZg=@protonmail.com>
Subject: Re: [bitcoindev] The case for privatizing Bitcoin Core
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_289410_1241276853.1749966110180"
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_289410_1241276853.1749966110180
Content-Type: multipart/alternative;
boundary="----=_Part_289411_1609005054.1749966110180"
------=_Part_289411_1609005054.1749966110180
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Kanzure and others,
Thanks for your thoughts on this subject.
(...I initially swear to myself to not comment on this thread,
though after seeing Poinsot mentioning my GH comment, I think
I have to answer, a bit at least. So doing it with a real effort
of goodwill and courtesy).
> voluntary non-coercive arrangement (kanzure)
That's where there is a glitch, because somehow it all depends
how you define coercion, i.e the axiom of non-coercion (rothbard)
or the monopoly of the means of production (marx) ? Among many
political traditions...A short look on the history of the last
one hundred and fifty years says that "coercion" is far from
being a non-equivocal concept.
Moreover, I think it's very single sided when you're saying that
the crowd of bitcoin core users and other adjacent stakeholders.
shouldn't estimate itself entitled on the backs of developers.
Let's remember that a subset of those same developers were I
think really relieved to call to public charity when the CSW
lawsuits did happen. The bdlf did accept external donations
for a while, and you have also people like Paul Storcz who said
to have contributed to the legal defense of the devs. I don't
think he was the only one.
Though it's also forgetting the numerous low-key contributors
who might have contributed to bitcoin core quid a small review,
a testing of the release binaries, help for the lang translations,
improving rpc documentations, etc. Those low-key contributors
without names who were celebrated in the past by one of the
bitcoin optech newsletter [0]
[0] https://bitcoinops.org/en/newsletters/2021/12/22/
And I'm not going to mention that some grant-giving
organizations have been accepting bitcoin donations to
fund their own devs program [1]. How can they be sure that
the people who are vocablly asking for some code change
are not the same who are anonymously donating ? It's not
an easy problem...
[1] https://btcpay0.voltageapp.io/i/Cpb3V6SQsd131ib6U5GHrU/BTC-CHAIN
We're all suffering from the bias that our contribution, be it code,
catching sec flaw, providing financial ressources or operational support,
giving time as a forum / ml moderator or onboarding newbies at your
local meetup is the most significative one...
> There is a secondary issue that in a world of consensus compatible
> forks Core really shouldn't make maintaining those consensus compatible
> forks unnecessarily difficult or impossible (michaelfolkson).
Libbitcoinkernel is out there and it's usable. It might be a high
technical bar, though it slashes the engineering cost of developing
a consensus-compatible full-node by order of magnitude clearly.
I would give it's a rough cost of $2-5M in engineering time to develop
a full-node from libbitcoinkernel. This might sounds huge, though if
you're familiar with the development cost of specialized OSes in the
areonautics or banking field, it's similar. The Blockstream of the
day can be critized in medias, though they're clearly burning money
in the dev process.
At some point, I do understand a lot of the bitcoin core contributors
who are exceeded by the bridaging on social networks (...though no
one force you to be on twitter and you can still have a career in
the space I'm just saying...) or eventually systematic shitposting
on their pull requests.
> If transparency is important to Bitcoin=E2=80=99s social contract, then w=
e
> should talk about what it actually entails, how it's balanced against
> resilience, and where it begins and ends. Developers already meet
> significant transparency obligations: reproducible builds, tagged
> releases, and open review processes. That=E2=80=99s not nothing. (Christo=
pherA)
I'm generally agreeing with a lot of the ideas presented by ChristopherA,
and I've advocated over the last weeks that it could be very valuable
to move bitcoin core on nostr (or experiment with radicle). This would be
along the lines of what has been proposed in the past by a former=20
maintainer [2]
[2] https://laanwj.github.io/2021/01/21/decentralize.html
> I agree with your problem statement. I believe there is a dangerous=20
perception
> that the Bitcoin Core Github repository somehow controls Bitcoin and is=
=20
worthy=20
> of political pressure. And this is not only the case of the filter=20
enjoyers,=20
> this misperception is also used for example to justify legal threats[^0]=
=20
against developers
(poinsot)
Okay that one I have to clarify. I did my first commit in core in 2018 and
more in 2019, i.e before that any of the current maintainers have been=20
nominated
(the people with a key in contrib/verify-commits/trusted-keys). While=20
moderation
was always a thing for spam and in the pathological case like for Gavin=20
kick-out,
it was never said that a subset of contributors can arbitrarly change the=
=20
moderation
rules at invitation-only meetings (in the `CONTRIBUTING.md` of the time).=
=20
And when
I ACKed some maintainers for this janitorial role it was never to grant=20
them the
permission to moderate my posts _arbitrarly_.
I'm still thinking that the way moderation was established last year was in=
=20
disrespect
of the hundreds of contributors that have poured their works in the git=20
tree along
the years and who are still active (even if it's monthly or twice a year,=
=20
some episodic
contributions can be always of high-quality), but not present at the=20
meeting for a reason
or other.
In my view, the constrain of logistics in the impossibility of inviting=20
hundrefs
of people to a physical location at the same time is not a good reason to=
=20
banalize
unilateral change to the development process. Especially, when the emphasis=
=20
of said
dev process culture is put on "decentealization" and at every CoreDev it is=
=20
reminded
that "we're not a decision-making body".
This situation is all so clear that when I opened a pull request saying=20
that bitcoin
core code might be an unintentional and accidental joint authorship among=
=20
all the
code contributors, no one has been able to tell me clearly either why it=20
would be
or why it would be not, and the pull request for that is still opened...
So in the present state of things I'm confirming in public that I'm not=20
going
to pursue Alex and Suhas for that disagreement on moderations. No legal=20
actions
has been opened. And somehow this thread is the opportunity to point out=20
more verbosly
all the disagreement we have on moderation and "privatizing" or=20
"decentralizing"
bitcoin core or not.
That was to clarify by giving my version.
All of that said, I'll start to review again Poinsot's BIP54 proposal,=20
sometimes
a bit of goodwill in open-source it can have a lot of positive effects,=20
rather
than pointing an accusating finger towards each other.
Clearly the kind of situations when you have to show heightness of soul and
a bit of foresight...and "eviter de rajouter de l'huile sur le feu".
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
To conclude, I don't have a strong opinion on the privatization of bitcoin=
=20
core
or not in view of solving "social abuse". You're going to make things=20
better on
one dimensions to downgrade on others. There is no free lunch.
By personal philosophy, I'm always a bit skeptical of that kind of=20
"top-down"
approach, especial when it's asked to dozens of contributors spread in many=
=20
parts of the
worlds and with different professional culturue to all suddenly move in the=
=20
same
direction.=20
Said even less of the crowd of node operators, that might estimate
themselves "betrayed" by a diminution in the transparency of the dev=20
process.
Generally, successful open-source projects are organic, bottom-up process.
If you're a bitcoin contributor and you wish (unilaterally) to diminish the
"social attacks", you're free to quit twitter to favor more long-text mode
of communications. There are some historical contributors that have never=
=20
been
on twitter (e.g andytoshi, nullc or myself), and it has never been a=20
drawback
to make a career in the industry.
Long-text mode of communications generally calls to the reasoning abilities=
=20
of an audience.
With patience and a zest of stoicism,
Antoine
OTS hash: 6ba4a996fb99f397d2207317bbca8614d27895fbe9a2cb1e4fd74ccc2b8c7b09
Le samedi 14 juin 2025 =C3=A0 21:45:11 UTC+1, Antoine Poinsot a =C3=A9crit =
:
> Bryan,
>
> Thanks for your thoughts. It's always good to take a step back and reflec=
t=20
> on whether things are the way they are because it makes sense or because =
of=20
> inertia.
>
> I started reading by speculating you were defending the case for somethin=
g=20
> akin to a "source-available" Bitcoin Core. Where development would happen=
=20
> in private and source code would be made available at the same time as=20
> (reproducible) binary releases. I think there are a few major issues with=
=20
> this approach. Among them:
>
> - The now-private project would have to take on the burden of=20
> producing educational and historical content, which is currently outso=
urced=20
> to the wider technical community (for instance the optech newsletter o=
r=20
> simply searchable through Github);
> - It would increase the cost, in relation to the previous point, of=20
> "grassroot" onboarding to the project. I may be biased by my personal=
=20
> experience of starting by lurking at the development process for years=
and=20
> spending a long time as an=20
> active-contributor-but-not-full-time-project-member, but it seems to m=
e=20
> such a project structure would erect significant barriers to this appr=
oach=20
> and could make it almost necessary to go through one of the=20
> development organizations to onboard to the project;
> - In a similar but different vein, it would also make it less likely=
=20
> to get valuable contributions from people that "just show up" with no=
=20
> particular intention to start working full time on Bitcoin Core but ha=
d=20
> something that makes a lot of sense to share (whether it's code, repor=
ting=20
> an experience or even just a meaningful thought).
> =20
>
> However you are not making the case for this, but for a private Bitcoin=
=20
> Core repository with a public mirror. The public mirror would have commen=
t=20
> threads on pull requests originating from the private repository and the=
=20
> possibility to open issues. It would essentially enable developer to opt=
=20
> into engaging on public comment threads (for bug reports, contentious pul=
l=20
> requests if they see fit, etc..) while always having the possibility to=
=20
> retreat in the private repository to focus. This does sound more appealin=
g=20
> to me, although it raises question with regard to its feasibility and the=
=20
> churn it could introduce (could the public mirror insert public comments=
=20
> within the synced private thread? or would it have to duplicate every=20
> single thread?).
>
> You touch on the office culture and the need for a platform that would be=
=20
> a better sweet spot between unmoderated public discussions and entirely=
=20
> private discussions happening in the confines of a Bitcoin developer=20
> organization's offices. However it's unclear that what drives a lot of=20
> discussions to happen in offices is the occasional disruption of online=
=20
> fora, rather than just the natural advantages of in-person discussions.
>
> You also state that brigading would be severely reduced and eliminated.=
=20
> However it seems contrary to having publicly available comment threads? I=
t=20
> would just contain the brigading to the publicly available comment thread=
s.=20
> You could make the point that this containment would disincentivize the=
=20
> brigading in the first place, but it would only be the case if there is n=
o=20
> expectation that the low-quality comments be taken into account in the=20
> decision making. And removing this expectation does not require such an=
=20
> involved project structure, which brings me to my last point.
>
> I agree with your problem statement. I believe there is a dangerous=20
> perception that the Bitcoin Core Github repository somehow controls Bitco=
in=20
> and is worthy of political pressure. And this is not only the case of the=
=20
> filter enjoyers, this misperception is also used for example to justify=
=20
> legal threats[^0] against developers. It is important to push back agains=
t=20
> this confusion, but it seems achievable with a lot less disruption than b=
y=20
> changing the project structure. We just need to face the fact that Bitcoi=
n=20
> Core is a centralized project. It has a central website, releases binarie=
s=20
> and updates its software based on rough technical consensus. Bitcoin is=
=20
> decentralized, Bitcoin Core is not. Setting expectations that misinformed=
=20
> rants and conspiracy theories will be considered at all in deciding wheth=
er=20
> code should be changed is entirely self-inflicted and does not need a=20
> change in the project structure to correct. It does however require Bitco=
in=20
> Core contributors to act collectively, which is notoriously difficult to=
=20
> achieve, for better (in the case of pressure to merge contentious consens=
us=20
> changes for instance) or for worse (here).
>
> In conclusion, i don't think yours is a bad idea. If the Bitcoin Core=20
> project was set up this way today i think it would be fine. I just see th=
e=20
> current project structure as equally fine and unnecessary to change, as=
=20
> what is really needed to mitigate the social attacks is to just stop=20
> tolerating them.
>
> Best,
> Antoine Poinsot
>
> [^0]: It was the case with Craig Wright, but also more recently:=20
> https://github.com/bitcoin-core/meta/issues/19#issuecomment-2843664280
> On Tuesday, June 10th, 2025 at 4:40 PM, Bryan Bishop <kan...@gmail.com>=
=20
> wrote:
>
> The case for privatizing Bitcoin Core:
>
> I believe that reflection is critical for curiosity, understanding,=20
> improvement, and progress. And recent activity on the Bitcoin Core github=
=20
> account has given me an opportunity to re-evaluate my beliefs about=20
> open-source software development on GitHub.
>
>
> # The ongoing problem
>
> What happened was nothing new. It has happened before and it will happen=
=20
> again, especially if we do nothing new or different. Essentially there is=
a=20
> recurring pattern of non-contributors (sometimes even non-developers)=20
> intruding into an online forum intended mainly for people collaborating o=
n=20
> Bitcoin Core to work together on whatever they are working on. This often=
=20
> causes issues like wasting people's valuable time, creating manufactured=
=20
> controversy, misinformation, etc. It is trivial to see how exposure to de=
ep=20
> technical content can cause confusion or misunderstanding for non-technic=
al=20
> people who may not even know the ethos of open-source development or what=
=20
> bitcoin developers really do or believe about what they do. Unsolicited=
=20
> feedback from random/new people and even noise can sometimes be useful an=
d=20
> thankfully it's impossible to eliminate online forums for providing that,=
=20
> but here I'm specifically focusing on areas intended for dev collaboratio=
n.
>
> What we want as developers is to collaborate with whoever we wish on=20
> whatever our hearts desire, and we can freely do that over the Internet o=
r=20
> in person on any project we see fit. Many of us choose to work on Bitcoin=
.=20
> Some of us choose to work on Bitcoin Core. It is an entirely voluntary=20
> effort and nobody owes any obligation to anyone else but to themselves.=
=20
> Indeed, even non-developer bitcoiners are not obligated, like they are no=
t=20
> obligated to run code written by people they find disagreeable if for som=
e=20
> reason they cannot find sufficient reason to not run code in the code=20
> itself.
>
> You can argue there might be ethical or moral obligations created by=20
> working on open-source software, beyond those created by the license, but=
I=20
> don't buy that argument. There are no additional explicit obligations=20
> beyond the license. I'll add, though, that many developers have their own=
=20
> moral values and beliefs about how they should act and behave, and how th=
at=20
> informs who they choose to collaborate with, which is great! Many believe=
=20
> they have a personal moral value of informing uneducated people, or=20
> protecting people from security threats, or hundreds of other particular=
=20
> preferences and opinions. All of these are fantastic and I am glad these=
=20
> preferences or beliefs exist... but they cannot be coercively applied and=
=20
> we should not allow the bitcoin project, or Bitcoin Core, or github, to b=
e=20
> a platform for inflicting coercive beliefs upon developers that have gift=
ed=20
> us so much time, energy and efforts on a historically and systemically=20
> critical development.
>
> Therefore, I think there might be an opportunity here to re-evaluate the=
=20
> nature of open-source software development. I think there is an opportuni=
ty=20
> to re-evaluate how we choose to work together. What if there was a better=
=20
> way to collaborate on the work we do for bitcoin? What would it look like=
?=20
> What would be different? What would be kept the same?
>
>
> # GitHub
>
> Unfortunately the situation is that GitHub does not have good moderation=
=20
> controls and was only built for a very narrow concept of open source=20
> development. The solution to brigading is better controls around the=20
> presentation layer or requiring some sort of membership. If you just have=
a=20
> perpetual open door policy straight from reddit into your developer den,=
=20
> then yeah people are going to walk in and take a shit on your desk where=
=20
> you were working with another dev.. With some thinking I'm sure we can=20
> structure better ways to get exposure to general public sentiment or=20
> opinion, while also structuring a space for development to take place tha=
t=20
> does not require blindly mixing off-topic content with developer content.
>
>
> # Privatization
>
> Here, I would like to make the case for privatizing Bitcoin Core software=
=20
> development into a members-only gitlab or other kind of open-source=20
> software collaboration system. It would have the following properties.=20
> Issues and pull requests would be private and not subject to public=20
> hyperlinking. Anyone can register or apply for access. Whoever runs the=
=20
> site/repository would be responsible for configuration, hosting, setup,=
=20
> moderation, access control, etc. Software development would continue unde=
r=20
> the same license. New issues, comments, code review comments would possib=
ly=20
> be licensed under a specific license like CC0 or public domain or some=20
> other license, possibly with PGP-signature to track agreement if we care=
=20
> about comments licensing. Pull requests can be cross-posted to any number=
=20
> of repositories either public or private as much as any contributor wishe=
s,=20
> except to the point where any norm violation or spam violation occurs for=
=20
> the respective publishing systems of course.
>
>
> # Office culture
>
> An alternative to what I am proposing is already happening: development=
=20
> inside closed offices (Chaincode, Brink, Localhost, etc), which is less=
=20
> accessible and less open than a invite-only developer collab site. And al=
so=20
> less "open development" than the current Bitcoin Core GitHub project. So =
a=20
> failure to sort out these issues with Bitcoin Core collaboration can and=
=20
> has already produced solutions that are functionally less inclusive than =
an=20
> online member-only source forge. It is to the detriment of the open proje=
ct=20
> that so much gets discussed inside these private offices and many of us a=
re=20
> not able to contribute that way, and there ought to be something between =
a=20
> public github that the general public can brigade and closed offices on t=
he=20
> other end of the spectrum.
>
>
> # How it would work
>
> Contributors would be free to collaborate on any branch, pull request, or=
=20
> privatized fork, or even public fork. Issues, issue comments, pull reques=
t=20
> comments, code review comments, and miscellaneous discussions can also be=
=20
> posted internally. Code can come from inside the members-only repository,=
=20
> or it can be contributed from outside sources if someone pulls it in,=20
> proposes it, or otherwise posts those patches.
>
> Releases can be cut and source code published all at once, if that is=20
> desirable to anyone. However, I suspect that for Bitcoin Core, contributo=
rs=20
> would likely push changes out to various public access githubs or other=
=20
> locations on an hourly, daily or regular basis. Bitcoin Core, as it exist=
s=20
> today, could do the same for pull requests, code review comments, etc, an=
d=20
> post them publicly on a website. Anyone would be free to make a website=
=20
> where any person, including non-developers and including non-contributors=
,=20
> could freely post code review or comments. This could even happen on the=
=20
> current GH bitcoin/bitcoin repository. For example, any of the private co=
de=20
> review comments can be posted directly into the PR on GH. PGP signatures=
=20
> can be used for verifiable comment attribution. Or another website can be=
=20
> linked from a GH PR to display the private-originated review history.
>
> Brigading will be severely reduced and eliminated. You can pass around a=
=20
> link to the repository and a comment or issue but nobody will be able to=
=20
> see the content unless they are a registered member, which the vast=20
> majority of all internet people won't be. This will severely curtail=20
> brigading and spam while also enabling continued ongoing development=20
> activities for collaborators.
>
> Bitcoin Core itself has releases and maintainers that push the release=20
> button. I fully believe that even after privatizing Bitcoin Core that the=
y=20
> still will behave using the same norms and beliefs and systems that they=
=20
> presently do. Public code review will still continue. Public releases wil=
l=20
> still happen. There will still be open source code. But the ability of=20
> attackers to steal attention or time from bitcoin developers will be=20
> severely reduced. Likewise for attackers ability to coerce bitcoin=20
> developers through public spectacle where they do their core work. I=20
> believe that the community would be more productive and more energized if=
=20
> we regularly used a privatized collaboration platform.
>
> In practice, the way that this would roll out is that the GitHub would=20
> continue to be the GitHub and would not really change. There would be a=
=20
> separate private area for some developers to work together. Then they wou=
ld=20
> throw it over the wall or have some sort of (possibly real-time)=20
> synchronization protocol to synchronize pull requests to the public GitHu=
b=20
> repository. If you want a public link on X.com then link to that, but a=
=20
> link to the membership-required site won't work for non-members.
>
> For the private work space: I think registration, coupled with a delay,=
=20
> coupled with a probationary period would probably be sufficient. Possibly=
=20
> also with review or, what could be interesting as if at least two people=
=20
> out of any of the members have to recommend the user for entry. Or, you c=
an=20
> do proof-of-work to get entry and post something, and it's subject to=20
> moderator review until 2-of-n approve your membership? I would advocate f=
or=20
> very strong norms as to moderation and rules of engagement such as, if yo=
u=20
> just show up to cause chaos then you lose your access to the members-only=
=20
> place and you will have to post code somewhere else on the internet. It=
=20
> won't be that anyone can show up and cause chaos and never be silenced or=
=20
> banned.
>
> Adoption: would not be too difficult, as only two or three developers can=
=20
> privately experience some benefits. They can also use private one-time=20
> expiring links to temporarily include non-members as they see fit.
>
>
> # Theory crafting
>
> Non-technical activist movements have a history of making open discussion=
=20
> forums non-viable. Those same non-technical activist movements also have =
a=20
> history of making many non-viable forks, due to for example a lack of=20
> technical expertise in said movements. I would like to find ways to=20
> redirect efforts that would manifest as unusable discussion forums,=20
> instead, towards the creation of more non-viable forks.
>
> We can remain committed to making forking as frictionless as we can, whil=
e=20
> also increasing the friction of participation of non-technical actors in=
=20
> members-only technical discussion forums. The existence of members-only=
=20
> technical discussion forums does not preclude the existence of public=20
> channels, nor does it prohibit the flow of information in either directio=
n.=20
> It merely carves out a specific space and area.
>
> Something along the lines of: "We are willing to commit to your freedom t=
o=20
> create and run software of your choosing. We are not committed to=20
> internalizing often coercive demands that *we* be the ones to create the=
=20
> exact software of your choosing. We hope that you like the software we wo=
rk=20
> on, and we welcome your feedback in the right time and place, just not in=
=20
> private developer spaces."
>
> Open source software has a lot of history behind it and established=20
> developer culture norms. Open here usually refers to the source code=20
> licensing (see early 90s work from Foresight Institute's Christine=20
> Peterson's Open Source Definition initiative). "Open" development does no=
t=20
> mean "open to coercion". It feels very weird to write an email that=20
> essentially amounts to reminding grown adults that they can freely=20
> collaborate in any way they wish, and that they do not have to invite or=
=20
> subject themselves to active ongoing attempts of coercion. Even if it's=
=20
> from "the public". There are free-for-all places all over the Internet to=
=20
> post that kind of content, or to read it and review it. There are also=20
> other possibilities for structured access and presentation of that kind o=
f=20
> data. For example, a reverse Bitcoin Optech that curates that sort of=20
> information from around the web. I suspect that over time what has happen=
ed=20
> is that of the people who refuse to be subjected to coercion attempts fro=
m=20
> internet mobs have simply left the public collaboration process to either=
=20
> retreat into office in-person settings or stop contributing to bitcoin=20
> development entirely...
>
> Also, it does not feel good to ban people or clean up brigades to restore=
=20
> structure or order etc. which is partly why some core contributors have=
=20
> been so hesitant to hit the GH moderation buttons more often, plus many o=
f=20
> us just wanna code or build cool stuff. It's a partner to free speech..=
=20
> your free speech means that you don't have to say things you don't agree=
=20
> with, including platforming people who disagree with you or hate you=20
> outright. "Coercive platforming" happens when others demand you platform=
=20
> their speech content even if it's off-topic or low signal or actively=20
> directly hostile to you. Meanwhile dev attention is scarce and while it's=
=20
> individually regulated (as it should be), care should be taken to monitor=
=20
> if the obvious default regulation is for developers to simply disengage o=
r=20
> not engage at all, which would be a detriment to the bitcoin project.=20
> Instead we can filter the noise going into the system at the top of the=
=20
> funnel instead of the bottom (comments level).
>
> One goal is that we are interested in having more developers join and=20
> collaborate on Bitcoin Core. Creating an environment conducive to new=20
> developers is important and if they have to also be subjected to a bunch =
of=20
> noise just to collaborate on code on GitHub then I think that is=20
> sub-optimal and a self-defeating strategy if one of the goals is growth i=
n=20
> the number of developers or contributors.
>
> What I think people might be upset about this idea to privatize is that,=
=20
> to the extent that people perceive that they are currently able to coerce=
=20
> developers to work on specific things any given developer wouldn't have=
=20
> worked on otherwise, and if any developer collaborations voluntarily=20
> retreat to their own private work area, then I think those same people=20
> might get upset to the extent they perceive or feel that they are losing =
a=20
> coercive lever over developers that they previously thought they had=20
> (perhaps permanent) power over. In reality, it has always been a voluntar=
y=20
> non-coercive arrangement, it's just that people get confused about the=20
> social dynamics and forget this isn't feudalism slave labor era anymore.
>
>
>
> # End of remarks
>
> Building this sort of protection measure is important for the ongoing and=
=20
> future success of the project. As a moderator in the bitcoin-dev project =
it=20
> is hard for me to communicate the levels of attacks that we have seen and=
=20
> that I expect to see going forward. We are talking about a trillion dolla=
r=20
> system. We are talking about disrupting tens of trillions of dollars of=
=20
> value. And there are massive adversarial forces, including nation state a=
nd=20
> non-state actors with tremendously deep resources, that are completely=20
> adverse to what we stand for and what we believe and what bitcoin is or=
=20
> what bitcoin will become. These sorts of threats are completely unlike an=
y=20
> other open source software project has ever seen, and if anything I am=20
> underestimating what we are up against. This isn't to say to throw out ou=
r=20
> values and enact bitcoin governance or whatever; instead it's an=20
> opportunity to look at what tools we have at our disposal to counter thes=
e=20
> threats and ensure our continued productivity and that our open community=
=20
> can remain open without also cutting ourselves off.
>
>
>
>
> Humbly my own,
>
> Bryan Bishop aka kanzure
>
> June 2025
>
>
>
> https://www.lesswrong.com/posts/tscc3e5eujrsEeFN4/well-kept-gardens-die-b=
y-pacifism
> https://meaningness.com/geeks-mops-sociopaths
> https://github.com/bitcoin-core/meta/issues/19
> https://x.com/kanzure/status/1932534820607045947
>
> P.S. I still think bitcoin-core/meta on GH should be deleted. It's=20
> relatively recent and nothing of value will be lost that cannot be=20
> re-hosted should it ever prove necessary to do so.
>
> --=20
> You received this message because you are subscribed to the Google Groups=
=20
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
=20
> email to bitcoindev+...@googlegroups.com.
> To view this discussion visit=20
> https://groups.google.com/d/msgid/bitcoindev/CABaSBax-meEsC2013zKYJnC3phF=
FB_W3cHQLroUJcPDZKsjB8w%40mail.gmail.com
> .
>
>
--=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 visit https://groups.google.com/d/msgid/bitcoindev/=
03dff9ee-5a2f-41d8-93b4-fa6e53109ed8n%40googlegroups.com.
------=_Part_289411_1609005054.1749966110180
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Kanzure and others,<br /><br />Thanks for your thoughts on this subject.=
<br /><br />(...I initially swear to myself to not comment on this thread,<=
br />though after seeing Poinsot mentioning my GH comment, I think<br />I h=
ave to answer, a bit at least. So doing it with a real effort<br />of goodw=
ill and courtesy).<br /><br />> voluntary non-coercive arrangement (kanz=
ure)<br /><br />That's where there is a glitch, because somehow it all depe=
nds<br />how you define coercion, i.e the axiom of non-coercion (rothbard)<=
br />or the monopoly of the means of production (marx) ? Among many<br />po=
litical traditions...A short look on the history of the last<br />one hundr=
ed and fifty years says that "coercion" is far from<br />being a non-equivo=
cal concept.<br /><br />Moreover, I think it's very single sided when you'r=
e saying that<br />the crowd of bitcoin core users and other adjacent stake=
holders.<br />shouldn't estimate itself entitled on the backs of developers=
.<br /><br />Let's remember that a subset of those same developers were I<b=
r />think really relieved to call to public charity when the CSW<br />lawsu=
its did happen. The bdlf did accept external donations<br />for a while, an=
d you have also people like Paul Storcz who said<br />to have contributed t=
o the legal defense of the devs. I don't<br />think he was the only one.<br=
/><br />Though it's also forgetting the numerous low-key contributors<br /=
>who might have contributed to bitcoin core quid a small review,<br />a tes=
ting of the release binaries, help for the lang translations,<br />improvin=
g rpc documentations, etc. Those low-key contributors<br />without names wh=
o were celebrated in the past by one of the<br />bitcoin optech newsletter =
[0]<br /><br />[0] https://bitcoinops.org/en/newsletters/2021/12/22/<br /><=
br />And I'm not going to mention that some grant-giving<br />organizations=
have been accepting bitcoin donations to<br />fund their own devs program =
[1]. How can they be sure that<br />the people who are vocablly asking for =
some code change<br />are not the same who are anonymously donating ? It's =
not<br />an easy problem...<br /><br />[1] https://btcpay0.voltageapp.io/i/=
Cpb3V6SQsd131ib6U5GHrU/BTC-CHAIN<br /><br />We're all suffering from the bi=
as that our contribution, be it code,<br />catching sec flaw, providing fin=
ancial ressources or operational support,<br />giving time as a forum / ml =
moderator or onboarding newbies at your<br />local meetup is the most signi=
ficative one...<br /><br />> There is a secondary issue that in a world =
of consensus compatible<br />> forks Core really shouldn't make maintain=
ing those consensus compatible<br />> forks unnecessarily difficult or i=
mpossible (michaelfolkson).<br /><br />Libbitcoinkernel is out there and it=
's usable. It might be a high<br />technical bar, though it slashes the eng=
ineering cost of developing<br />a consensus-compatible full-node by order =
of magnitude clearly.<br /><br />I would give it's a rough cost of $2-5M in=
engineering time to develop<br />a full-node from libbitcoinkernel. This m=
ight sounds huge, though if<br />you're familiar with the development cost =
of specialized OSes in the<br />areonautics or banking field, it's similar.=
The Blockstream of the<br />day can be critized in medias, though they're =
clearly burning money<br />in the dev process.<br /><br />At some point, I =
do understand a lot of the bitcoin core contributors<br />who are exceeded =
by the bridaging on social networks (...though no<br />one force you to be =
on twitter and you can still have a career in<br />the space I'm just sayin=
g...) or eventually systematic shitposting<br />on their pull requests.<br =
/><br />> If transparency is important to Bitcoin=E2=80=99s social contr=
act, then we<br />> should talk about what it actually entails, how it's=
balanced against<br />> resilience, and where it begins and ends. Devel=
opers already meet<br />> significant transparency obligations: reproduc=
ible builds, tagged<br />> releases, and open review processes. That=E2=
=80=99s not nothing. (ChristopherA)<br /><br />I'm generally agreeing with =
a lot of the ideas presented by ChristopherA,<br />and I've advocated over =
the last weeks that it could be very valuable<br />to move bitcoin core on =
nostr (or experiment with radicle). This would be<br />along the lines of w=
hat has been proposed in the past by a former maintainer [2]<br /><br />[2]=
https://laanwj.github.io/2021/01/21/decentralize.html<br /><br />> I ag=
ree with your problem statement. I believe there is a dangerous perception<=
br />> that the Bitcoin Core Github repository somehow controls Bitcoin =
and is worthy <br />> of political pressure. And this is not only the ca=
se of the filter enjoyers, <br />> this misperception is also used for e=
xample to justify legal threats[^0] against developers<br />(poinsot)<br />=
<br />Okay that one I have to clarify. I did my first commit in core in 201=
8 and<br />more in 2019, i.e before that any of the current maintainers hav=
e been nominated<br />(the people with a key in contrib/verify-commits/trus=
ted-keys). While moderation<br />was always a thing for spam and in the pat=
hological case like for Gavin kick-out,<br />it was never said that a subse=
t of contributors can arbitrarly change the moderation<br />rules at invita=
tion-only meetings (in the `CONTRIBUTING.md` of the time). And when<br />I =
ACKed some maintainers for this janitorial role it was never to grant them =
the<br />permission to moderate my posts _arbitrarly_.<br /><br />I'm still=
thinking that the way moderation was established last year was in disrespe=
ct<br />of the hundreds of contributors that have poured their works in the=
git tree along<br />the years and who are still active (even if it's month=
ly or twice a year, some episodic<br />contributions can be always of high-=
quality), but not present at the meeting for a reason<br />or other.<br /><=
br />In my view, the constrain of logistics in the impossibility of invitin=
g hundrefs<br />of people to a physical location at the same time is not a =
good reason to banalize<br />unilateral change to the development process. =
Especially, when the emphasis of said<br />dev process culture is put on "d=
ecentealization" and at every CoreDev it is reminded<br />that "we're not a=
decision-making body".<br /><br />This situation is all so clear that when=
I opened a pull request saying that bitcoin<br />core code might be an uni=
ntentional and accidental joint authorship among all the<br />code contribu=
tors, no one has been able to tell me clearly either why it would be<br />o=
r why it would be not, and the pull request for that is still opened...<br =
/><br />So in the present state of things I'm confirming in public that I'm=
not going<br />to pursue Alex and Suhas for that disagreement on moderatio=
ns. No legal actions<br />has been opened. And somehow this thread is the o=
pportunity to point out more verbosly<br />all the disagreement we have on =
moderation and "privatizing" or "decentralizing"<br />bitcoin core or not.<=
br /><br />That was to clarify by giving my version.<br /><br />All of that=
said, I'll start to review again Poinsot's BIP54 proposal, sometimes<br />=
a bit of goodwill in open-source it can have a lot of positive effects, rat=
her<br />than pointing an accusating finger towards each other.<br /><br />=
Clearly the kind of situations when you have to show heightness of soul and=
<br />a bit of foresight...and "eviter de rajouter de l'huile sur le feu".<=
br /><br /><br />- - - - - - - - - - - - - - - - - - - - - - - - - - - - - =
- - - - - - - -<br /><br />To conclude, I don't have a strong opinion on th=
e privatization of bitcoin core<br />or not in view of solving "social abus=
e". You're going to make things better on<br />one dimensions to downgrade =
on others. There is no free lunch.<br /><br />By personal philosophy, I'm a=
lways a bit skeptical of that kind of "top-down"<br />approach, especial wh=
en it's asked to dozens of contributors spread in many parts of the<br />wo=
rlds and with different professional culturue to all suddenly move in the s=
ame<br />direction. <br /><br />Said even less of the crowd of node operato=
rs, that might estimate<br />themselves "betrayed" by a diminution in the t=
ransparency of the dev process.<br /><br />Generally, successful open-sourc=
e projects are organic, bottom-up process.<br /><br />If you're a bitcoin c=
ontributor and you wish (unilaterally) to diminish the<br />"social attacks=
", you're free to quit twitter to favor more long-text mode<br />of communi=
cations. There are some historical contributors that have never been<br />o=
n twitter (e.g andytoshi, nullc or myself), and it has never been a drawbac=
k<br />to make a career in the industry.<br /><br />Long-text mode of commu=
nications generally calls to the reasoning abilities of an audience.<br /><=
br />With patience and a zest of stoicism,<br />Antoine<br />OTS hash: 6ba4=
a996fb99f397d2207317bbca8614d27895fbe9a2cb1e4fd74ccc2b8c7b09<br /><br /><di=
v class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">Le samedi 14=
juin 2025 =C3=A0 21:45:11 UTC+1, Antoine Poinsot 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;"><div style=3D"font=
-family:Arial,sans-serif;font-size:14px">Bryan,</div><div style=3D"font-fam=
ily:Arial,sans-serif;font-size:14px"><br></div><div style=3D"font-family:Ar=
ial,sans-serif;font-size:14px">Thanks for your thoughts. It's always go=
od to take a step back and reflect on whether things are the way they are b=
ecause it makes sense or because of inertia.<br></div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px">
<div>
=20
</div>
=20
<div>
=20
</div>
</div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div s=
tyle=3D"font-family:Arial,sans-serif;font-size:14px">I started reading by s=
peculating you were defending the case for something akin to a "source=
-available" Bitcoin Core. Where development would happen in private an=
d source code would be made available at the same time as (reproducible) bi=
nary releases. I think there are a few major issues with this approach. Amo=
ng them:</div><div style=3D"font-family:Arial,sans-serif;font-size:14px"><u=
l style=3D"margin-top:0px;margin-bottom:0px"><li style=3D"list-style-type:&=
quot;- ""><span>The now-private project would have to take on the burd=
en of producing educational and historical content, which is currently outs=
ourced to the wider technical community (for instance the optech newsletter=
or simply searchable through Github);</span></li><li style=3D"list-style-t=
ype:"- ""><span>It would increase the cost, in relation to the pr=
evious point, of "grassroot" onboarding to the project. I may be =
biased by my personal experience of starting by lurking at the development =
process for years and spending a long time as an active-contributor-but-not=
-full-time-project-member, but it seems to me such a project structure woul=
d erect significant barriers to this approach and <span>could make it almos=
t necessary to go through one of the development organizations to onboard t=
o the project;</span></span></li><li style=3D"list-style-type:"- "=
;"><span><span>In a similar but different vein, it would also make it less =
likely to get valuable contributions from people that "just show up&qu=
ot; with no particular intention to start working full time on Bitcoin Core=
but had something that makes a lot of sense to share (whether it's cod=
e, reporting an experience or even just a meaningful thought).<br></span></=
span></li></ul><div><br></div><div>However you are not making the case for =
this, but for a private Bitcoin Core repository with a public mirror. The p=
ublic mirror would have comment threads on pull requests originating from t=
he private repository and the possibility to open issues. It would essentia=
lly enable developer to opt into engaging on public comment threads (for bu=
g reports, contentious pull requests if they see fit, etc..) while always h=
aving the possibility to retreat in the private repository to focus. This d=
oes sound more appealing to me, although it raises question with regard to =
its feasibility and the churn it could introduce (could the public mirror i=
nsert public comments within the synced private thread? or would it have to=
duplicate every single thread?).<br></div></div><div style=3D"font-family:=
Arial,sans-serif;font-size:14px"><br></div><div style=3D"font-family:Arial,=
sans-serif;font-size:14px">You touch on the office culture and the need for=
a platform that would be a better sweet spot between unmoderated public di=
scussions and entirely private discussions happening in the confines of a B=
itcoin developer organization's offices. However it's unclear that =
what drives a lot of discussions to happen in offices is the occasional dis=
ruption of online fora, rather than just the natural advantages of in-perso=
n discussions.</div><div style=3D"font-family:Arial,sans-serif;font-size:14=
px"><br></div><div style=3D"font-family:Arial,sans-serif;font-size:14px">Yo=
u also state that b<span>rigading would be severely reduced and eliminated<=
/span>. However it seems contrary to having publicly available comment thre=
ads? It would just contain the brigading to the publicly available comment =
threads. You could make the point that this containment would disincentiviz=
e the brigading in the first place, but it would only be the case if there =
is no expectation that the low-quality comments be taken into account in th=
e decision making. And removing this expectation does not require such an i=
nvolved project structure, which brings me to my last point.</div><div styl=
e=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div style=3D"f=
ont-family:Arial,sans-serif;font-size:14px">I agree with your problem state=
ment. I believe there is a dangerous perception that the Bitcoin Core Githu=
b repository somehow controls Bitcoin and is worthy of political pressure. =
And this is not only the case of the filter enjoyers, this misperception is=
also used for example to justify legal threats[^0] against developers. It =
is important to push back against this confusion, but it seems achievable w=
ith a lot less disruption than by changing the project structure. We just n=
eed to face the fact that Bitcoin Core is a centralized project. It has a c=
entral website, releases binaries and updates its software based on rough t=
echnical consensus. Bitcoin is decentralized, Bitcoin Core is not. Setting =
expectations that misinformed rants and conspiracy theories will be conside=
red at all in deciding whether code should be changed is entirely self-infl=
icted and does not need a change in the project structure to correct. It do=
es however require Bitcoin Core contributors to act collectively, which is =
notoriously difficult to achieve, for better (in the case of pressure to me=
rge contentious consensus changes for instance) or for worse (here).</div><=
div style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div st=
yle=3D"font-family:Arial,sans-serif;font-size:14px">In conclusion, i don=
9;t think yours is a bad idea. If the Bitcoin Core project was set up this =
way today i think it would be fine. I just see the current project structur=
e as equally fine and unnecessary to change, as what is really needed to mi=
tigate the social attacks is to just stop tolerating them.</div><div style=
=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div style=3D"fo=
nt-family:Arial,sans-serif;font-size:14px">Best,<br>Antoine Poinsot<br></di=
v><div style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div=
style=3D"font-family:Arial,sans-serif;font-size:14px">[^0]: It was the cas=
e with Craig Wright, but also more recently: <span><a rel=3D"noreferrer nof=
ollow noopener" href=3D"https://github.com/bitcoin-core/meta/issues/19#issu=
ecomment-2843664280" target=3D"_blank" data-saferedirecturl=3D"https://www.=
google.com/url?hl=3Dfr&q=3Dhttps://github.com/bitcoin-core/meta/issues/=
19%23issuecomment-2843664280&source=3Dgmail&ust=3D1750052422930000&=
amp;usg=3DAOvVaw1npfrvJlRH219Wx8Ta67aq">https://github.com/bitcoin-core/met=
a/issues/19#issuecomment-2843664280</a></span><br></div><div></div><div>
On Tuesday, June 10th, 2025 at 4:40 PM, Bryan Bishop <<a href da=
ta-email-masked rel=3D"nofollow">kan...@gmail.com</a>> wrote:<br>
</div><div><blockquote type=3D"cite">
<div dir=3D"ltr"><div>The case for privatizing Bitcoin Core:<br=
><br>I believe that reflection is critical for curiosity, understanding, im=
provement, and progress. And recent activity on the Bitcoin Core github acc=
ount has given me an opportunity to re-evaluate my beliefs about open-sourc=
e software development on GitHub.<br><br><br># The ongoing problem<br><br>W=
hat happened was nothing new. It has happened before and it will happen aga=
in, especially if we do nothing new or different. Essentially there is a re=
curring pattern of non-contributors (sometimes even non-developers) intrudi=
ng into an online forum intended mainly for people collaborating on Bitcoin=
Core to work together on whatever they are working on. This often causes i=
ssues like wasting people's valuable time, creating manufactured contro=
versy, misinformation, etc. It is trivial to see how exposure to deep techn=
ical content can cause confusion or misunderstanding for non-technical peop=
le who may not even know the ethos of open-source development or what bitco=
in developers really do or believe about what they do. Unsolicited feedback=
from random/new people and even noise can sometimes be useful and thankful=
ly it's impossible to eliminate online forums for providing that, but h=
ere I'm specifically focusing on areas intended for dev collaboration.<=
br><br>What we want as developers is to collaborate with whoever we wish on=
whatever our hearts desire, and we can freely do that over the Internet or=
in person on any project we see fit. Many of us choose to work on Bitcoin.=
Some of us choose to work on Bitcoin Core. It is an entirely voluntary eff=
ort and nobody owes any obligation to anyone else but to themselves. Indeed=
, even non-developer bitcoiners are not obligated, like they are not obliga=
ted to run code written by people they find disagreeable if for some reason=
they cannot find sufficient reason to not run code in the code itself.<br>=
<br>You can argue there might be ethical or moral obligations created by wo=
rking on open-source software, beyond those created by the license, but I d=
on't buy that argument. There are no additional explicit obligations be=
yond the license. I'll add, though, that many developers have their own=
moral values and beliefs about how they should act and behave, and how tha=
t informs who they choose to collaborate with, which is great! Many believe=
they have a personal moral value of informing uneducated people, or protec=
ting people from security threats, or hundreds of other particular preferen=
ces and opinions. All of these are fantastic and I am glad these preference=
s or beliefs exist... but they cannot be coercively applied and we should n=
ot allow the bitcoin project, or Bitcoin Core, or github, to be a platform =
for inflicting coercive beliefs upon developers that have gifted us so much=
time, energy and efforts on a historically and systemically critical devel=
opment.<br><br>Therefore, I think there might be an opportunity here to re-=
evaluate the nature of open-source software development. I think there is a=
n opportunity to re-evaluate how we choose to work together. What if there =
was a better way to collaborate on the work we do for bitcoin? What would i=
t look like? What would be different? What would be kept the same?<br><br><=
br># GitHub<br><br>Unfortunately the situation is that GitHub does not have=
good moderation controls and was only built for a very narrow concept of o=
pen source development. The solution to brigading is better controls around=
the presentation layer or requiring some sort of membership. If you just h=
ave a perpetual open door policy straight from reddit into your developer d=
en, then yeah people are going to walk in and take a shit on your desk wher=
e you were working with another dev.. With some thinking I'm sure we ca=
n structure better ways to get exposure to general public sentiment or opin=
ion, while also structuring a space for development to take place that does=
not require blindly mixing off-topic content with developer content.<br><b=
r><br># Privatization<br><br>Here, I would like to make the case for privat=
izing Bitcoin Core software development into a members-only gitlab or other=
kind of open-source software collaboration system. It would have the follo=
wing properties. Issues and pull requests would be private and not subject =
to public hyperlinking. Anyone can register or apply for access. Whoever ru=
ns the site/repository would be responsible for configuration, hosting, set=
up, moderation, access control, etc. Software development would continue un=
der the same license. New issues, comments, code review comments would poss=
ibly be licensed under a specific license like CC0 or public domain or some=
other license, possibly with PGP-signature to track agreement if we care a=
bout comments licensing. Pull requests can be cross-posted to any number of=
repositories either public or private as much as any contributor wishes, e=
xcept to the point where any norm violation or spam violation occurs for th=
e respective publishing systems of course.<br><br><br># Office culture<br><=
br>An alternative to what I am proposing is already happening: development =
inside closed offices (Chaincode, Brink, Localhost, etc), which is less acc=
essible and less open than a invite-only developer collab site. And also le=
ss "open development" than the current Bitcoin Core GitHub projec=
t. So a failure to sort out these issues with Bitcoin Core collaboration ca=
n and has already produced solutions that are functionally less inclusive t=
han an online member-only source forge. It is to the detriment of the open =
project that so much gets discussed inside these private offices and many o=
f us are not able to contribute that way, and there ought to be something b=
etween a public github that the general public can brigade and closed offic=
es on the other end of the spectrum.<br><br><br># How it would work<br><br>=
Contributors would be free to collaborate on any branch, pull request, or p=
rivatized fork, or even public fork. Issues, issue comments, pull request c=
omments, code review comments, and miscellaneous discussions can also be po=
sted internally. Code can come from inside the members-only repository, or =
it can be contributed from outside sources if someone pulls it in, proposes=
it, or otherwise posts those patches.<br><br>Releases can be cut and sourc=
e code published all at once, if that is desirable to anyone. However, I su=
spect that for Bitcoin Core, contributors would likely push changes out to =
various public access githubs or other locations on an hourly, daily or reg=
ular basis. Bitcoin Core, as it exists today, could do the same for pull re=
quests, code review comments, etc, and post them publicly on a website. Any=
one would be free to make a website where any person, including non-develop=
ers and including non-contributors, could freely post code review or commen=
ts. This could even happen on the current GH bitcoin/bitcoin repository. Fo=
r example, any of the private code review comments can be posted directly i=
nto the PR on GH. PGP signatures can be used for verifiable comment attribu=
tion. Or another website can be linked from a GH PR to display the private-=
originated review history.<br><br>Brigading will be severely reduced and el=
iminated. You can pass around a link to the repository and a comment or iss=
ue but nobody will be able to see the content unless they are a registered =
member, which the vast majority of all internet people won't be. This w=
ill severely curtail brigading and spam while also enabling continued ongoi=
ng development activities for collaborators.<br><br>Bitcoin Core itself has=
releases and maintainers that push the release button. I fully believe tha=
t even after privatizing Bitcoin Core that they still will behave using the=
same norms and beliefs and systems that they presently do. Public code rev=
iew will still continue. Public releases will still happen. There will stil=
l be open source code. But the ability of attackers to steal attention or t=
ime from bitcoin developers will be severely reduced. Likewise for attacker=
s ability to coerce bitcoin developers through public spectacle where they =
do their core work. I believe that the community would be more productive a=
nd more energized if we regularly used a privatized collaboration platform.=
<br><br>In practice, the way that this would roll out is that the GitHub wo=
uld continue to be the GitHub and would not really change. There would be a=
separate private area for some developers to work together. Then they woul=
d throw it over the wall or have some sort of (possibly real-time) synchron=
ization protocol to synchronize pull requests to the public GitHub reposito=
ry. If you want a public link on X.com then link to that, but a link to the=
membership-required site won't work for non-members.<br><br>For the pr=
ivate work space: I think registration, coupled with a delay, coupled with =
a probationary period would probably be sufficient. Possibly also with revi=
ew or, what could be interesting as if at least two people out of any of th=
e members have to recommend the user for entry. Or, you can do proof-of-wor=
k to get entry and post something, and it's subject to moderator review=
until 2-of-n approve your membership? I would advocate for very strong nor=
ms as to moderation and rules of engagement such as, if you just show up to=
cause chaos then you lose your access to the members-only place and you wi=
ll have to post code somewhere else on the internet. It won't be that a=
nyone can show up and cause chaos and never be silenced or banned.<br><br>A=
doption: would not be too difficult, as only two or three developers can pr=
ivately experience some benefits. They can also use private one-time expiri=
ng links to temporarily include non-members as they see fit.<br><br><br># T=
heory crafting<br><br>Non-technical activist movements have a history of ma=
king open discussion forums non-viable. Those same non-technical activist m=
ovements also have a history of making many non-viable forks, due to for ex=
ample a lack of technical expertise in said movements. I would like to find=
ways to redirect efforts that would manifest as unusable discussion forums=
, instead, towards the creation of more non-viable forks.<br><br>We can rem=
ain committed to making forking as frictionless as we can, while also incre=
asing the friction of participation of non-technical actors in members-only=
technical discussion forums. The existence of members-only technical discu=
ssion forums does not preclude the existence of public channels, nor does i=
t prohibit the flow of information in either direction. It merely carves ou=
t a specific space and area.<br><br>Something along the lines of: "We =
are willing to commit to your freedom to create and run software of your ch=
oosing. We are not committed to internalizing often coercive demands that *=
we* be the ones to create the exact software of your choosing. We hope that=
you like the software we work on, and we welcome your feedback in the righ=
t time and place, just not in private developer spaces."<br><br>Open s=
ource software has a lot of history behind it and established developer cul=
ture norms. Open here usually refers to the source code licensing (see earl=
y 90s work from Foresight Institute's Christine Peterson's Open Sou=
rce Definition initiative). "Open" development does not mean &quo=
t;open to coercion". It feels very weird to write an email that essent=
ially amounts to reminding grown adults that they can freely collaborate in=
any way they wish, and that they do not have to invite or subject themselv=
es to active ongoing attempts of coercion. Even if it's from "the =
public". There are free-for-all places all over the Internet to post t=
hat kind of content, or to read it and review it. There are also other poss=
ibilities for structured access and presentation of that kind of data. For =
example, a reverse Bitcoin Optech that curates that sort of information fro=
m around the web. I suspect that over time what has happened is that of the=
people who refuse to be subjected to coercion attempts from internet mobs =
have simply left the public collaboration process to either retreat into of=
fice in-person settings or stop contributing to bitcoin development entirel=
y...<br><br>Also, it does not feel good to ban people or clean up brigades =
to restore structure or order etc. which is partly why some core contributo=
rs have been so hesitant to hit the GH moderation buttons more often, plus =
many of us just wanna code or build cool stuff. It's a partner to free =
speech.. your free speech means that you don't have to say things you d=
on't agree with, including platforming people who disagree with you or =
hate you outright. "Coercive platforming" happens when others dem=
and you platform their speech content even if it's off-topic or low sig=
nal or actively directly hostile to you. Meanwhile dev attention is scarce =
and while it's individually regulated (as it should be), care should be=
taken to monitor if the obvious default regulation is for developers to si=
mply disengage or not engage at all, which would be a detriment to the bitc=
oin project. Instead we can filter the noise going into the system at the t=
op of the funnel instead of the bottom (comments level).<br><br>One goal is=
that we are interested in having more developers join and collaborate on B=
itcoin Core. Creating an environment conducive to new developers is importa=
nt and if they have to also be subjected to a bunch of noise just to collab=
orate on code on GitHub then I think that is sub-optimal and a self-defeati=
ng strategy if one of the goals is growth in the number of developers or co=
ntributors.<br><br>What I think people might be upset about this idea to pr=
ivatize is that, to the extent that people perceive that they are currently=
able to coerce developers to work on specific things any given developer w=
ouldn't have worked on otherwise, and if any developer collaborations v=
oluntarily retreat to their own private work area, then I think those same =
people might get upset to the extent they perceive or feel that they are lo=
sing a coercive lever over developers that they previously thought they had=
(perhaps permanent) power over. In reality, it has always been a voluntary=
non-coercive arrangement, it's just that people get confused about the=
social dynamics and forget this isn't feudalism slave labor era anymor=
e.<br><br><br><br># End of remarks<br><br>Building this sort of protection =
measure is important for the ongoing and future success of the project. As =
a moderator in the bitcoin-dev project it is hard for me to communicate the=
levels of attacks that we have seen and that I expect to see going forward=
. We are talking about a trillion dollar system. We are talking about disru=
pting tens of trillions of dollars of value. And there are massive adversar=
ial forces, including nation state and non-state actors with tremendously d=
eep resources, that are completely adverse to what we stand for and what we=
believe and what bitcoin is or what bitcoin will become. These sorts of th=
reats are completely unlike any other open source software project has ever=
seen, and if anything I am underestimating what we are up against. This is=
n't to say to throw out our values and enact bitcoin governance or what=
ever; instead it's an opportunity to look at what tools we have at our =
disposal to counter these threats and ensure our continued productivity and=
that our open community can remain open without also cutting ourselves off=
.<br><br></div><div><br></div><div><br><br>Humbly my own,<br><br>Bryan Bish=
op aka kanzure<br><br>June 2025<br><br><br><a href=3D"https://www.lesswrong=
.com/posts/tscc3e5eujrsEeFN4/well-kept-gardens-die-by-pacifism" rel=3D"nore=
ferrer nofollow noopener" target=3D"_blank" data-saferedirecturl=3D"https:/=
/www.google.com/url?hl=3Dfr&q=3Dhttps://www.lesswrong.com/posts/tscc3e5=
eujrsEeFN4/well-kept-gardens-die-by-pacifism&source=3Dgmail&ust=3D1=
750052422930000&usg=3DAOvVaw3u62sUp20WftTYCfKRbrbw">https://www.lesswro=
ng.com/posts/tscc3e5eujrsEeFN4/well-kept-gardens-die-by-pacifism</a><br><a =
href=3D"https://meaningness.com/geeks-mops-sociopaths" rel=3D"noreferrer no=
follow noopener" target=3D"_blank" data-saferedirecturl=3D"https://www.goog=
le.com/url?hl=3Dfr&q=3Dhttps://meaningness.com/geeks-mops-sociopaths&am=
p;source=3Dgmail&ust=3D1750052422930000&usg=3DAOvVaw1o-RGT1cEef7SzI=
N9Al-as">https://meaningness.com/geeks-mops-sociopaths</a><br><a href=3D"ht=
tps://github.com/bitcoin-core/meta/issues/19" rel=3D"noreferrer nofollow no=
opener" target=3D"_blank" data-saferedirecturl=3D"https://www.google.com/ur=
l?hl=3Dfr&q=3Dhttps://github.com/bitcoin-core/meta/issues/19&source=
=3Dgmail&ust=3D1750052422930000&usg=3DAOvVaw2CVWJRd6l2Nf1L2h6Rh5Tw"=
>https://github.com/bitcoin-core/meta/issues/19</a><br><a href=3D"https://x=
.com/kanzure/status/1932534820607045947" rel=3D"noreferrer nofollow noopene=
r" target=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?hl=
=3Dfr&q=3Dhttps://x.com/kanzure/status/1932534820607045947&source=
=3Dgmail&ust=3D1750052422930000&usg=3DAOvVaw2KPiezL5xE-62f_T_ksDgV"=
>https://x.com/kanzure/status/1932534820607045947</a><br><br>P.S. I still t=
hink bitcoin-core/meta on GH should be deleted. It's relatively recent =
and nothing of value will be lost that cannot be re-hosted should it ever p=
rove necessary to do so.<br></div><div><br></div><div data-smartmail=3D"gma=
il_signature" class=3D"gmail_signature" dir=3D"ltr"></div></div>
<p></p></blockquote></div><div><blockquote type=3D"cite">
-- <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 rel=3D"noreferrer nofollow noopener" data-email-masked>bitc=
oindev+...@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w%40mail.gmail=
.com" rel=3D"noreferrer nofollow noopener" target=3D"_blank" data-saferedir=
ecturl=3D"https://www.google.com/url?hl=3Dfr&q=3Dhttps://groups.google.=
com/d/msgid/bitcoindev/CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w%=
2540mail.gmail.com&source=3Dgmail&ust=3D1750052422930000&usg=3D=
AOvVaw3JU4Yl6WQSEhcyGnfIzMqi">https://groups.google.com/d/msgid/bitcoindev/=
CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w%40mail.gmail.com</a>.<b=
r>
</blockquote></div></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 visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/03dff9ee-5a2f-41d8-93b4-fa6e53109ed8n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/03dff9ee-5a2f-41d8-93b4-fa6e53109ed8n%40googlegroups.com</a>.<br />
------=_Part_289411_1609005054.1749966110180--
------=_Part_289410_1241276853.1749966110180--
|