path: root/8d/452d797fac67ab9e9273e1f5022b17a0fb0c0e

Delivery-date: Sat, 14 Jun 2025 13:45:20 -0700
Received: from mail-ot1-f55.google.com ([209.85.210.55])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDL4XL646QOBBVF6W7BAMGQE6MOEUYY@googlegroups.com>)
	id 1uQXkb-0006DW-PW
	for bitcoindev@gnusha.org; Sat, 14 Jun 2025 13:45:20 -0700
Received: by mail-ot1-f55.google.com with SMTP id 46e09a7af769-72ecb622e02sf1438186a34.0
        for <bitcoindev@gnusha.org>; Sat, 14 Jun 2025 13:45:17 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1749933912; cv=pass;
        d=google.com; s=arc-20240605;
        b=k4oOcPwZqEkv+BFkXJtW80CGeDaNREaxQusjz14D5EU3bUAKc8wz4nomwKuh/cExEa
         SROxFPhTD/QwA4YJx27kxILmXYJkUjJSezkCrt5PRdtkNzNy6PPB3bm137oNUh+VcxCr
         UZ4KrhmWbUfcfZqvh1n2M5l1Ra34TDmZVOyF3DI+UlT/MgDWuY7xtWLkjNkdplndOVIP
         LNgOqcUx1S8jiBht4PPKNyEO+MAHwXpVxgIpKWn80SCPOdOzRuOA79O2odWhlq3pPf2m
         gBSnUrp4tgdMizY0mVTRwsUNWWIu97RDcFVnMVmHf5brNxLcRAWPnoCAFU4Ci/PvaCZO
         Iy8Q==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id
         :references:in-reply-to:message-id:subject:cc:from:to:date
         :dkim-signature;
        bh=BwvEPxshbARvBD7VGd3PlXl68t7YwrRRJ1xG05izbwc=;
        fh=sZ8SJYsj5KtSPXkeO/xYV9SfGSMAO8DAXf5eyKEkA0U=;
        b=Df9g7vQnFt+OkX3Qx/ZY1e+5AgqhxtQGC7hDk+R7YTZDo9bhTHCBLQlawWMvyzvC95
         dV4mLMo4HsRvvAY/cXyNOeXS2HjxACM0c1QtBUw1W8kKJik7EOERFcHw7h9FQLV/KP8l
         v0xgXX1UqGe5a2aIZS4dzQhTVwVhUYwZziDM5LwEcZSpmIGzLqK5w6yY+y8Bwbi62Iou
         nZS/8VO35akZz7rxafNVACm14O45y+1Z/PDRmHPrFCeJ8d/Rs2I9po3c2G1VNI9oTndH
         adj/bsNK6omiLGrWlXZxQ9Yk5oxlLYKs5Wg1kpfN1Ti45TDCfh1pSp2G/SAw60ockNQQ
         T+vg==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=UQy+4kRG;
       spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1749933912; x=1750538712; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender:mime-version
         :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
         :date:from:to:cc:subject:date:message-id:reply-to;
        bh=BwvEPxshbARvBD7VGd3PlXl68t7YwrRRJ1xG05izbwc=;
        b=N7qXT4/CUazntdBbsGRe9cmYPV193Fdu1kKBOUUuL88IokGMIG93xMtzNnlnUy6+i5
         u4n7BB77G+EXoz8w72l1EXn8SNvQNylB8bG2v39LNOMhNpsPN5395FzN/vB0NFcSikco
         2n3EjsU9Or4TiWyjQB55C8awJm7QqYolhF4d/Pn2E8UPFll1P++j3rmY9EXEy1jbTa6H
         c2Ma5oU7c3vkw9B1RMmwdEHCbPK1CIHCXyvlo8IivW/bVrpOzCr8REedm7Mkn50+k2x1
         QbfmKSGm8WqgZP29B/Jd6vfvqHEZciudP41AjX52BrZhahD+kRGDrHkEIERn1Lx9WvkO
         neKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749933912; x=1750538712;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender:mime-version
         :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
         :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=BwvEPxshbARvBD7VGd3PlXl68t7YwrRRJ1xG05izbwc=;
        b=WpsCiGgS0og1UQrWhRK2ry052MSlJ7fnXRCr1sNg0Fg4QZmBu9sZilmtu5/6lpCf+N
         EIRUSE7wdQG+Tbn1+wfz2c8SLh1TY1kCERTCZNKyGOXtg6H/Fk2+gd6ryyCQIgfq95xA
         a8HE+q2AxOk/J+OZphIGpGpBPiW5sBFGlhtB2Qyzf+Yn+8JWyC8quN95K11D7Mt0Ikan
         uWwhCQdi96Waat4oEyq054q+lUn7lNsLIIr0W5UUT+XOdh0Af6id8gte97GNwOpyY4vl
         M/+DOoFerBRwEDpdc30NS0Y9nzI3/U+5OBzOX0Di/PDeHmx9NQUKG6mzshJ7vXjGXppy
         V09A==
X-Forwarded-Encrypted: i=2; AJvYcCUXDq3Tcm8rD6UgHkW31vetvTib1oV186su+1hnd/a82GCF+RZE1wIrmnLwsqUvoBkfIPXh4cIGkRk7@gnusha.org
X-Gm-Message-State: AOJu0Yw9yGJdDVQ40nAG70JLcGNbV65m/IAoPvOAl83pGyMEbyNbwxvz
	bHuCPomzW543IuM008wB8MNDfWlPo4rwtsZNmpuOJpiTnrlMPn76r2OE
