Subject: [bitcoindev] The case for privatizing Bitcoin Core

From: Bryan Bishop <[email-masked]>
Date: Tue, 10 Jun 2025 15:31:07 -0500

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 on
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 deep
technical content can cause confusion or misunderstanding for non-technical
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 and
thankfully 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
whatever our hearts desire, and we can freely do that over the Internet or
in person on any project we see fit. Many of us choose to work on Bitcoin.
Some of us choose to work on Bitcoin Core. It is an entirely voluntary
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 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 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 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 be
a platform for inflicting coercive beliefs upon developers that have gifted
us so much time, energy and efforts on a historically and systemically
critical 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
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 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
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 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 comments licensing. Pull 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 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 also
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 project
that so much gets discussed inside these private offices and many of us are
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 the
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 request
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, contributors
would likely push changes out to various public access githubs or other
locations 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 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
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 they
still will behave using the same norms and beliefs and systems that they
presently do. Public code review will still continue. Public releases 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
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 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 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 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 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'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, while
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 direction.
It merely carves out a specific space and area.

Something along 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 coercive demands that *we* be the ones to create the
exact software of your choosing. We hope that you like the software we work
on, and we welcome your feedback in the 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 not
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 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 subjected 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...

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 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 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 or
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 in
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 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.

# 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 dollar
system. We are talking about disrupting tens of trillions of dollars of
value. And there are massive adversarial forces, including nation state and
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 any
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 our
values and enact 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-by-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 [email-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w%40mail.gmail.com.