From: Bryan Bishop <kanzure@gmail•com>
To: Antoine Poinsot <darosior@protonmail•com>
Cc: bitcoindev@googlegroups.com, Bryan Bishop <kanzure@gmail•com>
Subject: Re: [bitcoindev] The case for privatizing Bitcoin Core
Date: Mon, 16 Jun 2025 12:36:24 -0500 [thread overview]
Message-ID: <CABaSBaxYfpKXb_P0y=Va=d8nbKO2H_T6_qGBzs1DvksLES3oSA@mail.gmail.com> (raw)
In-Reply-To: <4iW61M7NCP-gPHoQZKi8ZrSa2U6oSjziG5JbZt3HKC_Ook_Nwm1PchKguOXZ235xaDlhg35nY8Zn7g1siy3IADHvSHyCcgTHrJorMKcDzZg=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 7239 bytes --]
Hi,
On Sat, Jun 14, 2025 at 1:29 PM Antoine Poinsot <darosior@protonmail•com>
wrote:
> I started reading by speculating you were defending the case for something
> akin to a "source-available" Bitcoin Core. [... ]However you are not making
> the case for this, but for a private Bitcoin Core repository with a public
> mirror.
>
I will not claim I am an eloquent writer. In fact, Adam Back rightly points
out that some of my phrasing is deeply dumb: in one paragraph I started off
a chain of ORs of alternatives that began with publishing cut releases
instead of every incremental commit. I didn't mean to suggest Bitcoin Core
should only publish cut releases, only that it was an option that could be
supported by social coding tools. It was followed by a chain of "ORs" of
alternatives, and overall I could have worded that paragraph better. Oops.
> The public mirror would have comment threads on pull requests originating
> from the private repository and the possibility to open issues. It would
> essentially enable developer to opt into engaging on public comment threads
> (for bug reports, contentious pull requests 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, although it raises question
> with regard to its feasibility and the churn it could introduce (could the
> public mirror insert public comments within the synced private thread? or
> would it have to duplicate every single thread?).
>
All kinds of arrangements are possible, including bi-directional
synchronization, or one-way synchronization and pingbacks with "review"
before posting synced content internally, ... or many other options. It's
up to the developers using the tools to decide if they find them useful. It
could be beneficial for a variety of different private development tools to
exist and be tried by different devs. There likely isn't one workflow that
works best for everyone, instead a bunch of differentiated preferences or
ways about getting their work done.
> 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
> private discussions happening in the confines of a Bitcoin developer
> organization'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.
>
I don't know how to reply to this. I thought I had brought up offices as an
example of existing private development efforts that already exist and are
already more private than an online members-only social coding tool. To the
extent that "private development is bad" is a motivation to not do the
things I have suggested, then I wanted to point to offices as a trend that
already exists and highlight how members-only open source software
development is a better option for some of us and somewhat disproves
"private development is bad" is a blocking concern that e.g. somehow
prohibits private development. It doesn't.
> You also state that brigading would be severely reduced and eliminated.
> However it seems contrary to having publicly available comment threads? It
> would just contain the brigading to the publicly available comment threads.
> You could make the point that this containment would disincentivize the
> brigading in the first place, but it would only be the case if there is no
> expectation that the low-quality comments be taken into account in the
> decision making.
>
Great point. I should have said that brigadier intrusions into developer
spaces would be reduced or eliminated, not that all bitcoin-related
brigading on the Internet for all time would be eliminated, which is well
outside of my powers to enact or promise.
> I agree with your problem statement. I believe there is a dangerous
> perception 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 threats[^0] against developers. It is important to push back against
> this confusion,
>
I have toyed around with the idea of proposing changes to Bitcoin Core's
github repository to minimize the perception of prestige. I don't have a
great suggestion at the moment so I haven't posted publicly on this. I'm
also not sure if lowering perceived prestige is the right thing to do or if
that would be beneficial to bitcoin, Bitcoin Core, users of Bitcoin Core,
or its developers. For example, what if Bitcoin Core started merging random
ads and spam into the README?
> We just need to face the fact that Bitcoin Core is a centralized project.
> It has a central website, releases binaries and updates its software based
> on rough technical consensus. Bitcoin is decentralized, Bitcoin Core is not.
>
There are some aspects of Bitcoin Core that are centralized, such as the
domain name registration, or the GitHub org, where unambiguously some
specific people have control of a project resource. Many other project
resources including a great number of volunteers freely allocate their time
and resources to help write and review code, propose changes, or otherwise
move the project forward with minimal coordination and no central control
over those people. Arguably a lot of the value of Bitcoin Core is from
those contributors.
To the extent that Bitcoin Core is centralized, then bitcoiners ought to be
thoughtful about the ways in which it is centralized (or not) and the
design goals should be the result of careful strategy or thinking.
Strengthening the decentralized aspects, or increasing decentralized
aspects, of the Bitcoin Core project may be prudent, depending on the
design goals. Based on other replies in this thread it may be possible to
achieve exclusive developer spaces by increasing decentralization for
Bitcoin Core with systems like Radicle or other social coding tools. I
guess depending on how you squint some might call that increasing the
centralization (proliferation of independent but private collaboration
spaces) or others might call it decentralization (anyone can fork/mirror
write-privately spaces). And this might even help people avoid incorrectly
seeing Bitcoin Core's centralized aspects as Bitcoin being centralized.
> Setting expectations that misinformed rants and conspiracy theories will
> be considered at all in deciding whether code should be changed is entirely
> self-inflicted and does not need a change in the project structure to
> correct.
>
- Bryan
https://x.com/kanzure
--
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/CABaSBaxYfpKXb_P0y%3DVa%3Dd8nbKO2H_T6_qGBzs1DvksLES3oSA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 9393 bytes --]
next prev parent reply other threads:[~2025-06-16 22:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-10 20:31 Bryan Bishop
2025-06-10 23:13 ` Dave Scotese
2025-06-11 8:38 ` [bitcoindev] " Michael Folkson
2025-06-12 16:45 ` The Case for Decentralizing Bitcoin Core Development [was Re: [bitcoindev] The case for privatizing Bitcoin Core] Christopher Allen
2025-06-14 18:29 ` [bitcoindev] The case for privatizing Bitcoin Core 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-06-16 17:36 ` Bryan Bishop [this message]
2025-06-15 16:14 ` Andrew Poelstra
2025-06-16 15:14 ` waxwing/ AdamISZ
2025-06-16 16:09 ` Bryan Bishop
2025-06-16 16:53 ` waxwing/ AdamISZ
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABaSBaxYfpKXb_P0y=Va=d8nbKO2H_T6_qGBzs1DvksLES3oSA@mail.gmail.com' \
--to=kanzure@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
--cc=darosior@protonmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox