path: root/e3/f5f41134d576d39ebbf05591877e4d5f7f52fa

Delivery-date: Wed, 11 Jun 2025 17:02:16 -0700
Received: from mail-qt1-f189.google.com ([209.85.160.189])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDJ6TUHA44ARB65RVDBAMGQE55WBSPA@googlegroups.com>)
	id 1uPVOY-0000yh-Ah
	for bitcoindev@gnusha.org; Wed, 11 Jun 2025 17:02:16 -0700
Received: by mail-qt1-f189.google.com with SMTP id d75a77b69052e-4a6ef72a544sf7155691cf.1
        for <bitcoindev@gnusha.org>; Wed, 11 Jun 2025 17:02:14 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1749686528; cv=pass;
        d=google.com; s=arc-20240605;
        b=KrIvKGZsCeh6TUw4mOgQGezQ3ZC6U7Bu3XiUMFivGDK8bweo0ahtoG53rejEYngPnO
         fN9yGxANfAetI16kmKEVEOzs3B5BaUcQupnZilHHLPp71qheITlSLeU6HsSeIdaTb2Bc
         DDe1vsXqePockvaLSv/N4Toi5p4ydHq143PBX+pvKpi09xKWFi+QnV83rC2yUFpgZFX9
         sMP8STs3dC9yLww6A+4S3eY9xYnjfGC1fhZ6dR9IVvk1Nm1lpQLFVLw2TXzrhYLro/V7
         9UwZ+ktQYt6RaZFeIqq7GRb6axEUTfGyGJJTxM88ahy95ryEVSJw9RALrQqV+yUWHA3k
         /+xA==
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:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature;
        bh=bDxEsh9KOfs5SsuhlGDwcV+QkAM+o+axuI937jHIXcw=;
        fh=nJWCAe8SCGqG4X6+l4FlzstmBFEL5/s1lWpJ4MojCaY=;
        b=gORfBjt9yf4IjPxocryuSYC0tsaN7T+kwFo77TZ0WeYru9MTun4Chcy0vk05+AgvV5
         iZo9LpWuGc5pGubYH0WIqfxROzxHOYDQlvgMA3OHpuUHu2Flc5qeD0S4NOS5cjRQkzKY
         fbdFE1ZsHgRn6jKyqv5tKkY78GSRF1P622YVaLkmi5OjvRxj8Qyi6SNDFjUlKB/bp6TT
         +zlMCSclRp0EIQbAGe7+HtYoBBy3ump/ywL2ATGmZSZhqMHgPxjZtkcZhQWvMPsHoe0Q
         lXhexkL75MlHlc8XWhrvxmACB1gBxrB5ywiI2rKsVh50Y0TQg0+6BO4SU2aszvim8I3F
         4Iog==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       spf=pass (google.com: domain of dscotese@gmail.com designates 209.85.128.41 as permitted sender) smtp.mailfrom=dscotese@gmail.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1749686528; x=1750291328; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=bDxEsh9KOfs5SsuhlGDwcV+QkAM+o+axuI937jHIXcw=;
        b=IwvstaYXG0jpMigPtNDb3aL0T3ceLugDsRSTazjhLhkcuX5UCpVtR6SGM/C7Ohdhle
         JT3J8E6ofUNOEDhSpPM76ihvD27RaqLQHK18Xo/FmXMVW1zFt6160kWRanq2eu/jHMog
         ZejabnlfyFycRRAa9Wo4TTi9oBk0xiW9pIf3BaAWTmKxOX3ezr0p+MeuEdZbXdT8Hwv+
         XKvbDuPbKdoI5Jt8KwLTWY2vMivORMzI+X/tZYzrL+Ok+lkpaWtN1i8I0K09zjcXhez7
         7XftuWNx2/pHTT9XNa5mPhxwWvPwDF+y/ojr5mZEzG4onMoTLiueZbUJm6YcP7V21OlC
         4KyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749686528; x=1750291328;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=bDxEsh9KOfs5SsuhlGDwcV+QkAM+o+axuI937jHIXcw=;
        b=npoxg7g62HP6ZF5RoSRygdqkFlMl66mL6aHEknPEbV6TOtjYuoS9/bFp0+GRXXuHrc
         cqZt18ntlRocIST4M1AE0icX4eAws7FqblgTyBRgQuLbZbULkPcjZM9ADE4EKemvaC6u
         VIsNvdlfqSnpX0vtEUlKb88e4dr+qsl943UaREsdLrHVNIcAFIdg6D/GbpvGh0Kc5iVU
         VNY5d9WdFwqcus2xDeWNXphnwgX9x5yQQpNN7p3wF3AlgXNRCxHx1BgwUd0MkpY164Y8
         z0vdFhNG4d0qtXbcCv7iABzicSufLuQKDvistjhxizuBz+wzOCm3PiXVB2Hnn0nbGRp5
         pv9w==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCWUi5vz/qV5enS4l6SjE8cAUpix7GKAfsozCWhnYaJEZDHTyjefzBH10erAZ7+I72qIqKvHaVdkq6bJ@gnusha.org
