The Case for Decentralizing Bitcoin Core Development [was Re: [bitcoindev] The case for privatizing Bitcoin Core]

[Christopher Allen <ChristopherA@lifewithalacrity.com>]

In response to: https://groups.google.com/g/bitcoindev/c/43yjt8MXMvo

On Tue, Jun 10, 2025 at 1:40 PM Bryan Bishop <kanzure@gmail.com> wrote:
> The case for privatizing Bitcoin Core:

The concerns Bryan raised about coordination noise and GitHub's
moderation limitations are real. We've seen how open platforms without
clear boundaries invite persistent disruption — not just trolling, but
sustained efforts to derail meaningful technical collaboration.

But rather than framing this as a call for *privatization*, I think
it's more productive to view the problem through the lens of
*decentralization*. Git is already a distributed protocol — we should
be using it that way. We need infrastructure that supports secure,
accountable collaboration without relying on centralized gatekeepers,
corporate platforms, or closed offices.

## Git is Already Distributed — Let's Lean Into That

Git is a distributed version control system by design. In principle,
any developer or group of developers can work together on their own
forks, branches, or remotes — and coordinate externally from GitHub if
necessary. What we often lack is robust and usable *infrastructure*
for decentralized collaboration: systems that offer structure,
provenance, access control, and cryptographic guarantees, without
reverting to centralized or closed development.

## Open Source vs. Open Development

It’s also important to recognize that an open-source license alone is
insufficient for true "Open Development". Sustainable open development
depends not just on permissive licensing, but on values like
transparent governance, verifiable contributions, and non-coercive
collaboration. "Open Development" is a broader process that considers
who can participate, how trust is earned, and what incentives shape
behavior. These questions are especially vital in a high-stakes
project such as Bitcoin Core.

I've written an article on Open Development
https://www.blockchaincommons.com/articles/Open-Development/ that I
invite you to read as a parallel stream to this discussion.

## Transparency Is Not a Given — It’s a Design Decision

One criticism that has surfaced around Open Development is the idea
that Bitcoin Core developers have a "duty of transparency." But this
expectation is rarely defined. Is it a duty to publish *code*, to
explain *decisions*, to make *deliberations* public in real time — or
something else entirely?

If transparency is important to Bitcoin’s social contract, then we
should talk about what it actually entails, how it's balanced against
resilience, and where it begins and ends. Developers already meet
significant transparency obligations: reproducible builds, tagged
releases, and open review processes. That’s not nothing.

But assuming an *unlimited* or *unspecified* duty to perform
transparently — in every venue, at every stage — can easily become a
vector for coercion or burnout. Like every part of this system,
transparency needs intentional architecture, not moral ambiguity.

## A Proof-of-Concept: Open Integrity Project

I help maintain the [Open Integrity
Project](https://github.com/OpenIntegrityProject/core), which explores
how Git repositories can be used as cryptographic roots of trust. Our
work includes:

* "Inception Commits" to establish a verifiable origin.
* A signed `.allowed_commit_signers` policy to verify contributors.
* Future plans for branch distribution via Bittorrent's DHT,
FROST-based threshold signing, decentralized governance, and other
methods.

Open Integrity is *not a proposal for Bitcoin Core Developement*. But
it proves that decentralized coordination around open-source codebases
can be more secure, intentional, and resilient — while remaining
transparent and permissively licensed.

## Radicle and Other Directions

Radicle (https://radicle.xyz) is another working example. It shows
that peer-to-peer Git hosting and identity infrastructure are real and
usable today. It may not fit every contributor, but it makes clear
that **decentralization** — not privatization — is a viable and
thoughtful alternative to GitHub’s constraints.

## Structuring for Sovereignty

Public dev spaces come with power dynamics — and attackers exploit
them. We need tools and norms that protect developer autonomy without
killing transparency. That’s not impossible. But we have to build for
it, not assume it comes for free.

As I said, we shouldn't frame these transitions as “privatizing”
development, but we should instead focus on how to **structure
decentralized collaboration** more effectively — with clear
boundaries, strong tooling, and healthy expectations. Still open, but
designed to resist coercion and chaos.

Let’s explore optional decentralized spaces where trust is earned,
review is rigorous, and participation remains open — but under
conditions that developers can actually work within. No gates, just
better scaffolding.

-- Christopher Allen, Blockchain Commons

P.S. As context for those who don't know me: I've been working on
secure software since the early '90s — contributing to projects like
RSAREF (used by PGP, Digicash, and other early cryptographic tools),
SSLREF which led to TLS 1.0, and more recently the W3C DID 1.0 spec.
I’ve participated in and helped shape multiple open-source and
standards communities over the decades, including during my brief time
at Blockstream and now with Blockchain Commons. My long view informs
my belief that better tooling and clearer boundaries can preserve both
openness and resilience.

-- 
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/CACrqygAwod5_gM5Jqt15ZGsBA%2BorcOZ_r0J2%3DKPBN8%2BeTVnKqQ%40mail.gmail.com.