path: root/fa/417720e1b161370c99face3afccb843043f4d7

Delivery-date: Wed, 11 Jun 2025 17:02:16 -0700
Received: from mail-yw1-f190.google.com ([209.85.128.190])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCYNLXGV3AMRB65RVDBAMGQECWONIWY@googlegroups.com>)
	id 1uPVOX-0000ya-L7
	for bitcoindev@gnusha.org; Wed, 11 Jun 2025 17:02:16 -0700
Received: by mail-yw1-f190.google.com with SMTP id 00721157ae682-710e75f9229sf5737887b3.2
        for <bitcoindev@gnusha.org>; Wed, 11 Jun 2025 17:02:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1749686527; x=1750291327; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=eZUIyex1pnI0D+fUcau3Bv3/D4Q4lPmjOwx9c5Lmyt8=;
        b=IiXhu23IM5+u1PXCh95m2y1cSOnm6cPM5oflfK2rnOCHJF+5afWqUQHzGXmU8xWz+m
         uu6XStZXoqlO/SkH/CaS3IDaS2D3NQ/GTc5mezjYiwfPLOPjTKUJHg2wGWt1RAiGXYdO
         crygtxlKMOTjIKX9nfoe8MaRI90SIP/K9QeznyYBBbUg1e37JgttMYBvz8U5r69W2zVA
         OLjTaf/V1gqw7BvdzGOvqJpBitbIboBmoLHXTlC+E8n5jcCNPnwEqXDVCQ8sXU1nIbn5
         lOsQoSkC0tpYkYl1e28rripqtQClreHkdR6Gx9dcYgY5RLlZ1PPHxsgk1Ig3Y5s/4ReW
         F7kQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.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-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=eZUIyex1pnI0D+fUcau3Bv3/D4Q4lPmjOwx9c5Lmyt8=;
        b=dZJUFBQqpVX7u8taSFqpn8soRp4xR+z+W4NH45G42yl0VWE3tLqGdoVlEVy2ZS/eEP
         8LwYKLO3xBCnhQJUvVaos7M2OYGjSJIV2k0S9cYHEEOy7ZlKOiGDxR40U8Dk2pMx8XhF
         MIxbJNPMqIL9KtWpBI2DJCqf31MLDksbxdR8ORMYATjhkx/vQt02x1JWnoz+PexFZF6V
         NdcUrpcvAA9o3BDKoP7/zNDz9LGR0C/tvFznM5TQyotm3VMtJN4dBYClqFmGT49WIeAF
         MBEnfQUuP35SnlL/U6zgZds40eD26Isgp1Cn3JiRPK+JRBqTPTEKN++hfDP2Dakj1WQc
         4Bhw==
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-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=eZUIyex1pnI0D+fUcau3Bv3/D4Q4lPmjOwx9c5Lmyt8=;
        b=W/5W9Ea+ClXcqESvo8KEvUMTUnOZraVOYNsUYUCJ8nQQsBTJnwvXXFc4t47nMeMhpF
         nrGrGs5pZck04ap5LpEI5KtV/ZYhf1BqNRSsNRSqV0iPR7kolsimC6iAUVQNsPDufZQs
         VTG1inoutRHfxoblRhkmLbRYvn3ENGNPdBu92Z8EK6RrOk37ZvFsWi/OtWjmjK4opWGI
         gTACWNO3OkPaEb9sSL/U0nlRsvHHH2w918mMkx82to7+PsTAII/9zH5JCjLIZaSiPzYm
         bou8FzN6BAx+fVrotB4mG6G1FbynbuvsFPcFKfGvwvkWK1NFxhKH+dLHkrDxc+RpFoGE
         Sceg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCVamXVGfokv3kFUkCVjHx9hITs6b8ohunSJOcOUhjYpr+444VKA5Xj67EXHMKCrwawTsP6japqAsjod@gnusha.org
X-Gm-Message-State: AOJu0Yyyw3mvVkx6evTJeQ97iz/immMPbWt0+AxpxEcpt5wyqhKO4UYW
	XmH/UmurLWaKEAg4JH+iP0aZu/0xJlHbrtSm4QM3g2vAE6IsK2GHo+33
X-Google-Smtp-Source: AGHT+IHfhE/XbS+LJiisgDwaQmQwtw1OndsgvloeNUfjyUz6MF4aoR/35YiKoPoPEuZV5x7YeKvLEw==
X-Received: by 2002:a05:6902:18d6:b0:e81:9c45:a97e with SMTP id 3f1490d57ef6-e820b6e5ccemr2442362276.38.1749686527421;
        Wed, 11 Jun 2025 17:02:07 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZepeBo3zxQgTYjvHmPGmiau6rMLI28QY7NQlMOAP3pm7g==
Received: by 2002:a25:c03:0:b0:e7d:cffc:6b5 with SMTP id 3f1490d57ef6-e820dab3116ls320543276.1.-pod-prod-04-us;
 Wed, 11 Jun 2025 17:02:02 -0700 (PDT)
X-Received: by 2002:a05:690c:46c4:b0:70c:d322:872c with SMTP id 00721157ae682-7114ec468f8mr29099137b3.1.1749686522626;
        Wed, 11 Jun 2025 17:02:02 -0700 (PDT)
Received: by 2002:a05:690c:26c6:b0:710:fccf:6901 with SMTP id 00721157ae682-711414346b7ms7b3;
        Wed, 11 Jun 2025 01:38:19 -0700 (PDT)
X-Received: by 2002:a05:690c:23c5:b0:70a:192d:122 with SMTP id 00721157ae682-711424d2357mr26038307b3.30.1749631097835;
        Wed, 11 Jun 2025 01:38:17 -0700 (PDT)
Date: Wed, 11 Jun 2025 01:38:17 -0700 (PDT)
From: Michael Folkson <michaelfolkson@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <daf2b47a-eff6-42ab-891b-a15f9f9fcd85n@googlegroups.com>
In-Reply-To: <CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w@mail.gmail.com>
References: <CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w@mail.gmail.com>
Subject: [bitcoindev] Re: The case for privatizing Bitcoin Core
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_30384_1592964251.1749631097312"
X-Original-Sender: michaelfolkson@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.5 (/)

------=_Part_30384_1592964251.1749631097312
Content-Type: multipart/alternative; 
	boundary="----=_Part_30385_1217564831.1749631097312"

------=_Part_30385_1217564831.1749631097312
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Bryan

Thanks for your email and thanks for maintaining an archive of the=20
bitcoin-dev mailing list.

I'm personally sympathetic with a lot of this with one significant caveat.=
=20
I've stated this caveat multiple times before ([0], [1], [2] etc) but I=20
will state it again because it is critically important and people who=20
really should know better (not necessarily you) should have understood and=
=20
accepted this by now.