X-Gm-Message-State: AOJu0YxsSeNI9uxW3CUl6qFr0xsXoKZCwtb019BRlrDX98jehDN6iioO
	Lmwq68C5VvkSx05OtacvzCLHnXkHm+j/pADSa3n//GFW4MwOkr75LDov
X-Google-Smtp-Source: AGHT+IGBVoTtBd0bRLXzAOVKhQNoTJkDIyt6BFqahd8uzWBtLnVX4v4sgoCARIYugOilzIkhclCFUg==
X-Received: by 2002:a05:622a:1b28:b0:49d:89bf:2982 with SMTP id d75a77b69052e-4a724294541mr14722811cf.17.1749686527582;
        Wed, 11 Jun 2025 17:02:07 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZdB2GnrldjTMLr8By3ZHUMsEhOLPPVyEs8SAMjF/petDQ==
Received: by 2002:ac8:580c:0:b0:4a6:f717:1df3 with SMTP id d75a77b69052e-4a722b676cbls7294861cf.0.-pod-prod-07-us;
 Wed, 11 Jun 2025 17:02:02 -0700 (PDT)
X-Received: by 2002:a05:620a:3915:b0:7d0:97d6:e94b with SMTP id af79cd13be357-7d3b369e84emr155103885a.31.1749686522580;
        Wed, 11 Jun 2025 17:02:02 -0700 (PDT)
Received: by 2002:ab3:7b88:0:b0:2b1:97ca:fe9d with SMTP id a1c4a302cd1d6-2b5151385bemsc7a;
        Tue, 10 Jun 2025 16:13:30 -0700 (PDT)
X-Received: by 2002:a05:6512:3e10:b0:553:6583:8f2 with SMTP id 2adb3069b0e04-5539c2385d5mr365538e87.57.1749597207593;
        Tue, 10 Jun 2025 16:13:27 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1749597207; cv=none;
        d=google.com; s=arc-20240605;
        b=gplxttcjjlyJWWp1S57iGtcRrJgx/VCTYkeljbhc72JxlwdmVJCgnVsYvL4nyKtCGf
         UySNJvxFv4+kJ4rGTcPLspHtMoASkv4h/cw+iKqSymnIediP2Z4alQIxteRdxbTEliP8
         2MRxVf6ees+I3QpsDEcoBRHBlUcvvEcGZGJVmWE4a6MdiDCKU44+Mmz0GBfUF5y2rjzh
         v3bXAjU6zA6wYcHgnyrJ/3nAI2bZ5AWFn25g7r9BNJIYdmn8MHzrz1+O8eStnlXk3MDO
         mIqCL1PuxYOQ4w7zTdoD+o0SPoEmGyityG6u9iYBsvFlEAhg+tGyrwbpwMufS3X0T6p3
         4Osg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version;
        bh=e7wRm862txjebdUxeLFpjiN6G+N+HyL7hWNud0bEms4=;
        fh=GrYwucciMhLORZt1fsQXZtg3Ji0QXL4X0nS/6kd273E=;
        b=MlOSD1TnMzgYGsZDACeFujzi5Blckpk9ehQxVV8W6JBU0h5TbcL6sDwzK1fZ/qkMF9
         v/a/kZZLjRcyMS06ce8sUJATNAx4ixa6hJ1nyDVesvC1aXjQvZAsMom1dLrXB9RWFgda
         cM+Pao0U43E5HHoD6pBihhe+X2B6IrawQ2a6gtRydorp5ZMGJTVPLqpo3vWqmgy3xb2A
         rLWCRJFGxBFKwRgnhCAvt7y61/lWWOCzkyqId8DPgVxtenKPT66+LCt0NnbC9+1gssRh
         nwHJ5CcQNmh8mPhkdcPnbiIek6og0v8J1JAgq9CG+73uIbGWL6fwW6X8SjOIh3ogRk76
         TGcw==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       spf=pass (google.com: domain of dscotese@gmail.com designates 209.85.128.41 as permitted sender) smtp.mailfrom=dscotese@gmail.com
Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com. [209.85.128.41])
        by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-553677338adsi199124e87.9.2025.06.10.16.13.27
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Tue, 10 Jun 2025 16:13:27 -0700 (PDT)
Received-SPF: pass (google.com: domain of dscotese@gmail.com designates 209.85.128.41 as permitted sender) client-ip=209.85.128.41;
Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-43edecbfb94so72809675e9.1
        for <bitcoindev@googlegroups.com>; Tue, 10 Jun 2025 16:13:27 -0700 (PDT)