X-Google-Smtp-Source: AGHT+IGHtFCkK+ZpEb6aww6ub7+R4gn/zDxcd5PTz70+np16wMh4GcYzEwMDpS5rxlWjX05wyc3fRw==
X-Received: by 2002:a05:6830:498d:b0:734:f5e2:8cbc with SMTP id 46e09a7af769-73a36332122mr2836267a34.18.1749933911738;
        Sat, 14 Jun 2025 13:45:11 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZekNHicEvx5PbgUmwpH43PU9iqeQOxhGwB3ZmkiDEcVKw==
Received: by 2002:a05:6820:6709:b0:60b:a53c:36af with SMTP id
 006d021491bc7-610fd353ed2ls697683eaf.2.-pod-prod-04-us; Sat, 14 Jun 2025
 13:45:07 -0700 (PDT)
X-Received: by 2002:a05:6808:6f87:b0:3f6:a476:f7d3 with SMTP id 5614622812f47-40a7c18c3aamr2765928b6e.9.1749933907846;
        Sat, 14 Jun 2025 13:45:07 -0700 (PDT)
Received: by 2002:a05:600c:a116:b0:442:dc76:9493 with SMTP id 5b1f17b1804b1-45334479db2ms5e9;
        Sat, 14 Jun 2025 11:29:39 -0700 (PDT)
X-Received: by 2002:a05:6000:2302:b0:3a4:f6ba:51da with SMTP id ffacd0b85a97d-3a5723711famr3642057f8f.15.1749925774473;
        Sat, 14 Jun 2025 11:29:34 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1749925774; cv=none;
        d=google.com; s=arc-20240605;
        b=V5Sw4PFD561B72Ul/SH1b0I/nk7dl9AoX+jf9svd4mqiAfxmWutUM50YiNE5B/XJCP
         5SI1bqvN8h5pyyCtE9gcIlOujAAdNSaHvgSmwDLUP6drEr/Kpgk1gUAQfKhwGThGKw72
         L8Pui+W2ErPgfeJueATL0tTcHgMPGsNJZH2umgBMtmbxHMVuWYioS4/HJfSHpRJ9PM2A
         Gmau6YN4PK+B/N41iKNDLSITRJu7PPkk2qy8AY/BPVbZZ/y0Y30+mV9I9vstxd835quB
         016J6anbE9yeKiG95ZQEAwmy7oaNLc4YK216H32hiiyWVHzkoFZ9crSPHq2dnUqegLIm
         6XXA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=mime-version:feedback-id:references:in-reply-to:message-id:subject
         :cc:from:to:date:dkim-signature;
        bh=gRQ+xXmqKRiaD1mpi9mi8lpsyqWdIPKP+C2yaB0L1kc=;
        fh=GrYwucciMhLORZt1fsQXZtg3Ji0QXL4X0nS/6kd273E=;
        b=ClBpozN0cyutf9r5lOhNYfFDLVMg6RC47KFtpEhXfMFYay+vA/wdA0nWnBX/6vFts9
         gIh3fGFpTBnOH82aGqxGMuck7ync4zk1Z+iucIIvPasBu8ImUp1FRvMynI+0XOUQkBRj
         UYi0dP5Z1Eu8m1LuStVyrQ+dhqSbiBbEeLeay7cfm/F04UhF3BO/A8FUs7pmt/R6Uv3X
         u1Jd71/ITqLzwJ5wmHNxfDWgYSKYPTZOShqkpk9veO2I04XsEid7kpu7WoOh59t8PBOI
         4KmA0F2YlpGz4DB4eSt7DSmYF7sH+h6BkoaLIRXF3UURptcUbj8SfV8Yi1miE4yQgm0U
         MsVg==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=UQy+4kRG;
       spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch. [185.70.43.22])
        by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-3a568ae18d3si74556f8f.5.2025.06.14.11.29.34
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Sat, 14 Jun 2025 11:29:34 -0700 (PDT)
Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) client-ip=185.70.43.22;
Date: Sat, 14 Jun 2025 18:29:26 +0000
To: Bryan Bishop <kanzure@gmail.com>
From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] The case for privatizing Bitcoin Core
Message-ID: <4iW61M7NCP-gPHoQZKi8ZrSa2U6oSjziG5JbZt3HKC_Ook_Nwm1PchKguOXZ235xaDlhg35nY8Zn7g1siy3IADHvSHyCcgTHrJorMKcDzZg=@protonmail.com>
In-Reply-To: <CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w@mail.gmail.com>
References: <CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w@mail.gmail.com>
Feedback-ID: 7060259:user:proton
X-Pm-Message-ID: 8771db6f70b9ce539c70035e804bc797a3715410
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="b1=_vUSNfO4MTt8ZXrFmfmBvQoOkgY4jDRPrjzG8CDHQ8Q"
X-Original-Sender: darosior@protonmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@protonmail.com header.s=protonmail3 header.b=UQy+4kRG;
       spf=pass (google.com: domain of darosior@protonmail.com designates
 185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
X-Original-From: Antoine Poinsot <darosior@protonmail.com>
Reply-To: Antoine Poinsot <darosior@protonmail.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: -1.0 (-)

--b1=_vUSNfO4MTt8ZXrFmfmBvQoOkgY4jDRPrjzG8CDHQ8Q
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Bryan,

Thanks for your thoughts. It's always good to take a step back and reflect =
on whether things are the way they are because it makes sense or because of=
 inertia.

I started reading by speculating you were defending the case for something =
akin to a "source-available" Bitcoin Core. Where development would happen i=
n private and source code would be made available at the same time as (repr=
oducible) binary releases. I think there are a few major issues with this a=
pproach. Among them:

- The now-private project would have to take on the burden of producing edu=
cational and historical content, which is currently outsourced to the wider=
 technical community (for instance the optech newsletter or simply searchab=
le through Github);
- It would increase the cost, in relation to the previous point, of "grassr=
oot" onboarding to the project. I may be biased by my personal experience o=
f starting by lurking at the development process for years and spending a l=
ong time as an active-contributor-but-not-full-time-project-member, but it =
seems to me such a project structure would erect significant barriers to th=
is approach and could make it almost necessary to go through one of the dev=
elopment organizations to onboard to the project;
- In a similar but different vein, it would also make it less likely to get=
 valuable contributions from people that "just show up" 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 code, reporting an experience =
or even just a meaningful thought).