A consensus rule change is different to any other change (transaction relay=
=20
policy, wallet, GUI, test etc). If consensus compatible forks of Bitcoin=20
Core want to maintain different mempool policies, wallet features, GUIs etc=
=20
they are free to with no chain split risk assuming they don't accidentally=
=20
introduce a consensus bug which Core has made as easy to avoid as possible=
=20
over the years. Hence we have seen Knots, Libre Relay etc introduce=20
different mempool policies to Core without a chain split or a split of the=
=20
network. The recent statement by Core stating what its current contributors=
=20
prioritize when designing transaction relay policy [3] and the=20
communication around the recent transaction relay policy pull request=20
(#32404) merge decision [4] I thought was excellent. However to take that=
=20
precedent on Core *transaction relay policy* (a signed statement by a set=
=20
of Core contributors and signposting around the merge decision) and assume=
=20
it can be applied to a *consensus rule change* (CTV and CSFS or whatever=20
the current set of opcodes is currently in vogue) requesting Core=20
contributors prioritize review within 6 months is short sighted to put it=
=20
mildly. Core can make unilateral decisions on transaction policy because=20
consensus compatible forks can have different transaction policy without=20
splitting the chain or the network. It can't make unilateral decisions on a=
=20
consensus rule change. If there is significant disagreement on a consensus=
=20
rule change an attempted consensus rule change can split the network and=20
create two currencies.=20

Hence if Core wants to make merge decisions on transaction relay policy=20
pull requests based on its recent statement I think that is fine. If it=20
wants to hide comments on such a pull request that don't accept that=20
statement I think that is fine. But if it wants to create a set of=20
contributors who think they can effectively decide on consensus rule=20
changes without the input of the broader community that is clearly not=20
fine.=20

There is a secondary issue that in a world of consensus compatible forks=20
Core really shouldn't make maintaining those consensus compatible forks=20
unnecessarily difficult or impossible. If users disagree with that=20
aforementioned transaction relay statement for example but Core also makes=
=20
merge decisions that makes maintaining consensus compatible forks=20
unnecessarily difficult or impossible then those users have nowhere to go.=
=20
In that sense Core is shaping up to effectively be like the Linux kernel=20
and however the project is managed in the repo it needs to be monitoring=20
and engaging with consensus compatible forks.=20

Thanks
Michael

[0]: https://gnusha.org/pi/bitcoindev/LmX3Gnfkf1T0Eb_wUXxPe8c0Tf2DNipfIqufk=
RS6oOPhttr4iZIOWtjUL_7QkcWEHr8eFvehHooaM140ZBKLwi98F5NwyQKSyEhAPZDK1YQ=3D@p=
rotonmail.com/
[1]: https://gnusha.org/pi/bitcoindev/XuO20TMFGBqz53WYWxi9bgAdB3iGmqEIUE84A=
upRxCpHQVd3-YbGVzZUFz21dOgb_AgwlGWaruzE8NGxhes6HCKHpRZLmL1d1kNu1yobAIU=3D@p=
rotonmail.com/
[2]: https://gnusha.org/pi/bitcoindev/uuq_VbxJp50_-m4ufKpEhJOknhZ0pvK8ioDab=
CkxtDjBYauO3gLKrj2O2tjS6YIFOnJLyaZg6-LENzom1DyQQ3TyMLIIaGz5IRrzrKB8gRs=3D@p=
rotonmail.com/
[3]: https://bitcoincore.org/en/2025/06/06/relay-statement/
[4]: https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2955614286



On Tuesday, June 10, 2025 at 11:40:15=E2=80=AFPM UTC+3 Bryan Bishop wrote:

> The case for privatizing Bitcoin Core:
>
> I believe that reflection is critical for curiosity, understanding,=20
> improvement, and progress. And recent activity on the Bitcoin Core github=
=20
> account has given me an opportunity to re-evaluate my beliefs about=20
> open-source software development on GitHub.
>
>
> # The ongoing problem
>
> What happened was nothing new. It has happened before and it will happen=
=20
> again, especially if we do nothing new or different. Essentially there is=
 a=20
> recurring pattern of non-contributors (sometimes even non-developers)=20
> intruding into an online forum intended mainly for people collaborating o=
n=20
> Bitcoin Core to work together on whatever they are working on. This often=
=20
> causes issues like wasting people's valuable time, creating manufactured=
=20
> controversy, misinformation, etc. It is trivial to see how exposure to de=
ep=20
> technical content can cause confusion or misunderstanding for non-technic=
al=20
> people who may not even know the ethos of open-source development or what=
=20
> bitcoin developers really do or believe about what they do. Unsolicited=
=20
> feedback from random/new people and even noise can sometimes be useful an=
d=20
> thankfully it's impossible to eliminate online forums for providing that,=
=20
> 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=20
> whatever our hearts desire, and we can freely do that over the Internet o=
r=20
> in person on any project we see fit. Many of us choose to work on Bitcoin=
.=20
> Some of us choose to work on Bitcoin Core. It is an entirely voluntary=20
> effort and nobody owes any obligation to anyone else but to themselves.=
=20
> Indeed, even non-developer bitcoiners are not obligated, like they are no=
t=20
> obligated to run code written by people they find disagreeable if for som=
e=20
> reason they cannot find sufficient reason to not run code in the code=20
> itself.
>
> You can argue there might be ethical or moral obligations created by=20
> working on open-source software, beyond those created by the license, but=
 I=20
> don't buy that argument. There are no additional explicit obligations=20
> beyond the license. I'll add, though, that many developers have their own=
=20
> moral values and beliefs about how they should act and behave, and how th=
at=20
> informs who they choose to collaborate with, which is great! Many believe=
=20
> they have a personal moral value of informing uneducated people, or=20
> protecting people from security threats, or hundreds of other particular=
=20
> preferences and opinions. All of these are fantastic and I am glad these=
=20
> preferences or beliefs exist... but they cannot be coercively applied and=
=20
> we should not allow the bitcoin project, or Bitcoin Core, or github, to b=
e=20
> a platform for inflicting coercive beliefs upon developers that have gift=
ed=20
> us so much time, energy and efforts on a historically and systemically=20
> critical development.
>
> Therefore, I think there might be an opportunity here to re-evaluate the=
=20
> nature of open-source software development. I think there is an opportuni=
ty=20
> to re-evaluate how we choose to work together. What if there was a better=
=20
> way to collaborate on the work we do for bitcoin? What would it look like=
?=20
> What would be different? What would be kept the same?
>
>
> # GitHub
>
> Unfortunately the situation is that GitHub does not have good moderation=
=20
> controls and was only built for a very narrow concept of open source=20
> development. The solution to brigading is better controls around the=20
> presentation layer or requiring some sort of membership. If you just have=
 a=20
> perpetual open door policy straight from reddit into your developer den,=
=20
> then yeah people are going to walk in and take a shit on your desk where=
=20
> you were working with another dev.. With some thinking I'm sure we can=20
> structure better ways to get exposure to general public sentiment or=20
> opinion, while also structuring a space for development to take place tha=
t=20
> 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=
=20
> development into a members-only gitlab or other kind of open-source=20
> software collaboration system. It would have the following properties.=20
> Issues and pull requests would be private and not subject to public=20
> hyperlinking. Anyone can register or apply for access. Whoever runs the=
=20
> site/repository would be responsible for configuration, hosting, setup,=
=20
> moderation, access control, etc. Software development would continue unde=
r=20
> the same license. New issues, comments, code review comments would possib=
ly=20
> be licensed under a specific license like CC0 or public domain or some=20
> other license, possibly with PGP-signature to track agreement if we care=
=20
> about comments licensing. Pull requests can be cross-posted to any number=
=20
> of repositories either public or private as much as any contributor wishe=
s,=20
> except to the point where any norm violation or spam violation occurs for=
=20
> the respective publishing systems of course.
>
>
> # Office culture
>
> An alternative to what I am proposing is already happening: development=
=20
> inside closed offices (Chaincode, Brink, Localhost, etc), which is less=
=20
> accessible and less open than a invite-only developer collab site. And al=
so=20
> less "open development" than the current Bitcoin Core GitHub project. So =
a=20
> failure to sort out these issues with Bitcoin Core collaboration can and=
=20
> has already produced solutions that are functionally less inclusive than =
an=20
> online member-only source forge. It is to the detriment of the open proje=
ct=20
> that so much gets discussed inside these private offices and many of us a=
re=20
> not able to contribute that way, and there ought to be something between =
a=20
> public github that the general public can brigade and closed offices on t=
he=20
> other end of the spectrum.
>
>
> # How it would work
>
> Contributors would be free to collaborate on any branch, pull request, or=
=20
> privatized fork, or even public fork. Issues, issue comments, pull reques=
t=20
> comments, code review comments, and miscellaneous discussions can also be=
=20
> posted internally. Code can come from inside the members-only repository,=
=20
> or it can be contributed from outside sources if someone pulls it in,=20
> proposes it, or otherwise posts those patches.
>
> Releases can be cut and source code published all at once, if that is=20
> desirable to anyone. However, I suspect that for Bitcoin Core, contributo=
rs=20
> would likely push changes out to various public access githubs or other=
=20
> locations on an hourly, daily or regular basis. Bitcoin Core, as it exist=
s=20
> today, could do the same for pull requests, code review comments, etc, an=
d=20
> post them publicly on a website. Anyone would be free to make a website=
=20
> where any person, including non-developers and including non-contributors=
,=20
> could freely post code review or comments. This could even happen on the=
=20
> current GH bitcoin/bitcoin repository. For example, any of the private co=
de=20
> review comments can be posted directly into the PR on GH. PGP signatures=
=20
> can be used for verifiable comment attribution. Or another website can be=
=20
> linked from a GH PR to display the private-originated review history.
>
> Brigading will be severely reduced and eliminated. You can pass around a=
=20
> link to the repository and a comment or issue but nobody will be able to=
=20
> see the content unless they are a registered member, which the vast=20
> majority of all internet people won't be. This will severely curtail=20
> brigading and spam while also enabling continued ongoing development=20
> activities for collaborators.
>
> Bitcoin Core itself has releases and maintainers that push the release=20
> button. I fully believe that even after privatizing Bitcoin Core that the=
y=20
> still will behave using the same norms and beliefs and systems that they=
=20
> presently do. Public code review will still continue. Public releases wil=
l=20
> still happen. There will still be open source code. But the ability of=20
> attackers to steal attention or time from bitcoin developers will be=20
> severely reduced. Likewise for attackers ability to coerce bitcoin=20
> developers through public spectacle where they do their core work. I=20
> believe that the community would be more productive and more energized if=
=20
> we regularly used a privatized collaboration platform.
>
> In practice, the way that this would roll out is that the GitHub would=20
> continue to be the GitHub and would not really change. There would be a=
=20
> separate private area for some developers to work together. Then they wou=
ld=20
> throw it over the wall or have some sort of (possibly real-time)=20
> synchronization protocol to synchronize pull requests to the public GitHu=
b=20
> repository. If you want a public link on X.com then link to that, but a=
=20
> link to the membership-required site won't work for non-members.
>
> For the private work space: I think registration, coupled with a delay,=
=20
> coupled with a probationary period would probably be sufficient. Possibly=
=20
> also with review or, what could be interesting as if at least two people=
=20
> out of any of the members have to recommend the user for entry. Or, you c=
an=20
> do proof-of-work to get entry and post something, and it's subject to=20
> moderator review until 2-of-n approve your membership? I would advocate f=
or=20
> very strong norms as to moderation and rules of engagement such as, if yo=
u=20
> just show up to cause chaos then you lose your access to the members-only=
=20
> place and you will have to post code somewhere else on the internet. It=
=20
> won't be that anyone can show up and cause chaos and never be silenced or=
=20
> banned.
>
> Adoption: would not be too difficult, as only two or three developers can=
=20
> privately experience some benefits. They can also use private one-time=20
> expiring links to temporarily include non-members as they see fit.
>
>
> # Theory crafting
>
> Non-technical activist movements have a history of making open discussion=
=20
> forums non-viable. Those same non-technical activist movements also have =
a=20
> history of making many non-viable forks, due to for example a lack of=20
> technical expertise in said movements. I would like to find ways to=20
> redirect efforts that would manifest as unusable discussion forums,=20
> instead, towards the creation of more non-viable forks.
>
> We can remain committed to making forking as frictionless as we can, whil=
e=20
> also increasing the friction of participation of non-technical actors in=
=20
> members-only technical discussion forums. The existence of members-only=
=20
> technical discussion forums does not preclude the existence of public=20
> channels, nor does it prohibit the flow of information in either directio=
n.=20
> It merely carves out a specific space and area.
>
> Something along the lines of: "We are willing to commit to your freedom t=
o=20
> create and run software of your choosing. We are not committed to=20
> internalizing often coercive demands that *we* be the ones to create the=
=20
> exact software of your choosing. We hope that you like the software we wo=
rk=20
> on, and we welcome your feedback in the right time and place, just not in=
=20
> private developer spaces."
>
> Open source software has a lot of history behind it and established=20
> developer culture norms. Open here usually refers to the source code=20
> licensing (see early 90s work from Foresight Institute's Christine=20
> Peterson's Open Source Definition initiative). "Open" development does no=
t=20
> mean "open to coercion". It feels very weird to write an email that=20
> essentially amounts to reminding grown adults that they can freely=20
> collaborate in any way they wish, and that they do not have to invite or=
=20
> subject themselves to active ongoing attempts of coercion. Even if it's=
=20
> from "the public". There are free-for-all places all over the Internet to=
=20
> post that kind of content, or to read it and review it. There are also=20
> other possibilities for structured access and presentation of that kind o=
f=20
> data. For example, a reverse Bitcoin Optech that curates that sort of=20
> information from around the web. I suspect that over time what has happen=
ed=20
> is that of the people who refuse to be subjected to coercion attempts fro=
m=20
> internet mobs have simply left the public collaboration process to either=
=20
> retreat into office in-person settings or stop contributing to bitcoin=20
> development entirely...
>
> Also, it does not feel good to ban people or clean up brigades to restore=
=20
> structure or order etc. which is partly why some core contributors have=
=20
> been so hesitant to hit the GH moderation buttons more often, plus many o=
f=20
> us just wanna code or build cool stuff. It's a partner to free speech..=
=20
> your free speech means that you don't have to say things you don't agree=
=20
> with, including platforming people who disagree with you or hate you=20
> outright. "Coercive platforming" happens when others demand you platform=
=20
> their speech content even if it's off-topic or low signal or actively=20
> directly hostile to you. Meanwhile dev attention is scarce and while it's=
=20
> individually regulated (as it should be), care should be taken to monitor=
=20
> if the obvious default regulation is for developers to simply disengage o=
r=20
> not engage at all, which would be a detriment to the bitcoin project.=20
> Instead we can filter the noise going into the system at the top of the=
=20
> funnel instead of the bottom (comments level).
>
> One goal is that we are interested in having more developers join and=20
> collaborate on Bitcoin Core. Creating an environment conducive to new=20
> developers is important and if they have to also be subjected to a bunch =
of=20
> noise just to collaborate on code on GitHub then I think that is=20
> sub-optimal and a self-defeating strategy if one of the goals is growth i=
n=20
> the number of developers or contributors.
>
> What I think people might be upset about this idea to privatize is that,=
=20
> to the extent that people perceive that they are currently able to coerce=
=20
> developers to work on specific things any given developer wouldn't have=
=20
> worked on otherwise, and if any developer collaborations voluntarily=20
> retreat to their own private work area, then I think those same people=20
> might get upset to the extent they perceive or feel that they are losing =
a=20
> coercive lever over developers that they previously thought they had=20
> (perhaps permanent) power over. In reality, it has always been a voluntar=
y=20
> non-coercive arrangement, it's just that people get confused about the=20
> 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=
=20
> future success of the project. As a moderator in the bitcoin-dev project =
it=20
> is hard for me to communicate the levels of attacks that we have seen and=
=20
> that I expect to see going forward. We are talking about a trillion dolla=
r=20
> system. We are talking about disrupting tens of trillions of dollars of=
=20
> value. And there are massive adversarial forces, including nation state a=
nd=20
> non-state actors with tremendously deep resources, that are completely=20
> adverse to what we stand for and what we believe and what bitcoin is or=
=20
> what bitcoin will become. These sorts of threats are completely unlike an=
y=20
> other open source software project has ever seen, and if anything I am=20
> underestimating what we are up against. This isn't to say to throw out ou=
r=20
> values and enact bitcoin governance or whatever; instead it's an=20
> opportunity to look at what tools we have at our disposal to counter thes=
e=20
> threats and ensure our continued productivity and that our open community=
=20
> 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=20
> relatively recent and nothing of value will be lost that cannot be=20
> re-hosted should it ever prove necessary to do so.
>
>

--=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/=
daf2b47a-eff6-42ab-891b-a15f9f9fcd85n%40googlegroups.com.

------=_Part_30385_1217564831.1749631097312
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Bryan<div><br /></div><div>Thanks for your email and thanks for maintain=
ing an archive of the bitcoin-dev mailing list.<br /><div><br /></div><div>=
I'm personally sympathetic with a lot of this with one significant caveat. =
I've stated this caveat multiple times before ([0], [1], [2] etc) but I wil=
l state it again because it is critically important and people who really s=
hould know better (not necessarily you) should have understood and accepted=
 this by now.</div><div><br /></div><div>A consensus rule change is differe=
nt to any other change (transaction relay policy, wallet, GUI, test etc). I=
f consensus compatible forks of Bitcoin Core want to maintain different mem=
pool policies, wallet features, GUIs etc they are free to with no chain spl=
it risk assuming they don't accidentally introduce a consensus bug which Co=
re has made as easy to avoid as possible over the years. Hence we have seen=
 Knots, Libre Relay etc introduce different mempool policies to Core withou=
t a chain split or a split of the network. The recent statement by Core sta=
ting what its current contributors prioritize when designing transaction re=
lay policy [3] and the communication around the recent transaction relay po=
licy pull request (#32404) merge decision [4] I thought was excellent. Howe=
ver to take that precedent on Core *transaction relay policy* (a signed sta=
tement by a set of Core contributors and signposting around the merge decis=
ion) and assume it can be applied to a *consensus rule change* (CTV and CSF=
S or whatever the current set of opcodes is currently in vogue) requesting =
Core contributors prioritize review within 6 months is short sighted to put=
 it mildly. Core can make unilateral decisions on transaction policy becaus=
e consensus compatible forks can have different transaction policy without =
splitting the chain or the network. It can't make unilateral decisions on a=
 consensus rule change. If there is significant disagreement on a consensus=
 rule change an attempted consensus rule change can split the network and c=
reate two currencies.=C2=A0</div><div><br /></div><div>Hence if Core wants =
to make merge decisions on transaction relay policy pull requests based on =
its recent statement I think that is fine. If it wants to hide comments on =
such a pull request that don't accept that statement I think that is fine. =
But if it wants to create a set of contributors who think they can effectiv=
ely decide on consensus rule changes without the input of the broader commu=
nity that is clearly not fine.=C2=A0</div><div><br /></div><div>There is a =
secondary issue that in a world of consensus compatible forks Core really s=
houldn't make maintaining those consensus compatible forks unnecessarily di=
fficult or impossible. If users disagree with that aforementioned transacti=
on relay statement for example but Core also makes merge decisions that mak=
es maintaining consensus compatible forks unnecessarily difficult or imposs=
ible then those users have nowhere to go. In that sense Core is shaping up =
to effectively be like the Linux kernel and however the project is managed =
in the repo it needs to be monitoring and engaging with consensus compatibl=
e forks.=C2=A0</div><div><br /></div><div>Thanks</div><div>Michael</div><di=
v><br /></div><div>[0]:=C2=A0https://gnusha.org/pi/bitcoindev/LmX3Gnfkf1T0E=
b_wUXxPe8c0Tf2DNipfIqufkRS6oOPhttr4iZIOWtjUL_7QkcWEHr8eFvehHooaM140ZBKLwi98=
F5NwyQKSyEhAPZDK1YQ=3D@protonmail.com/</div><div>[1]:=C2=A0https://gnusha.o=
rg/pi/bitcoindev/XuO20TMFGBqz53WYWxi9bgAdB3iGmqEIUE84AupRxCpHQVd3-YbGVzZUFz=
21dOgb_AgwlGWaruzE8NGxhes6HCKHpRZLmL1d1kNu1yobAIU=3D@protonmail.com/</div><=
div>[2]:=C2=A0https://gnusha.org/pi/bitcoindev/uuq_VbxJp50_-m4ufKpEhJOknhZ0=
pvK8ioDabCkxtDjBYauO3gLKrj2O2tjS6YIFOnJLyaZg6-LENzom1DyQQ3TyMLIIaGz5IRrzrKB=
8gRs=3D@protonmail.com/</div><div>[3]:=C2=A0https://bitcoincore.org/en/2025=
/06/06/relay-statement/</div><div>[4]:=C2=A0https://github.com/bitcoin/bitc=
oin/pull/32406#issuecomment-2955614286</div><div><br /></div><div><br /></d=
iv><div><br /></div></div><div class=3D"gmail_quote"><div dir=3D"auto" clas=
s=3D"gmail_attr">On Tuesday, June 10, 2025 at 11:40:15=E2=80=AFPM UTC+3 Bry=
an Bishop wrote:<br/></div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1e=
x;"><div dir=3D"ltr"><div>The case for privatizing Bitcoin Core:<br><br>I b=
elieve that reflection is critical for curiosity, understanding, improvemen=
t, and progress. And recent activity on the Bitcoin Core github account has=
 given me an opportunity to re-evaluate my beliefs about open-source softwa=
re development on GitHub.<br><br><br># The ongoing problem<br><br>What happ=
ened was nothing new. It has happened before and it will happen again, espe=
cially 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 li=
ke wasting people&#39;s valuable time, creating manufactured controversy, m=
isinformation, etc. It is trivial to see how exposure to deep technical con=
tent can cause confusion or misunderstanding for non-technical people who m=
ay not even know the ethos of open-source development or what bitcoin devel=
opers really do or believe about what they do. Unsolicited feedback from ra=
ndom/new people and even noise can sometimes be useful and thankfully it&#3=
9;s impossible to eliminate online forums for providing that, but here I&#3=
9;m specifically focusing on areas intended for dev collaboration.<br><br>W=
hat we want as developers is to collaborate with whoever we wish on whateve=
r our hearts desire, and we can freely do that over the Internet or in pers=
on 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 n=
on-developer bitcoiners are not obligated, like they are not obligated to r=
un code written by people they find disagreeable if for some reason they ca=
nnot 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=
 open-source software, beyond those created by the license, but I don&#39;t=
 buy that argument. There are no additional explicit obligations beyond the=
 license. I&#39;ll add, though, that many developers have their own moral v=
alues and beliefs about how they should act and behave, and how that inform=
s who they choose to collaborate with, which is great! Many believe they ha=
ve a personal moral value of informing uneducated people, or protecting peo=
ple from security threats, or hundreds of other particular preferences and =
opinions. All of these are fantastic and I am glad these preferences or bel=
iefs 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 infl=
icting coercive beliefs upon developers that have gifted us so much time, e=
nergy and efforts on a historically and systemically critical development.<=
br><br>Therefore, I think there might be an opportunity here to re-evaluate=
 the nature of open-source software development. I think there is an opport=
unity to re-evaluate how we choose to work together. What if there was a be=
tter way to collaborate on the work we do for bitcoin? What would it look l=
ike? What would be different? What would be kept the same?<br><br><br># Git=
Hub<br><br>Unfortunately the situation is that GitHub does not have good mo=
deration controls and was only built for a very narrow concept of open sour=
ce development. The solution to brigading is better controls around the pre=
sentation layer or requiring some sort of membership. If you just have a pe=
rpetual 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 we=
re working with another dev.. With some thinking I&#39;m sure we can struct=
ure better ways to get exposure to general public sentiment or opinion, whi=
le also structuring a space for development to take place that does not req=
uire blindly mixing off-topic content with developer content.<br><br><br># =
Privatization<br><br>Here, I would like to make the case for privatizing Bi=
tcoin Core software development into a members-only gitlab or other kind of=
 open-source software collaboration system. It would have the following pro=
perties. Issues and pull requests would be private and not subject to publi=
c hyperlinking. Anyone can register or apply for access. Whoever runs the s=
ite/repository would be responsible for configuration, hosting, setup, mode=
ration, 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 l=
icense, possibly with PGP-signature to track agreement if we care about com=
ments licensing. Pull requests can be cross-posted to any number of reposit=
ories either public or private as much as any contributor wishes, except to=
 the point where any norm violation or spam violation occurs for the respec=
tive publishing systems of course.<br><br><br># Office culture<br><br>An al=
ternative to what I am proposing is already happening: development inside c=
losed offices (Chaincode, Brink, Localhost, etc), which is less accessible =
and less open than a invite-only developer collab site. And also less &quot=
;open development&quot; than the current Bitcoin Core GitHub project. So a =
failure to sort out these issues with Bitcoin Core collaboration can and ha=
s already produced solutions that are functionally less inclusive than an o=
nline 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 th=
e other end of the spectrum.<br><br><br># How it would work<br><br>Contribu=
tors would be free to collaborate on any branch, pull request, or privatize=
d fork, or even public fork. Issues, issue comments, pull request comments,=
 code review comments, and miscellaneous discussions can also be posted int=
ernally. Code can come from inside the members-only repository, or it can b=
e 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 p=
ublished all at once, if that is desirable to anyone. However, I suspect th=
at for Bitcoin Core, contributors would likely push changes out to various =
public access githubs or other locations on an hourly, daily or regular bas=
is. 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 woul=
d 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 exampl=
e, 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-originat=
ed review history.<br><br>Brigading will be severely reduced and eliminated=
. You can pass around a link to the repository and a comment or issue but n=
obody 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 seve=
rely curtail brigading and spam while also enabling continued ongoing devel=
opment activities for collaborators.<br><br>Bitcoin Core itself has release=
s and maintainers that push the release button. I fully believe that even a=
fter privatizing Bitcoin Core that they still will behave using the same no=
rms and beliefs and systems that they presently do. Public code review will=
 still continue. Public releases will still happen. There will still be ope=
n source code. But the ability of attackers to steal attention or time from=
 bitcoin developers will be severely reduced. Likewise for attackers abilit=
y 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 cont=
inue to be the GitHub and would not really change. There would be a separat=
e 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 y=
ou want a public link on X.com then link to that, but a link to the members=
hip-required site won&#39;t work for non-members.<br><br>For the private wo=
rk space: I think registration, coupled with a delay, coupled with a probat=
ionary period would probably be sufficient. Possibly also with review or, w=
hat could be interesting as if at least two people out of any of the member=
s have to recommend the user for entry. Or, you can do proof-of-work to get=
 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 to=
 moderation and rules of engagement such as, if you just show up to cause c=
haos 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 ca=
n 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 links=
 to temporarily include non-members as they see fit.<br><br><br># Theory cr=
afting<br><br>Non-technical activist movements have a history of making ope=
n 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, instea=
d, towards the creation of more non-viable forks.<br><br>We can remain comm=
itted to making forking as frictionless as we can, while also increasing th=
e friction of participation of non-technical actors in members-only technic=
al discussion forums. The existence of members-only technical discussion fo=
rums does not preclude the existence of public channels, nor does it prohib=
it the flow of information in either direction. It merely carves out a spec=
ific space and area.<br><br>Something along the lines of: &quot;We are will=
ing 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 t=
he ones to create the exact software of your choosing. We hope that you lik=
e the software we work on, and we welcome your feedback in the right time a=
nd place, just not in private developer spaces.&quot;<br><br>Open source so=
ftware has a lot of history behind it and established developer culture nor=
ms. Open here usually refers to the source code licensing (see early 90s wo=
rk from Foresight Institute&#39;s Christine Peterson&#39;s Open Source Defi=
nition initiative). &quot;Open&quot; development does not mean &quot;open t=
o coercion&quot;. It feels very weird to write an email that essentially am=
ounts 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 ac=
tive ongoing attempts of coercion. Even if it&#39;s from &quot;the public&q=
uot;. 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 possibilitie=
s 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 sim=
ply 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 resto=
re 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 you=
 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 a=
ctively directly hostile to you. Meanwhile dev attention is scarce and whil=
e it&#39;s individually regulated (as it should be), care should be taken t=
o monitor if the obvious default regulation is for developers to simply dis=
engage or not engage at all, which would be a detriment to the bitcoin proj=
ect. 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 th=
at we are interested in having more developers join and collaborate on Bitc=
oin 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 collabora=
te 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 contr=
ibutors.<br><br>What I think people might be upset about this idea to priva=
tize is that, to the extent that people perceive that they are currently ab=
le to coerce developers to work on specific things any given developer woul=
dn&#39;t have worked on otherwise, and if any developer collaborations volu=
ntarily retreat to their own private work area, then I think those same peo=
ple might get upset to the extent they perceive or feel that they are losin=
g a coercive lever over developers that they previously thought they had (p=
erhaps permanent) power over. In reality, it has always been a voluntary no=
n-coercive arrangement, it&#39;s just that people get confused about the so=
cial 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 mea=
sure is important for the ongoing and future success of the project. As a m=
oderator in the bitcoin-dev project it is hard for me to communicate the le=
vels of attacks that we have seen and that I expect to see going forward. W=
e are talking about a trillion dollar system. We are talking about disrupti=
ng 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 be=
lieve and what bitcoin is or what bitcoin will become. These sorts of threa=
ts are completely unlike any other open source software project has ever se=
en, 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 whateve=
r; instead it&#39;s an opportunity to look at what tools we have at our dis=
posal to counter these threats and ensure our continued productivity and th=
at our open community can remain open without also cutting ourselves off.<b=
r><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.co=
m/posts/tscc3e5eujrsEeFN4/well-kept-gardens-die-by-pacifism" target=3D"_bla=
nk" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=
=3Den&amp;q=3Dhttps://www.lesswrong.com/posts/tscc3e5eujrsEeFN4/well-kept-g=
ardens-die-by-pacifism&amp;source=3Dgmail&amp;ust=3D1749712631396000&amp;us=
g=3DAOvVaw0MUJQNdxN0iEflPXrMLnrz">https://www.lesswrong.com/posts/tscc3e5eu=
jrsEeFN4/well-kept-gardens-die-by-pacifism</a><br><a href=3D"https://meanin=
gness.com/geeks-mops-sociopaths" target=3D"_blank" rel=3D"nofollow" data-sa=
feredirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://meaning=
ness.com/geeks-mops-sociopaths&amp;source=3Dgmail&amp;ust=3D174971263139600=
0&amp;usg=3DAOvVaw1mUwTxJ4hPDDJgCnV7lA2Z">https://meaningness.com/geeks-mop=
s-sociopaths</a><br><a href=3D"https://github.com/bitcoin-core/meta/issues/=
19" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.=
google.com/url?hl=3Den&amp;q=3Dhttps://github.com/bitcoin-core/meta/issues/=
19&amp;source=3Dgmail&amp;ust=3D1749712631396000&amp;usg=3DAOvVaw3QfKrRRzmk=
CuVMXVb6iwew">https://github.com/bitcoin-core/meta/issues/19</a><br><a href=
=3D"https://x.com/kanzure/status/1932534820607045947" target=3D"_blank" rel=
=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&am=
p;q=3Dhttps://x.com/kanzure/status/1932534820607045947&amp;source=3Dgmail&a=
mp;ust=3D1749712631396000&amp;usg=3DAOvVaw1xpRtGaGXOsL1OUX68TV1k">https://x=
.com/kanzure/status/1932534820607045947</a><br><br>P.S. I still think bitco=
in-core/meta on GH should be deleted. It&#39;s relatively recent and nothin=
g of value will be lost that cannot be re-hosted should it ever prove neces=
sary to do so.<br></div><div><br></div><div dir=3D"ltr" class=3D"gmail_sign=
ature" data-smartmail=3D"gmail_signature"></div></div>
</blockquote></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/daf2b47a-eff6-42ab-891b-a15f9f9fcd85n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/daf2b47a-eff6-42ab-891b-a15f9f9fcd85n%40googlegroups.com</a>.<br />

------=_Part_30385_1217564831.1749631097312--

------=_Part_30384_1592964251.1749631097312--