X-Gm-Gg: ASbGnctPPRu8egQDh7JA/4Vdx1kDtel+o2hO2WkqrUhMxHrSvxqwxxIJD8kTuTMwyze
	6cijX9XFC5sJ+ZuN5Z1+jdbpdVp641/iyfpeEah5rReJpE8yorDoriDr1ez/rJagEdM+ufPv46t
	R7MvWfk7B81wFfU7lxeiv8ejNhh58FRS89THO0tJOTGwA=
X-Received: by 2002:a05:600c:c16b:b0:450:cea0:1781 with SMTP id
 5b1f17b1804b1-453248cd535mr7613215e9.16.1749597206427; Tue, 10 Jun 2025
 16:13:26 -0700 (PDT)
MIME-Version: 1.0
References: <CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w@mail.gmail.com>
In-Reply-To: <CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w@mail.gmail.com>
From: Dave Scotese <dscotese@litmocracy.com>
Date: Tue, 10 Jun 2025 16:13:14 -0700
X-Gm-Features: AX0GCFsFoS8GomijQh3wOIYQZJ9J5hx1qtOo5gp0t-pIWtYpTHtUHepOx1wXkEI
Message-ID: <CAGLBAhePmsCcC1b0m5m-coqfMchqVFNNgqdyfkZosiRWt+nRow@mail.gmail.com>
Subject: Re: [bitcoindev] The case for privatizing Bitcoin Core
To: Bryan Bishop <kanzure@gmail.com>
Cc: bitcoindev@googlegroups.com
Content-Type: multipart/alternative; boundary="000000000000fd3e4306373fd7d4"
X-Original-Sender: dscotese@litmocracy.com
X-Original-Authentication-Results: gmr-mx.google.com;       spf=pass
 (google.com: domain of dscotese@gmail.com designates 209.85.128.41 as
 permitted sender) smtp.mailfrom=dscotese@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.7 (/)

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

Thanks for the great write-up!

I don't think "Please be less shy about moderation on Github" is too much
to ask. I'm not sure much else needs to be done. I also suspect that
there's a lot of deep understanding of the tools (github, gitlab, etc.)
that can already be used to thwart coercive brigading. Perhaps those who
control the public facing accounts could benefit from some help from people
who understand those tools better than I do.

Dave Scotese.

On Tue, Jun 10, 2025 at 1:40=E2=80=AFPM Bryan Bishop <kanzure@gmail.com> wr=
ote:

> The case for privatizing Bitcoin Core:
>
> I believe that reflection is critical for curiosity, understanding,
> improvement, and progress. And recent activity on the Bitcoin Core github
> account has given me an opportunity to re-evaluate my beliefs about
> open-source software 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)
> intruding into an online forum intended mainly for people collaborating o=
n
> Bitcoin Core to work together on whatever they are working on. This often
> causes issues like wasting people's valuable time, creating manufactured
> controversy, misinformation, etc. It is trivial to see how exposure to de=
ep
> technical content can cause confusion or misunderstanding for non-technic=
al
> people who may not even know the ethos of open-source development or what
> bitcoin developers really do or believe about what they do. Unsolicited
> feedback from random/new people and even noise can sometimes be useful an=
d
> thankfully it's impossible to eliminate online forums for providing that,
> 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
> whatever our hearts desire, and we can freely do that over the Internet o=
r
> 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
> effort and nobody owes any obligation to anyone else but to themselves.
> Indeed, even non-developer bitcoiners are not obligated, like they are no=
t
> obligated to run code written by people they find disagreeable if for som=
e
> 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
> working on open-source software, beyond those created by the license, but=
 I
> don't buy that argument. There are no additional explicit obligations
> beyond 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 th=
at
> informs who they choose to collaborate with, which is great! Many believe
> they have a personal moral value of informing uneducated people, or
> protecting people from security threats, or hundreds of other particular
> preferences and opinions. All 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 b=
e
> a platform for inflicting coercive beliefs upon developers that have gift=
ed
> us so much time, energy 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 opportuni=
ty
> 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
> development. The solution to brigading is better controls around the
> presentation layer 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 with another dev.. With some thinking I'm sure we can
> structure better ways to get exposure to general public sentiment or
> opinion, while also structuring a space for development to take place tha=
t
> 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
> software 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 would be responsible for configuration, hosting, setup,
> moderation, access control, etc. Software development would continue unde=
r
> the same license. New issues, comments, code review comments would possib=
ly
> 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 public or private as much as any contributor wishe=
s,
> except to the point where any norm violation or spam violation occurs for
> the respective publishing systems of course.
>
>
> # Office culture
>
> An alternative to what I am proposing is already happening: development
> inside closed offices (Chaincode, Brink, Localhost, etc), which is less
> accessible and less open than a invite-only developer collab site. And al=
so
> less "open development" than the current Bitcoin Core GitHub project. So =
a
> failure to sort out these issues with Bitcoin Core collaboration can and
> has already produced solutions that are functionally less inclusive than =
an
> online member-only source forge. It is to the detriment of the open proje=
ct
> that so much gets discussed inside these private offices and many of us a=
re
> not able to contribute that way, and there ought to be something between =
a
> public github that the general public can brigade and closed offices on t=
he
> other 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 reques=
t
> comments, code review comments, and miscellaneous discussions can also be
> posted 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.
>
> Releases can be cut and source code published all at once, if that is
> desirable to anyone. However, I suspect that for Bitcoin Core, contributo=
rs
> would likely push changes out to various public access githubs or other
> locations on an hourly, daily or regular basis. Bitcoin Core, as it exist=
s
> today, could do the same for pull requests, code review comments, etc, an=
d
> post them publicly on a website. Anyone would be free to make a website
> 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 co=
de
> review comments 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
> 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 spam while also enabling continued ongoing development
> activities for collaborators.
>
> Bitcoin Core itself has releases and maintainers that push the release
> button. I fully believe that even after privatizing Bitcoin Core that the=
y
> still will behave using the same norms and beliefs and systems that they
> presently do. Public code review will still continue. Public releases wil=
l
> still happen. There will still be open source code. But the ability of
> attackers to steal attention or time from bitcoin developers will be
> severely 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.
>
> In practice, the way that this would roll out is that the GitHub would
> 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 wou=
ld
> throw it over the wall or have some sort of (possibly real-time)
> synchronization protocol to synchronize pull requests to the public GitHu=
b
> 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 for non-members.
>
> For the private work space: I think registration, coupled with a delay,
> coupled with a probationary period would probably be sufficient. 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 entry. Or, you c=
an
> 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 f=
or
> very strong norms as to moderation and rules of engagement such as, if yo=
u
> 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 internet. It
> won't be that 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
> expiring 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
> 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.
>
> 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
> technical discussion forums does not preclude the existence of public
> channels, nor does it prohibit the flow of information in either directio=
n.
> It merely 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
> 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 wo=
rk
> on, and we welcome your feedback in the right time and place, just not in
> private developer spaces."
>
> Open source software has a lot of history behind it and established
> developer culture norms. Open here usually refers to the source code
> licensing (see early 90s work from Foresight Institute's Christine
> Peterson's Open Source Definition initiative). "Open" development does no=
t
> mean "open to 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 free-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 access and presentation of that kind o=
f
> data. For example, a reverse Bitcoin Optech that curates that sort of
> information from around the web. I suspect that over time what has happen=
ed
> is that of the people who refuse to be subjected to coercion attempts fro=
m
> internet mobs have simply left the public collaboration process to either
> retreat into office in-person settings or stop contributing 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
> been so hesitant to hit the GH moderation buttons more often, plus many o=
f
> 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 platforming people who disagree with you or hate you
> outright. "Coercive platforming" 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 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 simply disengage o=
r
> not engage at all, which would be a detriment to the bitcoin project.
> Instead we can filter the noise 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
> collaborate on Bitcoin Core. Creating an environment conducive to new
> developers is important and if they have to also be subjected to a bunch =
of
> noise 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 i=
n
> the number of developers 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
> developers to work on specific things any given developer wouldn't have
> worked on otherwise, and if any developer collaborations voluntarily
> 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 losing =
a
> coercive lever over developers that they previously thought they had
> (perhaps permanent) power over. In reality, it has always been a voluntar=
y
> non-coercive arrangement, it's just that people get confused about the
> 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
> 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 dolla=
r
> system. We are talking about disrupting tens of trillions of dollars of
> value. And there are massive adversarial forces, including nation state a=
nd
> non-state actors with tremendously deep 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 threats are completely unlike an=
y
> other open source software project has ever seen, and if anything I am
> underestimating what we are up against. This isn't to say to throw out ou=
r
> values and enact bitcoin governance or whatever; instead it's an
> opportunity to look at what tools we have at our disposal to counter thes=
e
> 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
> relatively recent and nothing of value will be lost that cannot be
> re-hosted should 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/bitcoindev/CABaSBax-meEsC2013zKYJnC3phF=
FB_W3cHQLroUJcPDZKsjB8w%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CABaSBax-meEsC2013zKYJnC3ph=
FFB_W3cHQLroUJcPDZKsjB8w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter>
> .
>


--=20
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto

--=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/=
CAGLBAhePmsCcC1b0m5m-coqfMchqVFNNgqdyfkZosiRWt%2BnRow%40mail.gmail.com.

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

<div dir=3D"ltr">Thanks for the great write-up!<div><br></div><div>I don&#3=
9;t think &quot;Please be less shy about moderation on Github&quot; is too =
much to ask. I&#39;m not sure much else needs to be done. I also suspect th=
at there&#39;s a lot of deep understanding of the tools (github, gitlab, et=
c.) that can already be used to thwart=C2=A0coercive brigading. Perhaps tho=
se who control the public facing accounts could benefit from some help from=
 people who understand those tools better than I do.</div><div><br></div><d=
iv>Dave Scotese.</div></div><br><div class=3D"gmail_quote gmail_quote_conta=
iner"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jun 10, 2025 at 1:40=E2=
=80=AFPM Bryan Bishop &lt;<a href=3D"mailto:kanzure@gmail.com">kanzure@gmai=
l.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><div dir=3D"ltr"><div>The case for privatizing Bitcoin Core:<br><br>I =
believe that reflection is critical for curiosity, understanding, improveme=
nt, and progress. And recent activity on the Bitcoin Core github account ha=
s given me an opportunity to re-evaluate my beliefs about open-source softw=
are development on GitHub.<br><br><br># The ongoing problem<br><br>What hap=
pened was nothing new. It has happened before and it will happen again, esp=
ecially if we do nothing new or different. Essentially there is a recurring=
 pattern of non-contributors (sometimes even non-developers) intruding into=
 an online forum intended mainly for people collaborating on Bitcoin Core t=
o work together on whatever they are working on. This often causes issues l=
ike wasting people&#39;s valuable time, creating manufactured controversy, =
misinformation, etc. It is trivial to see how exposure to deep technical co=
ntent can cause confusion or misunderstanding for non-technical people who =
may not even know the ethos of open-source development or what bitcoin deve=
lopers really do or believe about what they do. Unsolicited feedback from r=
andom/new people and even noise can sometimes be useful and thankfully it&#=
39;s impossible to eliminate online forums for providing that, but here I&#=
39;m specifically focusing on areas intended for dev collaboration.<br><br>=
What we want as developers is to collaborate with whoever we wish on whatev=
er our hearts desire, and we can freely do that over the Internet or in per=
son on any project we see fit. Many of us choose to work on Bitcoin. Some o=
f us choose to work on Bitcoin Core. It is an entirely voluntary effort and=
 nobody owes any obligation to anyone else but to themselves. Indeed, even =
