From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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

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

= 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.

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

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

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

Thanks
Michael

[0]:=C2=A0https://gnusha.org/pi/bitcoindev/LmX3Gnfkf1T0E= b_wUXxPe8c0Tf2DNipfIqufkRS6oOPhttr4iZIOWtjUL_7QkcWEHr8eFvehHooaM140ZBKLwi98= F5NwyQKSyEhAPZDK1YQ=3D@protonmail.com/
[1]:=C2=A0https://gnusha.o= rg/pi/bitcoindev/XuO20TMFGBqz53WYWxi9bgAdB3iGmqEIUE84AupRxCpHQVd3-YbGVzZUFz= 21dOgb_AgwlGWaruzE8NGxhes6HCKHpRZLmL1d1kNu1yobAIU=3D@protonmail.com/
<= div>[2]:=C2=A0https://gnusha.org/pi/bitcoindev/uuq_VbxJp50_-m4ufKpEhJOknhZ0= pvK8ioDabCkxtDjBYauO3gLKrj2O2tjS6YIFOnJLyaZg6-LENzom1DyQQ3TyMLIIaGz5IRrzrKB= 8gRs=3D@protonmail.com/
[3]:=C2=A0https://bitcoincore.org/en/2025= /06/06/relay-statement/
[4]:=C2=A0https://github.com/bitcoin/bitc= oin/pull/32406#issuecomment-2955614286



On Tuesday, June 10, 2025 at 11:40:15=E2=80=AFPM UTC+3 Bry= an Bishop wrote:
The case for privatizing Bitcoin Core:

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.


# The ongoing problem

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'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= 9;s impossible to eliminate online forums for providing that, but here I= 9;m specifically focusing on areas intended for dev collaboration.

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.

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 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>
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?


# Git= Hub

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'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.


# = Privatization

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.


# Office culture

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 "= ;open development" 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.


# How it would work

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.

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.

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't be. This will seve= rely curtail brigading and spam while also enabling continued ongoing devel= opment activities for collaborators.

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.

= 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't work for non-members.

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'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't be that anyone ca= n 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 cr= afting

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.

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.

Something along the lines of: "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."

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's Christine Peterson's Open Source Defi= nition initiative). "Open" development does not mean "open t= o coercion". 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's from "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...
=
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'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 a= ctively directly hostile to you. Meanwhile dev attention is scarce and whil= e it'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).

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.

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'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's just that people get confused about the so= cial dynamics and forget this isn't feudalism slave labor era anymore.<= br>


# End of remarks

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'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.



Humbly my own,

Bryan Bishop = aka kanzure

June 2025


https://www.lesswrong.com/posts/tscc3e5eu= jrsEeFN4/well-kept-gardens-die-by-pacifism
https://meaningness.com/geeks-mop= s-sociopaths
https://github.com/bitcoin-core/meta/issues/19
https://x= .com/kanzure/status/1932534820607045947

P.S. I still think bitco= in-core/meta on GH should be deleted. It'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.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/daf2b47a-eff6-42ab-891b-a15f9f9fcd85n%40googlegroups.com.
------=_Part_30385_1217564831.1749631097312-- ------=_Part_30384_1592964251.1749631097312--