However you are not making the case for this, but for a private Bitcoin Cor=
e repository with a public mirror. The public mirror would have comment thr=
eads on pull requests originating from the private repository and the possi=
bility to open issues. It would essentially enable developer to opt into en=
gaging on public comment threads (for bug reports, contentious pull request=
s if they see fit, etc..) while always having the possibility to retreat in=
 the private repository to focus. This does sound more appealing to me, alt=
hough it raises question with regard to its feasibility and the churn it co=
uld introduce (could the public mirror insert public comments within the sy=
nced private thread? or would it have to duplicate every single thread?).

You touch on the office culture and the need for a platform that would be a=
 better sweet spot between unmoderated public discussions and entirely priv=
ate discussions happening in the confines of a Bitcoin developer organizati=
on's offices. However it's unclear that what drives a lot of discussions to=
 happen in offices is the occasional disruption of online fora, rather than=
 just the natural advantages of in-person discussions.

You also state that brigading would be severely reduced and eliminated. How=
ever it seems contrary to having publicly available comment threads? It wou=
ld just contain the brigading to the publicly available comment threads. Yo=
u could make the point that this containment would disincentivize the briga=
ding in the first place, but it would only be the case if there is no expec=
tation that the low-quality comments be taken into account in the decision =
making. And removing this expectation does not require such an involved pro=
ject structure, which brings me to my last point.

I agree with your problem statement. I believe there is a dangerous percept=
ion that the Bitcoin Core Github 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 thre=
ats[^0] against developers. It is important to push back against this confu=
sion, but it seems achievable with a lot less disruption than by changing t=
he project structure. We just need to face the fact that Bitcoin Core is a =
centralized project. It has a central website, releases binaries and update=
s its software based on rough technical consensus. Bitcoin is decentralized=
, Bitcoin Core is not. Setting expectations that misinformed rants and cons=
piracy theories will be considered at all in deciding whether code should b=
e changed is entirely self-inflicted and does not need a change in the proj=
ect structure to correct. It does however require Bitcoin Core contributors=
 to act collectively, which is notoriously difficult to achieve, for better=
 (in the case of pressure to merge contentious consensus changes for instan=
ce) or for worse (here).

In conclusion, i don't think yours is a bad idea. If the Bitcoin Core proje=
ct was set up this way today i think it would be fine. I just see the curre=
nt project structure as equally fine and unnecessary to change, as what is =
really needed to mitigate the social attacks is to just stop tolerating the=
m.

Best,
Antoine Poinsot

[^0]: It was the case with Craig Wright, but also more recently: https://gi=
thub.com/bitcoin-core/meta/issues/19#issuecomment-2843664280
On Tuesday, June 10th, 2025 at 4:40 PM, Bryan Bishop <kanzure@gmail.com> wr=
ote:

> The case for privatizing Bitcoin Core:
>
> I believe that reflection is critical for curiosity, understanding, impro=
vement, and progress. And recent activity on the Bitcoin Core github accoun=
t has given me an opportunity to re-evaluate my beliefs about open-source s=
oftware development on GitHub.
>
> # The ongoing problem
>
> What happened was nothing new. It has happened before and it will happen =
again, especially if we do nothing new or different. Essentially there is a=
 recurring pattern of non-contributors (sometimes even non-developers) intr=
uding into an online forum intended mainly for people collaborating on Bitc=
oin Core to work together on whatever they are working on. This often cause=
s issues like wasting people's valuable time, creating manufactured controv=
ersy, misinformation, etc. It is trivial to see how exposure to deep techni=
cal content can cause confusion or misunderstanding for non-technical peopl=
e who may not even know the ethos of open-source development or what bitcoi=
n developers really do or believe about what they do. Unsolicited feedback =
from random/new people and even noise can sometimes be useful and thankfull=
y it's impossible to eliminate online forums for providing that, but here I=
'm specifically focusing on areas intended for dev collaboration.
>
> What we want as developers is to collaborate with whoever we wish on what=
ever our hearts desire, and we can freely do that over the Internet or in p=
erson 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 effort a=
nd nobody owes any obligation to anyone else but to themselves. Indeed, eve=
n non-developer bitcoiners are not obligated, like they are not obligated t=
o 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.
>
> You can argue there might be ethical or moral obligations created by work=
ing on open-source software, beyond those created by the license, but I don=
't buy that argument. There are no additional explicit obligations beyond t=
he license. I'll add, though, that many developers have their own moral val=
ues and beliefs about how they should act and behave, and how that informs =
who they choose to collaborate with, which is great! Many believe they have=
 a personal moral value of informing uneducated people, or protecting peopl=
e from security threats, or hundreds of other particular preferences and op=
inions. All of these are fantastic and I am glad these preferences or belie=
fs exist... but they cannot be coercively applied and we should not allow t=
he bitcoin project, or Bitcoin Core, or github, to be a platform for inflic=
ting coercive beliefs upon developers that have gifted us so much time, ene=
rgy and efforts on a historically and systemically critical development.
>
> Therefore, I think there might be an opportunity here to re-evaluate the =
nature of open-source software development. I think there is an 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 it look like? =
What would be different? What would be kept the same?
>
> # GitHub
>
> Unfortunately the situation is that GitHub does not have good moderation =
controls and was only built for a very narrow concept of open source develo=
pment. The solution to brigading is better controls around the presentation=
 layer or requiring some sort of membership. If you just have a perpetual o=