non-developer bitcoiners are not obligated, like they are not obligated to =
run code written by people they find disagreeable if for some reason they c=
annot 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 o=
n open-source software, beyond those created by the license, but I don&#39;=
t buy that argument. There are no additional explicit obligations beyond th=
e license. I&#39;ll add, though, that many developers have their own moral =
values and beliefs about how they should act and behave, and how that infor=
ms who they choose to collaborate with, which is great! Many believe they h=
ave a personal moral value of informing uneducated people, or protecting pe=
ople from security threats, or hundreds of other particular preferences and=
 opinions. All of these are fantastic and I am glad these preferences or be=
liefs exist... but they cannot be coercively applied and we should not allo=
w the bitcoin project, or Bitcoin Core, or github, to be a platform for inf=
licting coercive beliefs upon developers that have gifted us so much time, =
energy and efforts on a historically and systemically critical development.=
<br><br>Therefore, I think there might be an opportunity here to re-evaluat=
e the nature of open-source software development. I think there is an oppor=
tunity to re-evaluate how we choose to work together. What if there was a b=
etter 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?<br><br><br># Gi=
tHub<br><br>Unfortunately the situation is that GitHub does not have good m=
oderation controls and was only built for a very narrow concept of open sou=
rce development. The solution to brigading is better controls around the pr=
esentation layer or requiring some sort of membership. If you just have a p=
erpetual open door policy straight from reddit into your developer den, the=
n yeah people are going to walk in and take a shit on your desk where you w=
ere working with another dev.. With some thinking I&#39;m sure we can struc=
ture better ways to get exposure to general public sentiment or opinion, wh=
ile also structuring a space for development to take place that does not re=
quire blindly mixing off-topic content with developer content.<br><br><br>#=
 Privatization<br><br>Here, I would like to make the case for privatizing B=
itcoin Core software development into a members-only gitlab or other kind o=
f open-source software collaboration system. It would have the following pr=
operties. Issues and pull requests would be private and not subject to publ=
ic hyperlinking. Anyone can register or apply for access. Whoever runs the =
site/repository would be responsible for configuration, hosting, setup, mod=
eration, access control, etc. Software development would continue under the=
 same license. New 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 co=
mments licensing. Pull requests can be cross-posted to any number of reposi=
tories either public or private as much as any contributor wishes, except t=
o the point where any norm violation or spam violation occurs for the respe=
ctive publishing systems of course.<br><br><br># Office culture<br><br>An a=
lternative to what I am proposing is already happening: development inside =
closed offices (Chaincode, Brink, Localhost, etc), which is less accessible=
 and less open than a invite-only developer collab site. And also less &quo=
t;open development&quot; than the current Bitcoin Core GitHub project. So a=
 failure to sort out these issues with Bitcoin Core collaboration can and h=
as already produced solutions that are functionally less inclusive than 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 of us ar=
e not able to contribute that way, and there ought to be something between =
a public github that the general public can brigade and closed offices on t=
he other end of the spectrum.<br><br><br># How it would work<br><br>Contrib=
utors would be free to collaborate on any branch, pull request, or privatiz=
ed fork, or even public fork. Issues, issue comments, pull request comments=
, code review comments, and miscellaneous discussions can also be posted in=
ternally. 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 source code =
published all at once, if that is desirable to anyone. However, I suspect t=
hat for Bitcoin Core, contributors would likely push changes out to various=
 public access githubs or other locations on an hourly, daily or regular ba=
