From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 14 Jun 2025 13:45:20 -0700 Received: from mail-ot1-f55.google.com ([209.85.210.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uQXkb-0006DW-PW for bitcoindev@gnusha.org; Sat, 14 Jun 2025 13:45:20 -0700 Received: by mail-ot1-f55.google.com with SMTP id 46e09a7af769-72ecb622e02sf1438186a34.0 for ; Sat, 14 Jun 2025 13:45:17 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1749933912; cv=pass; d=google.com; s=arc-20240605; b=k4oOcPwZqEkv+BFkXJtW80CGeDaNREaxQusjz14D5EU3bUAKc8wz4nomwKuh/cExEa SROxFPhTD/QwA4YJx27kxILmXYJkUjJSezkCrt5PRdtkNzNy6PPB3bm137oNUh+VcxCr UZ4KrhmWbUfcfZqvh1n2M5l1Ra34TDmZVOyF3DI+UlT/MgDWuY7xtWLkjNkdplndOVIP LNgOqcUx1S8jiBht4PPKNyEO+MAHwXpVxgIpKWn80SCPOdOzRuOA79O2odWhlq3pPf2m gBSnUrp4tgdMizY0mVTRwsUNWWIu97RDcFVnMVmHf5brNxLcRAWPnoCAFU4Ci/PvaCZO Iy8Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=BwvEPxshbARvBD7VGd3PlXl68t7YwrRRJ1xG05izbwc=; fh=sZ8SJYsj5KtSPXkeO/xYV9SfGSMAO8DAXf5eyKEkA0U=; b=Df9g7vQnFt+OkX3Qx/ZY1e+5AgqhxtQGC7hDk+R7YTZDo9bhTHCBLQlawWMvyzvC95 dV4mLMo4HsRvvAY/cXyNOeXS2HjxACM0c1QtBUw1W8kKJik7EOERFcHw7h9FQLV/KP8l v0xgXX1UqGe5a2aIZS4dzQhTVwVhUYwZziDM5LwEcZSpmIGzLqK5w6yY+y8Bwbi62Iou nZS/8VO35akZz7rxafNVACm14O45y+1Z/PDRmHPrFCeJ8d/Rs2I9po3c2G1VNI9oTndH adj/bsNK6omiLGrWlXZxQ9Yk5oxlLYKs5Wg1kpfN1Ti45TDCfh1pSp2G/SAw60ockNQQ T+vg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=UQy+4kRG; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1749933912; x=1750538712; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=BwvEPxshbARvBD7VGd3PlXl68t7YwrRRJ1xG05izbwc=; b=N7qXT4/CUazntdBbsGRe9cmYPV193Fdu1kKBOUUuL88IokGMIG93xMtzNnlnUy6+i5 u4n7BB77G+EXoz8w72l1EXn8SNvQNylB8bG2v39LNOMhNpsPN5395FzN/vB0NFcSikco 2n3EjsU9Or4TiWyjQB55C8awJm7QqYolhF4d/Pn2E8UPFll1P++j3rmY9EXEy1jbTa6H c2Ma5oU7c3vkw9B1RMmwdEHCbPK1CIHCXyvlo8IivW/bVrpOzCr8REedm7Mkn50+k2x1 QbfmKSGm8WqgZP29B/Jd6vfvqHEZciudP41AjX52BrZhahD+kRGDrHkEIERn1Lx9WvkO neKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749933912; x=1750538712; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=BwvEPxshbARvBD7VGd3PlXl68t7YwrRRJ1xG05izbwc=; b=WpsCiGgS0og1UQrWhRK2ry052MSlJ7fnXRCr1sNg0Fg4QZmBu9sZilmtu5/6lpCf+N EIRUSE7wdQG+Tbn1+wfz2c8SLh1TY1kCERTCZNKyGOXtg6H/Fk2+gd6ryyCQIgfq95xA a8HE+q2AxOk/J+OZphIGpGpBPiW5sBFGlhtB2Qyzf+Yn+8JWyC8quN95K11D7Mt0Ikan uWwhCQdi96Waat4oEyq054q+lUn7lNsLIIr0W5UUT+XOdh0Af6id8gte97GNwOpyY4vl M/+DOoFerBRwEDpdc30NS0Y9nzI3/U+5OBzOX0Di/PDeHmx9NQUKG6mzshJ7vXjGXppy V09A== X-Forwarded-Encrypted: i=2; AJvYcCUXDq3Tcm8rD6UgHkW31vetvTib1oV186su+1hnd/a82GCF+RZE1wIrmnLwsqUvoBkfIPXh4cIGkRk7@gnusha.org X-Gm-Message-State: AOJu0Yw9yGJdDVQ40nAG70JLcGNbV65m/IAoPvOAl83pGyMEbyNbwxvz bHuCPomzW543IuM008wB8MNDfWlPo4rwtsZNmpuOJpiTnrlMPn76r2OE X-Google-Smtp-Source: AGHT+IGHtFCkK+ZpEb6aww6ub7+R4gn/zDxcd5PTz70+np16wMh4GcYzEwMDpS5rxlWjX05wyc3fRw== X-Received: by 2002:a05:6830:498d:b0:734:f5e2:8cbc with SMTP id 46e09a7af769-73a36332122mr2836267a34.18.1749933911738; Sat, 14 Jun 2025 13:45:11 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZekNHicEvx5PbgUmwpH43PU9iqeQOxhGwB3ZmkiDEcVKw== Received: by 2002:a05:6820:6709:b0:60b:a53c:36af with SMTP id 006d021491bc7-610fd353ed2ls697683eaf.2.-pod-prod-04-us; Sat, 14 Jun 2025 13:45:07 -0700 (PDT) X-Received: by 2002:a05:6808:6f87:b0:3f6:a476:f7d3 with SMTP id 5614622812f47-40a7c18c3aamr2765928b6e.9.1749933907846; Sat, 14 Jun 2025 13:45:07 -0700 (PDT) Received: by 2002:a05:600c:a116:b0:442:dc76:9493 with SMTP id 5b1f17b1804b1-45334479db2ms5e9; Sat, 14 Jun 2025 11:29:39 -0700 (PDT) X-Received: by 2002:a05:6000:2302:b0:3a4:f6ba:51da with SMTP id ffacd0b85a97d-3a5723711famr3642057f8f.15.1749925774473; Sat, 14 Jun 2025 11:29:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1749925774; cv=none; d=google.com; s=arc-20240605; b=V5Sw4PFD561B72Ul/SH1b0I/nk7dl9AoX+jf9svd4mqiAfxmWutUM50YiNE5B/XJCP 5SI1bqvN8h5pyyCtE9gcIlOujAAdNSaHvgSmwDLUP6drEr/Kpgk1gUAQfKhwGThGKw72 L8Pui+W2ErPgfeJueATL0tTcHgMPGsNJZH2umgBMtmbxHMVuWYioS4/HJfSHpRJ9PM2A Gmau6YN4PK+B/N41iKNDLSITRJu7PPkk2qy8AY/BPVbZZ/y0Y30+mV9I9vstxd835quB 016J6anbE9yeKiG95ZQEAwmy7oaNLc4YK216H32hiiyWVHzkoFZ9crSPHq2dnUqegLIm 6XXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=gRQ+xXmqKRiaD1mpi9mi8lpsyqWdIPKP+C2yaB0L1kc=; fh=GrYwucciMhLORZt1fsQXZtg3Ji0QXL4X0nS/6kd273E=; b=ClBpozN0cyutf9r5lOhNYfFDLVMg6RC47KFtpEhXfMFYay+vA/wdA0nWnBX/6vFts9 gIh3fGFpTBnOH82aGqxGMuck7ync4zk1Z+iucIIvPasBu8ImUp1FRvMynI+0XOUQkBRj UYi0dP5Z1Eu8m1LuStVyrQ+dhqSbiBbEeLeay7cfm/F04UhF3BO/A8FUs7pmt/R6Uv3X u1Jd71/ITqLzwJ5wmHNxfDWgYSKYPTZOShqkpk9veO2I04XsEid7kpu7WoOh59t8PBOI 4KmA0F2YlpGz4DB4eSt7DSmYF7sH+h6BkoaLIRXF3UURptcUbj8SfV8Yi1miE4yQgm0U MsVg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=UQy+4kRG; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch. [185.70.43.22]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-3a568ae18d3si74556f8f.5.2025.06.14.11.29.34 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 14 Jun 2025 11:29:34 -0700 (PDT) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) client-ip=185.70.43.22; Date: Sat, 14 Jun 2025 18:29:26 +0000 To: Bryan Bishop From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: bitcoindev@googlegroups.com Subject: Re: [bitcoindev] The case for privatizing Bitcoin Core Message-ID: <4iW61M7NCP-gPHoQZKi8ZrSa2U6oSjziG5JbZt3HKC_Ook_Nwm1PchKguOXZ235xaDlhg35nY8Zn7g1siy3IADHvSHyCcgTHrJorMKcDzZg=@protonmail.com> In-Reply-To: References: Feedback-ID: 7060259:user:proton X-Pm-Message-ID: 8771db6f70b9ce539c70035e804bc797a3715410 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_vUSNfO4MTt8ZXrFmfmBvQoOkgY4jDRPrjzG8CDHQ8Q" X-Original-Sender: darosior@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=UQy+4kRG; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Antoine Poinsot Reply-To: Antoine Poinsot 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: -1.0 (-) --b1=_vUSNfO4MTt8ZXrFmfmBvQoOkgY4jDRPrjzG8CDHQ8Q Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Bryan, Thanks for your thoughts. It's always good to take a step back and reflect = on whether things are the way they are because it makes sense or because of= inertia. I started reading by speculating you were defending the case for something = akin to a "source-available" Bitcoin Core. Where development would happen i= n private and source code would be made available at the same time as (repr= oducible) binary releases. I think there are a few major issues with this a= pproach. Among them: - The now-private project would have to take on the burden of producing edu= cational and historical content, which is currently outsourced to the wider= technical community (for instance the optech newsletter or simply searchab= le through Github); - It would increase the cost, in relation to the previous point, of "grassr= oot" onboarding to the project. I may be biased by my personal experience o= f starting by lurking at the development process for years and spending a l= ong time as an active-contributor-but-not-full-time-project-member, but it = seems to me such a project structure would erect significant barriers to th= is approach and could make it almost necessary to go through one of the dev= elopment organizations to onboard to the project; - In a similar but different vein, it would also make it less likely to get= valuable contributions from people that "just show up" with no particular = intention to start working full time on Bitcoin Core but had something that= makes a lot of sense to share (whether it's code, reporting an experience = or even just a meaningful thought). However you are not making the case for this, but for a private Bitcoin Cor= e repository with a public mirror. The public mirror would have comment thr= eads on pull requests originating from the private repository and the possi= bility to open issues. It would essentially enable developer to opt into en= gaging on public comment threads (for bug reports, contentious pull request= s if they see fit, etc..) while always having the possibility to retreat in= the private repository to focus. This does sound more appealing to me, alt= hough it raises question with regard to its feasibility and the churn it co= uld introduce (could the public mirror insert public comments within the sy= nced private thread? or would it have to duplicate every single thread?). You touch on the office culture and the need for a platform that would be a= better sweet spot between unmoderated public discussions and entirely priv= ate discussions happening in the confines of a Bitcoin developer organizati= on's offices. However it's unclear that what drives a lot of discussions to= happen in offices is the occasional disruption of online fora, rather than= just the natural advantages of in-person discussions. You also state that brigading would be severely reduced and eliminated. How= ever it seems contrary to having publicly available comment threads? It wou= ld just contain the brigading to the publicly available comment threads. Yo= u could make the point that this containment would disincentivize the briga= ding in the first place, but it would only be the case if there is no expec= tation that the low-quality comments be taken into account in the decision = making. And removing this expectation does not require such an involved pro= ject structure, which brings me to my last point. I agree with your problem statement. I believe there is a dangerous percept= ion that the Bitcoin Core Github repository somehow controls Bitcoin and is= worthy of political pressure. And this is not only the case of the filter = enjoyers, this misperception is also used for example to justify legal thre= ats[^0] against developers. It is important to push back against this confu= sion, but it seems achievable with a lot less disruption than by changing t= he project structure. We just need to face the fact that Bitcoin Core is a = centralized project. It has a central website, releases binaries and update= s its software based on rough technical consensus. Bitcoin is decentralized= , Bitcoin Core is not. Setting expectations that misinformed rants and cons= piracy theories will be considered at all in deciding whether code should b= e changed is entirely self-inflicted and does not need a change in the proj= ect structure to correct. It does however require Bitcoin Core contributors= to act collectively, which is notoriously difficult to achieve, for better= (in the case of pressure to merge contentious consensus changes for instan= ce) or for worse (here). In conclusion, i don't think yours is a bad idea. If the Bitcoin Core proje= ct was set up this way today i think it would be fine. I just see the curre= nt project structure as equally fine and unnecessary to change, as what is = really needed to mitigate the social attacks is to just stop tolerating the= m. Best, Antoine Poinsot [^0]: It was the case with Craig Wright, but also more recently: https://gi= thub.com/bitcoin-core/meta/issues/19#issuecomment-2843664280 On Tuesday, June 10th, 2025 at 4:40 PM, Bryan Bishop wr= ote: > The case for privatizing Bitcoin Core: > > I believe that reflection is critical for curiosity, understanding, impro= vement, and progress. And recent activity on the Bitcoin Core github accoun= t has given me an opportunity to re-evaluate my beliefs about open-source s= oftware development on GitHub. > > # The ongoing problem > > What happened was nothing new. It has happened before and it will happen = again, especially if we do nothing new or different. Essentially there is a= recurring pattern of non-contributors (sometimes even non-developers) intr= uding into an online forum intended mainly for people collaborating on Bitc= oin Core to work together on whatever they are working on. This often cause= s issues like wasting people's valuable time, creating manufactured controv= ersy, misinformation, etc. It is trivial to see how exposure to deep techni= cal content can cause confusion or misunderstanding for non-technical peopl= e who may not even know the ethos of open-source development or what bitcoi= n developers really do or believe about what they do. Unsolicited feedback = from random/new people and even noise can sometimes be useful and thankfull= y it's impossible to eliminate online forums for providing that, but here I= 'm specifically focusing on areas intended for dev collaboration. > > What we want as developers is to collaborate with whoever we wish on what= ever our hearts desire, and we can freely do that over the Internet or in p= erson 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 a= nd nobody owes any obligation to anyone else but to themselves. Indeed, eve= n non-developer bitcoiners are not obligated, like they are not obligated t= o run code written by people they find disagreeable if for some reason they= cannot find sufficient reason to not run code in the code itself. > > You can argue there might be ethical or moral obligations created by work= ing on open-source software, beyond those created by the license, but I don= 't buy that argument. There are no additional explicit obligations beyond t= he license. I'll add, though, that many developers have their own moral val= ues and beliefs about how they should act and behave, and how that informs = who they choose to collaborate with, which is great! Many believe they have= a personal moral value of informing uneducated people, or protecting peopl= e from security threats, or hundreds of other particular preferences and op= inions. All of these are fantastic and I am glad these preferences or belie= fs exist... but they cannot be coercively applied and we should not allow t= he bitcoin project, or Bitcoin Core, or github, to be a platform for inflic= ting coercive beliefs upon developers that have gifted us so much time, ene= rgy and efforts on a historically and systemically critical development. > > Therefore, I think there might be an opportunity here to re-evaluate the = nature of open-source software development. I think there is an opportunity= to re-evaluate how we choose to work together. What if there was a better = way to collaborate on the work we do for bitcoin? What would it look like? = What would be different? What would be kept the same? > > # GitHub > > Unfortunately the situation is that GitHub does not have good moderation = controls and was only built for a very narrow concept of open source develo= pment. The solution to brigading is better controls around the presentation= layer or requiring some sort of membership. If you just have a perpetual o= pen door policy straight from reddit into your developer den, then yeah peo= ple are going to walk in and take a shit on your desk where you were workin= g with another dev.. With some thinking I'm sure we can structure better wa= ys to get exposure to general public sentiment or opinion, while also struc= turing a space for development to take place that does not require blindly = mixing off-topic content with developer content. > > # Privatization > > Here, I would like to make the case for privatizing Bitcoin Core software= development into a members-only gitlab or other kind of open-source softwa= re collaboration system. It would have the following properties. Issues and= pull requests would be private and not subject to public hyperlinking. Any= one can register or apply for access. Whoever runs the site/repository woul= d be responsible for configuration, hosting, setup, moderation, access cont= rol, etc. Software development would continue under the same license. New i= ssues, comments, code review comments would possibly be licensed under a sp= ecific license like CC0 or public domain or some other license, possibly wi= th PGP-signature to track agreement if we care about comments licensing. Pu= ll requests can be cross-posted to any number of repositories either public= or private as much as any contributor wishes, except to the point where an= y norm violation or spam violation occurs for the respective publishing sys= tems of course. > > # Office culture > > An alternative to what I am proposing is already happening: development i= nside closed offices (Chaincode, Brink, Localhost, etc), which is less acce= ssible and less open than a invite-only developer collab site. And also les= s "open development" than the current Bitcoin Core GitHub project. So a fai= lure to sort out these issues with Bitcoin Core collaboration can and has a= lready produced solutions that are functionally less inclusive than an onli= ne member-only source forge. It is to the detriment of the open project tha= t so much gets discussed inside these private offices and many of us are no= t able to contribute that way, and there ought to be something between a pu= blic github that the general public can brigade and closed offices on the o= ther end of the spectrum. > > # How it would work > > Contributors would be free to collaborate on any branch, pull request, or= privatized fork, or even public fork. Issues, issue comments, pull request= comments, code review comments, and miscellaneous discussions can also be = posted internally. Code can come from inside the members-only repository, o= r it can be contributed from outside sources if someone pulls it in, propos= es it, or otherwise posts those patches. > > Releases can be cut and source code published all at once, if that is des= irable to anyone. However, I suspect that for Bitcoin Core, contributors wo= uld likely push changes out to various public access githubs or other locat= ions on an hourly, daily or regular basis. Bitcoin Core, as it exists today= , could do the same for pull requests, code review comments, etc, and post = them publicly on a website. Anyone would be free to make a website where an= y person, including non-developers and including non-contributors, could fr= eely post code review or comments. This could even happen on the current GH= bitcoin/bitcoin repository. For example, any of the private code review co= mments can be posted directly into the PR on GH. PGP signatures can be used= for verifiable comment attribution. Or another website can be linked from = a GH PR to display the private-originated review history. > > Brigading will be severely reduced and eliminated. You can pass around a = link to the repository and a comment or issue but nobody will be able to se= e the content unless they are a registered member, which the vast majority = of all internet people won't be. This will severely curtail brigading and s= pam while also enabling continued ongoing development activities for collab= orators. > > Bitcoin Core itself has releases and maintainers that push the release bu= tton. I fully believe that even after privatizing Bitcoin Core that they st= ill will behave using the same norms and beliefs and systems that they pres= ently do. Public code review will still continue. Public releases will stil= l happen. There will still be open source code. But the ability of attacker= s to steal attention or time from bitcoin developers will be severely reduc= ed. Likewise for attackers ability to coerce bitcoin developers through pub= lic spectacle where they do their core work. I believe that the community w= ould be more productive and more energized if we regularly used a privatize= d collaboration platform. > > In practice, the way that this would roll out is that the GitHub would co= ntinue to be the GitHub and would not really change. There would be a separ= ate private area for some developers to work together. Then they would thro= w it over the wall or have some sort of (possibly real-time) synchronizatio= n protocol to synchronize pull requests to the public GitHub repository. If= you want a public link on X.com then link to that, but a link to the membe= rship-required site won't work for non-members. > > For the private work space: I think registration, coupled with a delay, c= oupled with a probationary period would probably be sufficient. Possibly al= so with review or, what could be interesting as if at least two people out = of any of the members have to recommend the user for entry. Or, you can do = proof-of-work to get entry and post something, and it's subject to moderato= r review until 2-of-n approve your membership? I would advocate for very st= rong norms as to moderation and rules of engagement such as, if you just sh= ow up to cause chaos then you lose your access to the members-only place an= d you will have to post code somewhere else on the internet. It won't be th= at anyone can show up and cause chaos and never be silenced or banned. > > Adoption: would not be too difficult, as only two or three developers can= privately experience some benefits. They can also use private one-time exp= iring links to temporarily include non-members as they see fit. > > # Theory crafting > > Non-technical activist movements have a history of making open discussion= forums non-viable. Those same non-technical activist movements also have a= history of making many non-viable forks, due to for example a lack of tech= nical expertise in said movements. I would like to find ways to redirect ef= forts that would manifest as unusable discussion forums, instead, towards t= he creation of more non-viable forks. > > We can remain committed to making forking as frictionless as we can, whil= e also increasing the friction of participation of non-technical actors in = members-only technical discussion forums. The existence of members-only tec= hnical discussion forums does not preclude the existence of public channels= , nor does it prohibit the flow of information in either direction. It mere= ly carves out a specific space and area. > > Something along the lines of: "We are willing to commit to your freedom t= o create and run software of your choosing. We are not committed to interna= lizing often coercive demands that *we* be the ones to create the exact sof= tware of your choosing. We hope that you like the software we work on, and = we welcome your feedback in the right time and place, just not in private d= eveloper spaces." > > Open source software has a lot of history behind it and established devel= oper culture norms. Open here usually refers to the source code licensing (= see early 90s work from Foresight Institute's Christine Peterson's Open Sou= rce Definition initiative). "Open" development does not mean "open to coerc= ion". It feels very weird to write an email that essentially amounts to rem= inding grown adults that they can freely collaborate in any way they wish, = and that they do not have to invite or subject themselves to active ongoing= attempts of coercion. Even if it's from "the public". There are free-for-a= ll places all over the Internet to post that kind of content, or to read it= and review it. There are also other possibilities for structured access an= d 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 o= ver time what has happened is that of the people who refuse to be subjected= to coercion attempts from internet mobs have simply left the public collab= oration process to either retreat into office in-person settings or stop co= ntributing to bitcoin development entirely... > > Also, it does not feel good to ban people or clean up brigades to restore= structure or order etc. which is partly why some core contributors have be= en 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, i= ncluding platforming people who disagree with you or hate you outright. "Co= ercive platforming" happens when others demand you platform their speech co= ntent even if it's off-topic or low signal or actively directly hostile to = you. Meanwhile dev attention is scarce and while it's individually regulate= d (as it should be), care should be taken to monitor if the obvious default= regulation is for developers to simply disengage or not engage at all, whi= ch would be a detriment to the bitcoin project. Instead we can filter the n= oise going into the system at the top of the funnel instead of the bottom (= comments level). > > One goal is that we are interested in having more developers join and col= laborate on Bitcoin Core. Creating an environment conducive to new develope= rs is important and if they have to also be subjected to a bunch of noise j= ust to collaborate on code on GitHub then I think that is sub-optimal and a= self-defeating strategy if one of the goals is growth in the number of dev= elopers or contributors. > > What I think people might be upset about this idea to privatize is that, = to the extent that people perceive that they are currently able to coerce d= evelopers to work on specific things any given developer wouldn't have work= ed on otherwise, and if any developer collaborations voluntarily retreat to= their own private work area, then I think those same people might get upse= t to the extent they perceive or feel that they are losing a coercive lever= over developers that they previously thought they had (perhaps permanent) = power over. In reality, it has always been a voluntary non-coercive arrange= ment, it's just that people get confused about the social dynamics and forg= et this isn't feudalism slave labor era anymore. > > # End of remarks > > Building this sort of protection measure is important for the ongoing and= future success of the project. As a moderator in the bitcoin-dev project i= t is hard for me to communicate the levels of attacks that we have seen and= that I expect to see going forward. We are talking about a trillion dollar= system. We are talking about disrupting tens of trillions of dollars of va= lue. And there are massive adversarial forces, including nation state and n= on-state actors with tremendously deep resources, that are completely adver= se to what we stand for and what we believe and what bitcoin is or what bit= coin will become. These sorts of threats are completely unlike any other op= en source software project has ever seen, and if anything I am underestimat= ing what we are up against. This isn't to say to throw out our values and e= nact bitcoin governance or whatever; instead it's an opportunity to look at= what tools we have at our disposal to counter these threats and ensure our= continued productivity and that our open community can remain open without= also cutting ourselves off. > > Humbly my own, > > Bryan Bishop aka kanzure > > June 2025 > > https://www.lesswrong.com/posts/tscc3e5eujrsEeFN4/well-kept-gardens-die-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 relati= vely recent and nothing of value will be lost that cannot be re-hosted shou= ld it ever prove necessary to do so. > > -- > You received this message because you are subscribed to the Google Groups= "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w%40mail.gmail.com. --=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/= 4iW61M7NCP-gPHoQZKi8ZrSa2U6oSjziG5JbZt3HKC_Ook_Nwm1PchKguOXZ235xaDlhg35nY8Z= n7g1siy3IADHvSHyCcgTHrJorMKcDzZg%3D%40protonmail.com. --b1=_vUSNfO4MTt8ZXrFmfmBvQoOkgY4jDRPrjzG8CDHQ8Q Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bryan,

=
Thanks for = your thoughts. It's always good to take a step back and reflect on whether = things are the way they are because it makes sense or because of inertia.
=20
=20
=20

<= div style=3D"font-family: Arial, sans-serif; font-size: 14px;">I started re= ading by speculating you were defending the case for something akin to a "s= ource-available" Bitcoin Core. Where development would happen in private an= d source code would be made available at the same time as (reproducible) bi= nary releases. I think there are a few major issues with this approach. Amo= ng them:
  • The now-private project would = have to take on the burden of producing educational and historical content,= which is currently outsourced to the wider technical community (for instan= ce the optech newsletter or simply searchable through Github);
    • <= li style=3D"list-style-type: "- ";">It would increase the c= ost, in relation to the previous point, of "grassroot" onboarding to the pr= oject. I may be biased by my personal experience of starting by lurking at = the development process for years and spending a long time as an active-con= tributor-but-not-full-time-project-member, but it seems to me such a projec= t structure would erect significant barriers to this approach and cou= ld make it almost necessary to go through one of the development organizati= ons to onboard to the project;
  • In a similar but different vein, it would = also make it less likely to get valuable contributions from people that "ju= st show up" with no particular intention to start working full time on Bitc= oin Core but had something that makes a lot of sense to share (whether it's= code, reporting an experience or even just a meaningful thought).

However you are not making the case = for this, but for a private Bitcoin Core repository with a public mirror. T= he public mirror would have comment threads on pull requests originating fr= om the private repository and the possibility to open issues. It would esse= ntially enable developer to opt into engaging on public comment threads (fo= r bug reports, contentious pull requests if they see fit, etc..) while alwa= ys having the possibility to retreat in the private repository to focus. Th= is does sound more appealing to me, although it raises question with regard= to its feasibility and the churn it could introduce (could the public mirr= or insert public comments within the synced private thread? or would it hav= e to duplicate every single thread?).

You touch on the office culture an= d the need for a platform that would be a better sweet spot between unmoder= ated public discussions and entirely private discussions happening in the c= onfines of a Bitcoin developer organization's offices. However it's unclear= that what drives a lot of discussions to happen in offices is the occasion= al disruption of online fora, rather than just the natural advantages of in= -person discussions.

You also state that brigading would be severely reduced= and eliminated. However it seems contrary to having publicly availa= ble comment threads? It would just contain the brigading to the publicly av= ailable comment threads. You could make the point that this containment wou= ld disincentivize the brigading in the first place, but it would only be th= e case if there is no expectation that the low-quality comments be taken in= to account in the decision making. And removing this expectation does not r= equire such an involved project structure, which brings me to my last point= .

=
I agr= ee with your problem statement. I believe there is a dangerous perception t= hat the Bitcoin Core Github repository somehow controls Bitcoin and is wort= hy of political pressure. And this is not only the case of the filter enjoy= ers, this misperception is also used for example to justify legal threats[^= 0] against developers. It is important to push back against this confusion,= but it seems achievable with a lot less disruption than by changing the pr= oject structure. We just need to face the fact that Bitcoin Core is a centr= alized project. It has a central website, releases binaries and updates its= software based on rough technical consensus. Bitcoin is decentralized, Bit= coin Core is not. Setting expectations that misinformed rants and conspirac= y theories will be considered at all in deciding whether code should be cha= nged is entirely self-inflicted and does not need a change in the project s= tructure to correct. It does however require Bitcoin Core contributors to a= ct collectively, which is notoriously difficult to achieve, for better (in = the case of pressure to merge contentious consensus changes for instance) o= r for worse (here).

In conclusion, i don't think yours is a bad idea. If the Bitco= in Core project was set up this way today i think it would be fine. I just = see the current project structure as equally fine and unnecessary to change= , as what is really needed to mitigate the social attacks is to just stop t= olerating them.

Best,
Antoine Poinsot

[^0]: It was the case with Craig Wright, but= also more recently: https://github.com/bitcoin-core/meta/issues/19#issuecomment-= 2843664280
On Tuesday, June 10th, 2025 at 4:40 PM, Bryan Bishop <kanzure@gm= ail.com> wrote:
The case for privatizing Bitcoin Core:
I believe that reflection is critical for curiosity, understanding, im= provement, and progress. And recent activity on the Bitcoin Core github acc= ount has given me an opportunity to re-evaluate my beliefs about open-sourc= e software development on GitHub.


# The ongoing problem

W= hat happened was nothing new. It has happened before and it will happen aga= in, especially if we do nothing new or different. Essentially there is a re= curring pattern of non-contributors (sometimes even non-developers) intrudi= ng into an online forum intended mainly for people collaborating on Bitcoin= Core to work together on whatever they are working on. This often causes i= ssues like wasting people's valuable time, creating manufactured controvers= y, misinformation, etc. It is trivial to see how exposure to deep technical= content can cause confusion or misunderstanding for non-technical people w= ho may not even know the ethos of open-source development or what bitcoin d= evelopers really do or believe about what they do. Unsolicited feedback fro= m random/new people and even noise can sometimes be useful and thankfully i= t's impossible to eliminate online forums for providing that, but here I'm = specifically focusing on areas intended for dev collaboration.

What = we want as developers is to collaborate with whoever we wish on whatever ou= r hearts desire, and we can freely do that over the Internet or in person o= n 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 nobo= dy owes any obligation to anyone else but to themselves. Indeed, even non-d= eveloper bitcoiners are not obligated, like they are not obligated to run c= ode written by people they find disagreeable if for some reason they cannot= find sufficient reason to not run code in the code itself.

You can = argue there might be ethical or moral obligations created by working on ope= n-source software, beyond those created by the license, but I don't buy tha= t argument. There are no additional explicit obligations beyond the license= . I'll add, though, that many developers have their own moral values and be= liefs about how they should act and behave, and how that informs who they c= hoose to collaborate with, which is great! Many believe they have a persona= l moral value of informing uneducated people, or protecting people from sec= urity threats, or hundreds of other particular preferences and opinions. Al= l of these are fantastic and I am glad these preferences or beliefs exist..= . but they cannot be coercively applied and we should not allow the bitcoin= project, or Bitcoin Core, or github, to be a platform for inflicting coerc= ive beliefs upon developers that have gifted us so much time, energy and ef= forts on a historically and systemically critical development.

There= fore, I think there might be an opportunity here to re-evaluate the nature = of open-source software development. I think there is an opportunity to re-= evaluate how we choose to work together. What if there was a better way to = collaborate on the work we do for bitcoin? What would it look like? What wo= uld be different? What would be kept the same?


# GitHub

U= nfortunately the situation is that GitHub does not have good moderation con= trols and was only built for a very narrow concept of open source developme= nt. The solution to brigading is better controls around the presentation la= yer or requiring some sort of membership. If you just have a perpetual open= door policy straight from reddit into your developer den, then yeah people= are going to walk in and take a shit on your desk where you were working w= ith another dev.. With some thinking I'm sure we can structure better ways = to get exposure to general public sentiment or opinion, while also structur= ing a space for development to take place that does not require blindly mix= ing off-topic content with developer content.


# Privatization
Here, I would like to make the case for privatizing Bitcoin Core softw= are development into a members-only gitlab or other kind of open-source sof= tware collaboration system. It would have the following properties. Issues = and pull requests would be private and not subject to public hyperlinking. = Anyone can register or apply for access. Whoever runs the site/repository w= ould be responsible for configuration, hosting, setup, moderation, access c= ontrol, etc. Software development would continue under the same license. Ne= w issues, comments, code review comments would possibly be licensed under a= specific license like CC0 or public domain or some other license, possibly= with PGP-signature to track agreement if we care about comments licensing.= Pull requests can be cross-posted to any number of repositories either pub= lic or private as much as any contributor wishes, except to the point where= any norm violation or spam violation occurs for the respective publishing = systems of course.


# Office culture

An alternative to wha= t I am proposing is already happening: development inside closed offices (C= haincode, Brink, Localhost, etc), which is less accessible and less open th= an a invite-only developer collab site. And also less "open development" th= an the current Bitcoin Core GitHub project. So a failure to sort out these = issues with Bitcoin Core collaboration can and has already produced solutio= ns that are functionally less inclusive than an online member-only source f= orge. It is to the detriment of the open project that so much gets discusse= d inside these private offices and many of us are not able to contribute th= at way, and there ought to be something between a public github that the ge= neral public can brigade and closed offices on the other end of the spectru= m.


# How it would work

Contributors would be free to coll= aborate on any branch, pull request, or privatized fork, or even public for= k. Issues, issue comments, pull request comments, code review comments, and= miscellaneous discussions can also be posted internally. Code can come fro= m inside the members-only repository, or it can be contributed from outside= sources if someone pulls it in, proposes it, or otherwise posts those patc= hes.

Releases can be cut and source code published all at once, if t= hat is desirable to anyone. However, I suspect that for Bitcoin Core, contr= ibutors would likely push changes out to various public access githubs or o= ther locations on an hourly, daily or regular basis. Bitcoin Core, as it ex= ists today, could do the same for pull requests, code review comments, etc,= and post them publicly on a website. Anyone would be free to make a websit= e where any person, including non-developers and including non-contributors= , could freely post code review or comments. This could even happen on the = current GH bitcoin/bitcoin repository. For example, any of the private code= review comments can be posted directly into the PR on GH. PGP signatures c= an be used for verifiable comment attribution. Or another website can be li= nked from a GH PR to display the private-originated review history.

= Brigading will be severely reduced and eliminated. You can pass around a li= nk to the repository and a comment or issue but nobody will be able to see = the content unless they are a registered member, which the vast majority of= all internet people won't be. This will severely curtail brigading and spa= m while also enabling continued ongoing development activities for collabor= ators.

Bitcoin Core itself has releases and maintainers that push th= e release button. I fully believe that even after privatizing Bitcoin Core = that they still will behave using the same norms and beliefs and systems th= at they presently do. Public code review will still continue. Public releas= es will still happen. There will still be open source code. But the ability= of attackers to steal attention or time from bitcoin developers will be se= verely reduced. Likewise for attackers ability to coerce bitcoin developers= through public spectacle where they do their core work. I believe that the= community would be more productive and more energized if we regularly used= a privatized collaboration platform.

In practice, the way that this= would roll out is that the GitHub would continue to be the GitHub and woul= d not really change. There would be a separate private area for some develo= pers to work together. Then they would throw it over the wall or have some = sort of (possibly real-time) synchronization protocol to synchronize pull r= equests to the public GitHub repository. If you want a public link on X.com= then link to that, but a link to the membership-required site won't work f= or non-members.

For the private work space: I think registration, co= upled with a delay, coupled with a probationary period would probably be su= fficient. Possibly also with review or, what could be interesting as if at = least two people out of any of the members have to recommend the user for e= ntry. 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 su= ch as, if you just show up to cause chaos then you lose your access to the = members-only place and you will have to post code somewhere else on the int= ernet. It won't be that anyone can show up and cause chaos and never be sil= enced or banned.

Adoption: would not be too difficult, as only two o= r three developers can privately experience some benefits. They can also us= e private one-time expiring links to temporarily include non-members as the= y see fit.


# Theory crafting

Non-technical activist movem= ents have a history of making open discussion forums non-viable. Those same= non-technical activist movements also have a history of making many non-vi= able forks, due to for example a lack of technical expertise in said moveme= nts. I would like to find ways to redirect efforts that would manifest as u= nusable discussion forums, instead, towards the creation of more non-viable= forks.

We can remain committed to making forking as frictionless as= we can, while also increasing the friction of participation of non-technic= al actors in members-only technical discussion forums. The existence of mem= bers-only technical discussion forums does not preclude the existence of pu= blic channels, nor does it prohibit the flow of information in either direc= tion. It merely carves out a specific space and area.

Something alon= g the lines of: "We are willing to commit to your freedom to create and run= software of your choosing. We are not committed to internalizing often coe= rcive demands that *we* be the ones to create the exact software of your ch= oosing. We hope that you like the software we work on, and we welcome your = feedback in the right time and place, just not in private developer spaces.= "

Open source software has a lot of history behind it and establishe= d developer culture norms. Open here usually refers to the source code lice= nsing (see early 90s work from Foresight Institute's Christine Peterson's O= pen Source Definition initiative). "Open" development does not mean "open t= o coercion". It feels very weird to write an email that essentially amounts= to reminding grown adults that they can freely collaborate in any way they= wish, and that they do not have to invite or subject themselves to active = ongoing attempts of coercion. Even if it's from "the public". There are fre= e-for-all places all over the Internet to post that kind of content, or to = read it and review it. There are also other possibilities for structured ac= cess 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 su= bjected to coercion attempts from internet mobs have simply left the public= collaboration process to either retreat into office in-person settings or = stop contributing to bitcoin development entirely...

Also, it does n= ot feel good to ban people or clean up brigades to restore structure or ord= er 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 platform= ing people who disagree with you or hate you outright. "Coercive platformin= g" happens when others demand you platform their speech content even if it'= s off-topic or low signal or actively directly hostile to you. Meanwhile de= v attention is scarce and while it's individually regulated (as it should b= e), care should be taken to monitor if the obvious default regulation is fo= r developers to simply disengage or not engage at all, which would be a det= riment to the bitcoin project. Instead we can filter the noise going into t= he system at the top of the funnel instead of the bottom (comments level).<= br>
One goal is that we are interested in having more developers join an= d collaborate on Bitcoin Core. Creating an environment conducive to new dev= elopers is important and if they have to also be subjected to a bunch of no= ise just to collaborate on code on GitHub then I think that is sub-optimal = and a self-defeating strategy if one of the goals is growth in the number o= f developers or contributors.

What I think people might be upset abo= ut this idea to privatize is that, to the extent that people perceive that = they are currently able to coerce developers to work on specific things any= given developer wouldn't have worked on otherwise, and if any developer co= llaborations voluntarily retreat to their own private work area, then I thi= nk those same people might get upset to the extent they perceive or feel th= at they are losing a coercive lever over developers that they previously th= ought they had (perhaps permanent) power over. In reality, it has always be= en a voluntary non-coercive arrangement, it's just that people get confused= about the social dynamics and forget this isn't feudalism slave labor era = anymore.



# End of remarks

Building this sort of prote= ction measure is important for the ongoing and future success of the projec= t. As a moderator in the bitcoin-dev project it is hard for me to communica= te the levels of attacks that we have seen and that I expect to see going f= orward. We are talking about a trillion dollar system. We are talking about= disrupting tens of trillions of dollars of value. And there are massive ad= versarial forces, including nation state and non-state actors with tremendo= usly deep resources, that are completely adverse to what we stand for and w= hat we believe and what bitcoin is or what bitcoin will become. These sorts= of threats are completely unlike any other open source software project ha= s ever seen, and if anything I am underestimating what we are up against. T= his isn't to say to throw out our values and enact bitcoin governance or wh= atever; instead it's an opportunity to look at what tools we have at our di= sposal to counter these threats and ensure our continued productivity and t= hat our open community can remain open without also cutting ourselves off.<= br>



Humbly my own,

Bryan Bishop= aka kanzure

June 2025


https://www.lesswrong.com/posts/t= scc3e5eujrsEeFN4/well-kept-gardens-die-by-pacifism
https://meaningness.com/geeks-mops-sociopaths
<= a href=3D"https://github.com/bitcoin-core/meta/issues/19" target=3D"_blank"= rel=3D"noreferrer nofollow noopener">https://github.com/bitcoin-core/meta/= issues/19
https://x.com/kan= zure/status/1932534820607045947

P.S. I still think bitcoin-core/= meta on GH should be deleted. It's relatively recent and nothing of value w= ill be lost that cannot be re-hosted should it ever prove necessary to do s= o.

--
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/CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPD= ZKsjB8w%40mail.gmail.com.

--
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/bitcoindev/= 4iW61M7NCP-gPHoQZKi8ZrSa2U6oSjziG5JbZt3HKC_Ook_Nwm1PchKguOXZ235xaDlhg35nY8Z= n7g1siy3IADHvSHyCcgTHrJorMKcDzZg%3D%40protonmail.com.
--b1=_vUSNfO4MTt8ZXrFmfmBvQoOkgY4jDRPrjzG8CDHQ8Q--