pen door policy straight from reddit into your developer den, then yeah peo=
ple are going to walk in and take a shit on your desk where you were workin=
g with another dev.. With some thinking I'm sure we can structure better wa=
ys to get exposure to general public sentiment or opinion, while also struc=
turing a space for development to take place that 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=
 development into a members-only gitlab or other kind of open-source softwa=
re collaboration system. It would have the following properties. Issues and=
 pull requests would be private and not subject to public hyperlinking. Any=
one can register or apply for access. Whoever runs the site/repository woul=
d be responsible for configuration, hosting, setup, moderation, access cont=
rol, etc. Software development would continue under the same license. New i=
ssues, comments, code review comments would possibly be licensed under a sp=
ecific license like CC0 or public domain or some other license, possibly wi=
th PGP-signature to track agreement if we care about comments licensing. Pu=
ll requests can be cross-posted to any number of repositories either public=
 or private as much as any contributor wishes, except to the point where an=
y norm violation or spam violation occurs for the respective publishing sys=
tems of course.
>
> # Office culture
>
> An alternative to what I am proposing is already happening: development i=
nside closed offices (Chaincode, Brink, Localhost, etc), which is less acce=
ssible and less open than a invite-only developer collab site. And also les=
s "open development" than the current Bitcoin Core GitHub project. So a fai=
lure to sort out these issues with Bitcoin Core collaboration can and has a=
lready produced solutions that are functionally less inclusive than an onli=
ne member-only source forge. It is to the detriment of the open project tha=
t so much gets discussed inside these private offices and many of us are no=
t able to contribute that way, and there ought to be something between a pu=
blic github that the general public can brigade and closed offices on the o=
ther end of the spectrum.
>
> # How it would work
>
> Contributors would be free to collaborate on any branch, pull request, or=
 privatized fork, or even public fork. Issues, issue comments, pull request=
 comments, code review comments, and miscellaneous discussions can also be =
posted internally. Code can come from inside the members-only repository, o=
r it can be contributed from outside sources if someone pulls it in, propos=
es it, or otherwise posts those patches.
>
> Releases can be cut and source code published all at once, if that is des=
irable to anyone. However, I suspect that for Bitcoin Core, contributors wo=
uld likely push changes out to various public access githubs or other locat=
ions on an hourly, daily or regular basis. Bitcoin Core, as it exists today=
, could do the same for pull requests, code review comments, etc, and post =
them publicly on a website. Anyone would be free to make a website where an=
y person, including non-developers and including non-contributors, could fr=
eely post code review or comments. This could even happen on the current GH=
 bitcoin/bitcoin repository. For example, any of the private code review co=
mments can be posted directly into the PR on GH. PGP signatures can be used=
 for verifiable comment attribution. Or another website can be linked from =
a GH PR to display the private-originated review history.
>
> Brigading will be severely reduced and eliminated. You can pass around a =
link to the repository and a comment or issue but nobody will be able to se=
e the content unless they are a registered member, which the vast majority =
of all internet people won't be. This will severely curtail brigading and s=
pam while also enabling continued ongoing development activities for collab=
orators.
>
> Bitcoin Core itself has releases and maintainers that push the release bu=
tton. I fully believe that even after privatizing Bitcoin Core that they st=
ill will behave using the same norms and beliefs and systems that they pres=
ently do. Public code review will still continue. Public releases will stil=
l happen. There will still be open source code. But the ability of attacker=
s to steal attention or time from bitcoin developers will be severely reduc=
ed. Likewise for attackers ability to coerce bitcoin developers through pub=
lic spectacle where they do their core work. I believe that the community w=
ould be more productive and more energized if we regularly used a privatize=
d collaboration platform.
>
> In practice, the way that this would roll out is that the GitHub would co=
ntinue to be the GitHub and would not really change. There would be a separ=
ate private area for some developers to work together. Then they would thro=
w it over the wall or have some sort of (possibly real-time) synchronizatio=
n protocol to synchronize pull requests to the public GitHub repository. If=
 you want a public link on X.com then link to that, but a link to the membe=
rship-required site won't work for non-members.
>
> For the private work space: I think registration, coupled with a delay, c=
oupled with a probationary period would probably be sufficient. Possibly al=
so with review or, what could be interesting as if at least two people out =
of any of the members have to recommend the user for entry. Or, you can do =
proof-of-work to get entry and post something, and it's subject to moderato=
r review until 2-of-n approve your membership? I would advocate for very st=
rong norms as to moderation and rules of engagement such as, if you just sh=
ow up to cause chaos then you lose your access to the members-only place an=
d you will have to post code somewhere else on the internet. It won't be th=
at anyone can show up and cause chaos and never be silenced or banned.
>
> Adoption: would not be too difficult, as only two or three developers can=
 privately experience some benefits. They can also use private one-time exp=
iring links to temporarily include non-members as they see fit.
>
> # Theory crafting
>
> Non-technical activist movements have a history of making open discussion=
 forums non-viable. Those same non-technical activist movements also have a=
 history of making many non-viable forks, due to for example a lack of tech=