sis. 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 wou=
ld be free to make a website where any person, including non-developers and=
 including non-contributors, could freely post code review or comments. Thi=
s could even happen on the current GH bitcoin/bitcoin repository. For examp=
le, any of the private code review comments can be posted directly into the=
 PR on GH. PGP signatures can be used for verifiable comment attribution. O=
r another website can be linked from a GH PR to display the private-origina=
ted review history.<br><br>Brigading will be severely reduced and eliminate=
d. You can pass around a link 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&#39;t be. This will sev=
erely curtail brigading and spam while also enabling continued ongoing deve=
lopment activities for collaborators.<br><br>Bitcoin Core itself has releas=
es and maintainers that push the release button. I fully believe that even =
after privatizing Bitcoin Core that they still will behave using the same n=
orms and beliefs and systems that they presently do. Public code review wil=
l still continue. Public releases will still happen. There will still be op=
en source code. But the ability of attackers to steal attention or time fro=
m bitcoin developers will be severely reduced. Likewise for attackers abili=
ty to coerce bitcoin developers through public spectacle where they do thei=
r 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 con=
tinue to be the GitHub and would not really change. There would be a separa=
te private area for some developers to work together. Then they would throw=
 it over the wall or have some sort of (possibly real-time) synchronization=
 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 member=
ship-required site won&#39;t work for non-members.<br><br>For the private w=
ork space: I think registration, coupled with a delay, coupled with a proba=
tionary period would probably be sufficient. Possibly also with review or, =
what could be interesting as if at least two people out of any of the membe=
rs have to recommend the user for entry. Or, you can do proof-of-work to ge=
t entry and post something, and it&#39;s subject to moderator review until =
2-of-n approve your membership? I would advocate for very strong norms as t=
o 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 will have=
 to post code somewhere else on the internet. It won&#39;t be that anyone c=
an show up and cause chaos and never be silenced or banned.<br><br>Adoption=
: would not be too difficult, as only two or three developers can privately=
 experience some benefits. They can also use private one-time expiring link=
s to temporarily include non-members as they see fit.<br><br><br># Theory c=
rafting<br><br>Non-technical activist movements have a history of making op=
en discussion forums non-viable. Those same non-technical activist movement=
s also have a history of making many non-viable forks, due to for example a=
 lack of technical expertise in said movements. I would like to find ways t=
o redirect efforts that would manifest as unusable discussion forums, inste=
ad, towards the creation of more non-viable forks.<br><br>We can remain com=
mitted to making forking as frictionless as we can, while also increasing t=
he friction of participation of non-technical actors in members-only techni=
cal discussion forums. The existence of members-only technical discussion f=
orums does not preclude the existence of public channels, nor does it prohi=
bit the flow of information in either direction. It merely carves out a spe=
cific space and area.<br><br>Something along the lines of: &quot;We are wil=
ling to commit to your freedom to create and run software of your choosing.=
 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 li=
ke the software we work on, and we welcome your feedback in the right time =
and place, just not in private developer spaces.&quot;<br><br>Open source s=
oftware has a lot of history behind it and established developer culture no=
rms. Open here usually refers to the source code licensing (see early 90s w=
ork from Foresight Institute&#39;s Christine Peterson&#39;s Open Source Def=
inition initiative). &quot;Open&quot; development does not mean &quot;open =
to coercion&quot;. It feels very weird to write an email that essentially a=
mounts to reminding grown adults that they can freely collaborate in any wa=
y they wish, and that they do not have to invite or subject themselves to a=
ctive ongoing attempts of coercion. Even if it&#39;s from &quot;the public&=
quot;. There are free-for-all places all over the Internet to post that kin=
d of content, or to read it and review it. There are also other possibiliti=
es for structured access and presentation of that kind of data. For example=
, a reverse Bitcoin Optech that curates that sort of information from aroun=
d 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 si=
mply 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 not feel good to ban people or clean up brigades to rest=
ore structure or order 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&#39;s a partner to free speech.=
. your free speech means that you don&#39;t have to say things you don&#39;=
t agree with, including platforming people who disagree with you or hate yo=
u outright. &quot;Coercive platforming&quot; happens when others demand you=
 platform their speech content even if it&#39;s off-topic or low signal or =