nical expertise in said movements. I would like to find ways to redirect ef=
forts that would manifest as unusable discussion forums, instead, towards t=
he creation of more non-viable forks.
>
> We can remain committed to making forking as frictionless as we can, whil=
e also increasing the friction of participation of non-technical actors in =
members-only technical discussion forums. The existence of members-only tec=
hnical discussion forums does not preclude the existence of public channels=
, nor does it prohibit the flow of information in either direction. It mere=
ly carves out a specific space and area.
>
> Something along the lines of: "We are willing to commit to your freedom t=
o create and run software of your choosing. We are not committed to interna=
lizing often coercive demands that *we* be the ones to create the exact sof=
tware of your choosing. We hope that you like the software we work on, and =
we welcome your feedback in the right time and place, just not in private d=
eveloper spaces."
>
> Open source software has a lot of history behind it and established devel=
oper culture norms. Open here usually refers to the source code licensing (=
see early 90s work from Foresight Institute's Christine Peterson's Open Sou=
rce Definition initiative). "Open" development does not mean "open to coerc=
ion". It feels very weird to write an email that essentially amounts to rem=
inding grown adults that they can freely collaborate in any way they wish, =
and that they do not have to invite or subject themselves to active ongoing=
 attempts of coercion. Even if it's from "the public". There are free-for-a=
ll places all over the Internet to post that kind of content, or to read it=
 and review it. There are also other possibilities for structured access an=
d presentation of that kind of data. For example, a reverse Bitcoin Optech =
that curates that sort of information from around the web. I suspect that o=
ver 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 collab=
oration process to either retreat into office in-person settings or stop co=
ntributing to bitcoin development entirely...
>
> 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 contributors have be=
en 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 don't agree with, i=
ncluding platforming people who disagree with you or hate you outright. "Co=
ercive platforming" happens when others demand you platform their speech co=
ntent even if it's off-topic or low signal or actively directly hostile to =
you. Meanwhile dev attention is scarce and while it's individually regulate=
d (as it should be), care should be taken to monitor if the obvious default=
 regulation is for developers to simply disengage or not engage at all, whi=
ch would be a detriment to the bitcoin project. Instead we can filter the n=
oise going into the system at the top of the funnel instead of the bottom (=
comments level).
>
> One goal is that we are interested in having more developers join and col=
laborate on Bitcoin Core. Creating an environment conducive to new develope=
rs is important and if they have to also be subjected to a bunch of noise j=
ust to collaborate on code on GitHub then I think that is sub-optimal and a=
 self-defeating strategy if one of the goals is growth in the number of dev=
elopers or contributors.
>
> What I think people might be upset about this idea to privatize is that, =
to the extent that people perceive that they are currently able to coerce d=
evelopers to work on specific things any given developer wouldn't have work=
ed on otherwise, and if any developer collaborations voluntarily retreat to=
 their own private work area, then I think those same people might get upse=
t to the extent they perceive or feel that they are losing 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 arrange=
ment, it's just that people get confused about the social dynamics and forg=
et this isn't feudalism slave labor era anymore.
>
> # End of remarks
>
> 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 i=
t 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 disrupting tens of trillions of dollars of va=
lue. And there are massive adversarial forces, including nation state and n=
on-state actors with tremendously deep resources, that are completely adver=
se to what we stand for and what we believe and what bitcoin is or what bit=
coin will become. These sorts of threats are completely unlike any other op=
en source software project has ever seen, and if anything I am underestimat=
ing what we are up against. This isn't to say to throw out our values and e=
nact bitcoin governance or whatever; 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.
>
> 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 relati=
vely recent and nothing of value will be lost that cannot be re-hosted shou=
ld it ever prove necessary to do so.
>
> --
> 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=
 email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoinde=
v/CABaSBax-meEsC2013zKYJnC3phFFB_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/=
4iW61M7NCP-gPHoQZKi8ZrSa2U6oSjziG5JbZt3HKC_Ook_Nwm1PchKguOXZ235xaDlhg35nY8Z=
n7g1siy3IADHvSHyCcgTHrJorMKcDzZg%3D%40protonmail.com.

--b1=_vUSNfO4MTt8ZXrFmfmBvQoOkgY4jDRPrjzG8CDHQ8Q
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div style=3D"font-family: Arial, sans-serif; font-size: 14px;">Bryan,</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;">Thanks for =
your thoughts. It's always good to take a step back and reflect on whether =
things are the way they are because it makes sense or because of inertia.<b=
r></div>
<div class=3D"protonmail_signature_block protonmail_signature_block-empty" =
style=3D"font-family: Arial, sans-serif; font-size: 14px;">
    <div class=3D"protonmail_signature_block-user protonmail_signature_bloc=
k-empty">
       =20
            </div>
   =20
            <div class=3D"protonmail_signature_block-proton protonmail_sign=
ature_block-empty">
       =20
            </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;">I started re=
ading by speculating you were defending the case for something akin to a "s=
ource-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=
;"><ul style=3D"margin-top: 0px; margin-bottom: 0px;" data-editing-info=3D"=
{&quot;orderedStyleType&quot;:1,&quot;unorderedStyleType&quot;:2}"><li styl=
e=3D"list-style-type: &quot;- &quot;;"><span>The now-private project would =
have to take on the burden of producing educational and historical content,=
 which is currently outsourced to the wider technical community (for instan=
ce the optech newsletter or simply searchable through Github);</span></li><=
li style=3D"list-style-type: &quot;- &quot;;"><span>It would increase the c=
ost, in relation to the previous point, of "grassroot" onboarding to the pr=
oject. 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-con=
tributor-but-not-full-time-project-member, but it seems to me such a projec=
t structure would erect significant barriers to this approach and <span>cou=
ld make it almost necessary to go through one of the development organizati=
ons to onboard to the project;</span></span></li><li style=3D"list-style-ty=
pe: &quot;- &quot;;"><span><span>In a similar but different vein, it would =
also make it less likely to get valuable contributions from people that "ju=
st show up" with no particular intention to start working full time on Bitc=
oin Core but had something that makes a lot of sense to share (whether it's=
 code, reporting an experience or even just a meaningful thought).<br></spa=
n></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. T=
he public mirror would have comment threads on pull requests originating fr=
om the private repository and the possibility to open issues. It would esse=
ntially enable developer to opt into engaging on public comment threads (fo=
r bug reports, contentious pull requests if they see fit, etc..) while alwa=
ys having the possibility to retreat in the private repository to focus. Th=
is does sound more appealing to me, although it raises question with regard=
 to its feasibility and the churn it could introduce (could the public mirr=
or insert public comments within the synced private thread? or would it hav=
e to duplicate every single thread?).<br></div></div><div style=3D"font-fam=
ily: Arial, sans-serif; font-size: 14px;"><br></div><div style=3D"font-fami=
ly: Arial, sans-serif; font-size: 14px;">You touch on the office culture an=
d the need for a platform that would be a better sweet spot between unmoder=
ated public discussions and entirely private discussions happening in the c=
onfines of a Bitcoin developer organization's offices. However it's unclear=
 that what drives a lot of discussions to happen in offices is the occasion=
al disruption of online fora, rather than just the natural advantages of in=
-person discussions.</div><div style=3D"font-family: Arial, sans-serif; fon=
t-size: 14px;"><br></div><div style=3D"font-family: Arial, sans-serif; font=
-size: 14px;">You also state that b<span>rigading would be severely reduced=
 and eliminated</span>. However it seems contrary to having publicly availa=
ble comment threads? It would just contain the brigading to the publicly av=
ailable comment threads. You could make the point that this containment wou=
ld disincentivize the brigading in the first place, but it would only be th=
e case if there is no expectation that the low-quality comments be taken in=
to account in the decision making. And removing this expectation does not r=
equire such an involved project structure, which brings me to my last point=
.</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;">I agr=
ee with your problem statement. I believe there is a dangerous perception t=
hat the Bitcoin Core Github repository somehow controls Bitcoin and is wort=
hy of political pressure. And this is not only the case of the filter enjoy=
ers, 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 with a lot less disruption than by changing the pr=
oject structure. We just need to face the fact that Bitcoin Core is a centr=
alized project. It has a central website, releases binaries and updates its=
 software based on rough technical consensus. Bitcoin is decentralized, Bit=
coin Core is not. Setting expectations that misinformed rants and conspirac=
y theories will be considered at all in deciding whether code should be cha=
nged is entirely self-inflicted and does not need a change in the project s=
tructure to correct. It does however require Bitcoin Core contributors to a=
ct collectively, which is notoriously difficult to achieve, for better (in =
the case of pressure to merge contentious consensus changes for instance) o=
r for worse (here).</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;">In conclusion, i don't think yours is a bad idea. If the Bitco=
in Core project was set up this way today i think it would be fine. I just =
see the current project structure as equally fine and unnecessary to change=
, as what is really needed to mitigate the social attacks is to just stop t=
olerating them.</div><div style=3D"font-family: Arial, sans-serif; font-siz=
e: 14px;"><br></div><div style=3D"font-family: Arial, sans-serif; font-size=
: 14px;">Best,<br>Antoine Poinsot<br></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;">[^0]: It was the case with Craig Wright, but=
 also more recently: <span><a target=3D"_blank" rel=3D"noreferrer nofollow =
noopener" href=3D"https://github.com/bitcoin-core/meta/issues/19#issuecomme=
nt-2843664280">https://github.com/bitcoin-core/meta/issues/19#issuecomment-=
2843664280</a></span><br></div><div class=3D"protonmail_quote">
        On Tuesday, June 10th, 2025 at 4:40 PM, Bryan Bishop &lt;kanzure@gm=
ail.com&gt; wrote:<br>
        <blockquote class=3D"protonmail_quote" 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 controvers=
y, misinformation, etc. It is trivial to see how exposure to deep technical=
 content can cause confusion or misunderstanding for non-technical people w=
ho may not even know the ethos of open-source development or what bitcoin d=
evelopers really do or believe about what they do. Unsolicited feedback fro=
m random/new people and even noise can sometimes be useful and thankfully i=
t's impossible to eliminate online forums for providing that, but here 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 ou=
r hearts desire, and we can freely do that over the Internet or in person o=
n 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 effort and nobo=
dy owes any obligation to anyone else but to themselves. Indeed, even non-d=
eveloper bitcoiners are not obligated, like they are not obligated to run c=
ode 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 working on ope=
n-source software, beyond those created by the license, but I don't buy tha=
t argument. There are no additional explicit obligations beyond the license=
. I'll add, though, that many developers have their own moral values and be=
liefs about how they should act and behave, and how that informs who they c=
hoose to collaborate with, which is great! Many believe they have a persona=
l moral value of informing uneducated people, or protecting people from sec=
urity threats, or hundreds of other particular preferences and opinions. Al=
l of these are fantastic and I am glad these preferences or beliefs exist..=
. but they cannot be coercively applied and we should not allow the bitcoin=
 project, or Bitcoin Core, or github, to be a platform for inflicting coerc=
ive beliefs upon developers that have gifted us so much time, energy and ef=
forts on a historically and systemically critical development.<br><br>There=
fore, I think there might be an opportunity here to re-evaluate the nature =
of open-source software development. I think there is an 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 it look like? What wo=
uld be different? What would be kept the same?<br><br><br># GitHub<br><br>U=
nfortunately the situation is that GitHub does not have good moderation con=
trols and was only built for a very narrow concept of open source developme=
nt. The solution to brigading is better controls around the presentation la=
yer or requiring some sort of membership. If you just have a perpetual open=
 door policy straight from reddit into your developer den, then yeah people=
 are going to walk in and take a shit on your desk where you were working w=