actively directly hostile to you. Meanwhile dev attention is scarce and whi=
le it&#39;s individually regulated (as it should be), care should be taken =
to monitor if the obvious default regulation is for developers to simply di=
sengage or not engage at all, which would be a detriment to the bitcoin pro=
ject. Instead we can filter the=C2=A0noise going into the system at the top=
 of the funnel instead of the bottom (comments level).<br><br>One goal is t=
hat we are interested in having more developers join and collaborate on Bit=
coin Core. Creating an environment conducive to new developers is important=
 and if they have to also be subjected to a bunch of noise just to collabor=
ate 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 developers or cont=
ributors.<br><br>What I think people might be upset about this idea to priv=
atize is that, to the extent that people perceive that they are currently a=
ble to coerce developers to work on specific things any given developer wou=
ldn&#39;t have worked on otherwise, and if any developer collaborations vol=
untarily retreat to their own private work area, then I think those same pe=
ople might get upset to the extent they perceive or feel that they are losi=
ng a coercive lever over developers that they previously thought they had (=
perhaps permanent) power over. In reality, it has always been a voluntary n=
on-coercive arrangement, it&#39;s just that people get confused about the s=
ocial dynamics and forget this isn&#39;t feudalism slave labor era anymore.=
<br><br><br><br># End of remarks<br><br>Building this sort of protection me=
asure 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 l=
evels 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 disrupt=
ing tens of trillions of dollars of value. And there are massive adversaria=
l forces, including nation state and non-state actors with tremendously dee=
p resources, that are completely adverse to what we stand for and what we b=
elieve and what bitcoin is or what bitcoin will become. These sorts of thre=
ats are completely unlike any other open source software project has ever s=
een, and if anything I am underestimating what we are up against. This isn&=
#39;t to say to throw out our values and enact bitcoin governance or whatev=
er; instead it&#39;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">https://www.lesswrong.com/posts/tscc3e5eujrsEeFN4/well-kept-gardens-di=
e-by-pacifism</a><br><a href=3D"https://meaningness.com/geeks-mops-sociopat=
hs" target=3D"_blank">https://meaningness.com/geeks-mops-sociopaths</a><br>=
<a href=3D"https://github.com/bitcoin-core/meta/issues/19" target=3D"_blank=
">https://github.com/bitcoin-core/meta/issues/19</a><br><a href=3D"https://=
x.com/kanzure/status/1932534820607045947" target=3D"_blank">https://x.com/k=
anzure/status/1932534820607045947</a><br><br>P.S. I still think bitcoin-cor=
e/meta on GH should be deleted. It&#39;s relatively recent and nothing of v=
alue will be lost that cannot be re-hosted should it ever prove necessary t=
o do so.<br></div><div><br></div><div dir=3D"ltr" class=3D"gmail_signature"=
></div></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" target=
=3D"_blank">bitcoindev+unsubscribe@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?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">https://=
groups.google.com/d/msgid/bitcoindev/CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLr=
oUJcPDZKsjB8w%40mail.gmail.com</a>.<br>
</blockquote></div><div><br clear=3D"all"></div><div><br></div><span class=
=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s=
ignature"><div dir=3D"ltr">I own <a href=3D"http://www.litmocracy.com" targ=
et=3D"_blank">Litmocracy</a> and <a href=3D"http://www.memeracing.net" targ=
et=3D"_blank">Meme Racing</a> (in alpha). <br>I&#39;m the webmaster for <a =
href=3D"http://www.voluntaryist.com" target=3D"_blank">The Voluntaryist</a>=
 which now accepts Bitcoin.<br>&quot;He ought to find it more profitable to=
 play by the rules&quot; - Satoshi Nakamoto</div></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/CAGLBAhePmsCcC1b0m5m-coqfMchqVFNNgqdyfkZosiRWt%2BnRow%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CAGLBAhePmsCcC1b0m5m-coqfMchqVFNNgqdyfkZosiRWt%2BnRow%40ma=
il.gmail.com</a>.<br />

--000000000000fd3e4306373fd7d4--