ith another dev.. With some thinking I'm sure we can structure better ways =
to get exposure to general public sentiment or opinion, while also structur=
ing a space for development to take place that does not require blindly mix=
ing off-topic content with developer content.<br><br><br># Privatization<br=
><br>Here, I would like to make the case for privatizing Bitcoin Core softw=
are development into a members-only gitlab or other kind of open-source sof=
tware collaboration system. It would have the following properties. Issues =
and pull requests would be private and not subject to public hyperlinking. =
Anyone can register or apply for access. Whoever runs the site/repository w=
ould be responsible for configuration, hosting, setup, moderation, access c=
ontrol, etc. Software development would continue under the same license. Ne=
w issues, comments, code review comments would possibly 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 about comments licensing.=
 Pull requests can be cross-posted to any number of repositories either pub=
lic or private as much as any contributor wishes, except to the point where=
 any norm violation or spam violation occurs for the respective publishing =
systems of course.<br><br><br># Office culture<br><br>An alternative to wha=
t I am proposing is already happening: development inside closed offices (C=
haincode, Brink, Localhost, etc), which is less accessible and less open th=
an a invite-only developer collab site. And also less "open development" th=
an the current Bitcoin Core GitHub project. So a failure to sort out these =
issues with Bitcoin Core collaboration can and has already produced solutio=
ns that are functionally less inclusive than an online member-only source f=
orge. It is to the detriment of the open project that so much gets discusse=
d inside these private offices and many of us are not able to contribute th=
at way, and there ought to be something between a public github that the ge=
neral public can brigade and closed offices on the other end of the spectru=
m.<br><br><br># How it would work<br><br>Contributors would be free to coll=
aborate on any branch, pull request, or privatized fork, or even public for=
k. Issues, issue comments, pull request comments, code review comments, and=
 miscellaneous discussions can also be posted internally. Code can come fro=
m inside the members-only repository, or it can be contributed from outside=
 sources if someone pulls it in, proposes it, or otherwise posts those patc=
hes.<br><br>Releases can be cut and source code published all at once, if t=
hat is desirable to anyone. However, I suspect that for Bitcoin Core, contr=
ibutors would likely push changes out to various public access githubs or o=
ther locations on an hourly, daily or regular basis. Bitcoin Core, as it ex=
ists today, could do the same for pull requests, code review comments, etc,=
 and post them publicly on a website. Anyone would be free to make a websit=
e where any person, including non-developers and including non-contributors=
, could freely post code review or comments. This could even happen on the =
current GH bitcoin/bitcoin repository. For example, any of the private code=
 review comments can be posted directly into the PR on GH. PGP signatures c=
an be used for verifiable comment attribution. Or another website can be li=
nked from a GH PR to display the private-originated review history.<br><br>=
Brigading will be severely reduced and eliminated. You can pass around a li=
nk to the repository and a comment or issue 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 will severely curtail brigading and spa=
m while also enabling continued ongoing development activities for collabor=
ators.<br><br>Bitcoin Core itself has releases and maintainers that push th=
e release button. I fully believe that even after privatizing Bitcoin Core =
that they still will behave using the same norms and beliefs and systems th=
at they presently do. Public code review will still continue. Public releas=
es will still happen. There will still be open source code. But the ability=
 of attackers to steal attention or time from bitcoin developers will be se=
verely reduced. Likewise for attackers ability to coerce bitcoin developers=
 through public spectacle where they do their core work. I believe that the=
 community would be more productive and 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 would continue to be the GitHub and woul=
d not really change. There would be a separate private area for some develo=
pers to work together. Then they would throw it over the wall or have some =
sort of (possibly real-time) synchronization protocol to synchronize pull r=
equests to the public GitHub repository. If you want a public link on X.com=
 then link to that, but a link to the membership-required site won't work f=
or non-members.<br><br>For the private work space: I think registration, co=
upled with a delay, coupled with a probationary period would probably be su=
fficient. Possibly also with review or, what could be interesting as if at =
least two people out of any of the members have to recommend the user for e=
ntry. Or, you can do proof-of-work 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 norms as to moderation and rules of engagement su=
ch as, if you just show up to cause chaos then you lose your access to the =
members-only place and you will have to post code somewhere else on the int=
ernet. It won't be that anyone can show up and cause chaos and never be sil=
enced or banned.<br><br>Adoption: would not be too difficult, as only two o=
r three developers can privately experience some benefits. They can also us=
e private one-time expiring links to temporarily include non-members as the=
y see fit.<br><br><br># Theory crafting<br><br>Non-technical activist movem=
ents have a history of making open discussion forums non-viable. Those same=
 non-technical activist movements also have a history of making many non-vi=
able forks, due to for example a lack of technical expertise in said moveme=
nts. I would like to find ways to redirect efforts that would manifest as u=
nusable discussion forums, instead, towards the creation of more non-viable=
 forks.<br><br>We can remain committed to making forking as frictionless as=
 we can, while also increasing the friction of participation of non-technic=
al actors in members-only technical discussion forums. The existence of mem=
bers-only technical discussion forums does not preclude the existence of pu=
blic channels, nor does it prohibit the flow of information in either direc=
tion. It merely carves out a specific space and area.<br><br>Something alon=
g the lines of: "We are willing to commit to your freedom to create and run=
 software of your choosing. We are not committed to internalizing often coe=
rcive demands that *we* be the ones to create the exact software of your ch=
oosing. We hope that you like the software we work on, and we welcome your =
feedback in the right time and place, just not in private developer spaces.=
"<br><br>Open source software has a lot of history behind it and establishe=
d developer culture norms. Open here usually refers to the source code lice=
nsing (see early 90s work from Foresight Institute's Christine Peterson's O=
pen Source Definition initiative). "Open" development does not mean "open t=
o coercion". It feels very weird to write an email that essentially 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 themselves to active =
ongoing attempts of coercion. Even if it's from "the public". There are fre=
e-for-all places all over the Internet to post that kind of content, or to =
read it and review it. There are also other possibilities for structured ac=
cess and presentation of that kind of data. For example, a reverse Bitcoin =
Optech that curates that sort of information from around the web. I suspect=
 that over time what has happened is that of the people who refuse to be su=
bjected to coercion attempts from internet mobs have simply left the public=
 collaboration process to either retreat into office in-person settings or =
stop contributing to bitcoin development entirely...<br><br>Also, it does n=
ot feel good to ban people or clean up brigades to restore structure or ord=
er etc. which is partly why some core contributors 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 don't agree with, including platform=
ing people who disagree with you or hate you outright. "Coercive platformin=
g" happens when others demand you platform their speech content even if it'=
s off-topic or low signal or actively directly hostile to you. Meanwhile de=
v attention is scarce and while it's individually regulated (as it should b=
e), care should be taken to monitor if the obvious default regulation is fo=
r developers to simply disengage or not engage at all, which would be a det=
riment to the bitcoin project. Instead we can filter the noise going into t=
he system at the top of the funnel instead of the bottom (comments level).<=
br><br>One goal is that we are interested in having more developers join an=
d collaborate on Bitcoin Core. Creating an environment conducive to new dev=
elopers is important and if they have to also be subjected to a bunch of no=
ise just to collaborate on code on GitHub then I think that is sub-optimal =
and a self-defeating strategy if one of the goals is growth in the number o=
f developers or contributors.<br><br>What I think people might be upset abo=
ut this idea to privatize is that, to the extent that people perceive that =
they are currently able to coerce developers to work on specific things any=
 given developer wouldn't have worked on otherwise, and if any developer co=
llaborations voluntarily retreat to their own private work area, then I thi=
nk those same people might get upset to the extent they perceive or feel th=
at they are losing a coercive lever over developers that they previously th=
ought they had (perhaps permanent) power over. In reality, it has always be=
en 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 =
anymore.<br><br><br><br># End of remarks<br><br>Building this sort of prote=
ction measure is important for the ongoing and future success of the projec=
t. As a moderator in the bitcoin-dev project it is hard for me to communica=
te the levels of attacks that we have seen and that I expect to see going f=
orward. We are talking about a trillion dollar system. We are talking about=
 disrupting tens of trillions of dollars of value. And there are massive ad=
versarial forces, including nation state and non-state actors with tremendo=
usly deep resources, that are completely adverse to what we stand for and w=
hat we believe and what bitcoin is or what bitcoin will become. These sorts=
 of threats are completely unlike any other open source software project ha=
s ever seen, and if anything I am underestimating what we are up against. T=
his isn't to say to throw out our values and enact bitcoin governance or wh=
atever; instead it's an opportunity to look at what tools we have at our di=
sposal to counter these threats and ensure our continued productivity and t=
hat 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 Bishop=
 aka kanzure<br><br>June 2025<br><br><br><a href=3D"https://www.lesswrong.c=
om/posts/tscc3e5eujrsEeFN4/well-kept-gardens-die-by-pacifism" target=3D"_bl=
ank" rel=3D"noreferrer nofollow noopener">https://www.lesswrong.com/posts/t=
scc3e5eujrsEeFN4/well-kept-gardens-die-by-pacifism</a><br><a href=3D"https:=
//meaningness.com/geeks-mops-sociopaths" target=3D"_blank" rel=3D"noreferre=
r nofollow noopener">https://meaningness.com/geeks-mops-sociopaths</a><br><=
a href=3D"https://github.com/bitcoin-core/meta/issues/19" target=3D"_blank"=
 rel=3D"noreferrer nofollow noopener">https://github.com/bitcoin-core/meta/=
issues/19</a><br><a href=3D"https://x.com/kanzure/status/193253482060704594=
7" target=3D"_blank" rel=3D"noreferrer nofollow noopener">https://x.com/kan=
zure/status/1932534820607045947</a><br><br>P.S. I still think bitcoin-core/=
meta on GH should be deleted. It's relatively recent and nothing of value w=
ill be lost that cannot be re-hosted should it ever prove necessary to do s=
o.<br></div><div><br></div><div data-smartmail=3D"gmail_signature" class=3D=
"gmail_signature" dir=3D"ltr"></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
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" rel=3D"n=
oreferrer nofollow noopener">bitcoindev+unsubscribe@googlegroups.com</a>.<b=
r>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w%40mail.gmail=
.com" target=3D"_blank" rel=3D"noreferrer nofollow noopener">https://groups=
.google.com/d/msgid/bitcoindev/CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPD=
ZKsjB8w%40mail.gmail.com</a>.<br>

        </blockquote><br>
    </div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; 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/4iW61M7NCP-gPHoQZKi8ZrSa2U6oSjziG5JbZt3HKC_Ook_Nwm1PchKguOXZ235x=
aDlhg35nY8Zn7g1siy3IADHvSHyCcgTHrJorMKcDzZg%3D%40protonmail.com?utm_medium=
=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoindev/=
4iW61M7NCP-gPHoQZKi8ZrSa2U6oSjziG5JbZt3HKC_Ook_Nwm1PchKguOXZ235xaDlhg35nY8Z=
n7g1siy3IADHvSHyCcgTHrJorMKcDzZg%3D%40protonmail.com</a>.<br />

--b1=_vUSNfO4MTt8ZXrFmfmBvQoOkgY4jDRPrjzG8CDHQ8Q--