From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 10 Jun 2025 13:40:23 -0700 Received: from mail-oo1-f55.google.com ([209.85.161.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 1uP5ld-0001K9-4D for bitcoindev@gnusha.org; Tue, 10 Jun 2025 13:40:23 -0700 Received: by mail-oo1-f55.google.com with SMTP id 006d021491bc7-60f3ce73b8esf2423885eaf.1 for ; Tue, 10 Jun 2025 13:40:21 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1749588015; cv=pass; d=google.com; s=arc-20240605; b=EZUw0tf3nH/V4gHD3L5TZJUd26ul45ZQmQeXElY1NtNgA6k6tSvsxHFw4flKOLja1I BwjYB0XU+CUyvX5rOc4ECGGC2LT/wq+wjHxJ1TQOT1MgQfm1Xn44Fecu35TB9j/LEkNe O6y/apnv1y93yl2+e4iNKQxgfd72TG9DCnVNMwNswupndTockFMXVILPa5/Sh8eR4ORK DWvAYK2X/p5x0lxbjtUyg5Gfsi4LmgdOfykreojo6TFJ+SU5B5qlxUW85a50vtkt8lI5 j5kLK3wwo2N+k2+DQpLHQkIQ1mp2VDuXuRPhGIO0WDqAwECkREY/fQiHzJmfZ6EPtn1f 8Uiw== 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:cc:to:subject:message-id:date:from :mime-version:sender:dkim-signature:dkim-signature; bh=n3L3d52oBzwsY0zGxKYqWIMGcRMLLXGvOuKqDZ39gV8=; fh=gBZU9p1LtMIWw7FC8XR8Doo3ekw/0aaacwKJY1IpAzI=; b=MnKtZFODDutFlYQq6El36nKQ6Zt0DdGT7VooAQ/f4ARYUHB/DydrTn4f0hBW/1xrhC DVJyJXpIdY3oE49nf+/0Gis+pxE13tOWMQvyCw+65oH3yGIyjR0brLIahVoqpRovfm8t VNoEfOh6iwmF7H5flugtVk3TiMkNc2lV8o7W6rTnbfxPnTmQmlDTBCbyeJdPWtsM5FCl uVDOdKolc+gcba93joF/ONMVtJ4HWWBYdI51TAVX8u7Gx1/uQnmQhOAJWku5HBKZLdCP 0S74k5psg+OyuwUSXjJMDG7dk7qseXBXCuES1fUAtr6bfPOga4AWlSO4OIMij1RA5P+/ z81w==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=e0EN6iu+; spf=pass (google.com: domain of kanzure@gmail.com designates 2a00:1450:4864:20::535 as permitted sender) smtp.mailfrom=kanzure@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1749588015; x=1750192815; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:mime-version :sender:from:to:cc:subject:date:message-id:reply-to; bh=n3L3d52oBzwsY0zGxKYqWIMGcRMLLXGvOuKqDZ39gV8=; b=L8uh8LSZQ9qCtHVs3L3rb8wsbvjL9WgGMErMQ0mFqMMCeqIhX9kBLUR5+oU2iv5sGp 2VwC4c0+Ee3K54egABCysc8KQl8tVVlJUL6ScOJg5+0WSDNupS9dll+kZSibljz8JP77 hhlvijrzzViXnyGG90rsPzRwr8ygiD1lgpojaWwRD7xrgizd+TBFhl9DAWbB4JmSFrQe CMY2ER4oI/1ikisO0zsPgQGGuQvQ+kJ8DraLrUivkbhjShZpsH2xtjbSwkohNR6JxtAN XN5E1vTdEvihOOhwHC0apO2aOZLiWhT/mABllZKAVYbLDVRy1RdR2Xscs49YEeSCCVL6 GkJA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749588015; x=1750192815; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=n3L3d52oBzwsY0zGxKYqWIMGcRMLLXGvOuKqDZ39gV8=; b=nEMqgItfPlypxELAdvIAn+CmpydXOJGubrHEfvVd0cWobmC7YBIHRRhMCGZOtRLaC5 WbLlpBgqAmY0PupGWZeFNH1srdXuRqgWLs9pemeOxD7BSOeNqPX7cVFdSe0lBOqS1JZA voE3tWuqYiqOP2+dijLPCb1UG7E/3GtJiPfNlucMf7IZNLhFY/XZQJ5oYMlSfUTUyxk6 27qoGc9bVDO3BESCilsZsGhWACv3NdpEIxIKVbbT+Xrnep/kYWyDOHGJKBSKgbOGdGrQ pFiZmOD+mFAq7asn/d9nXLhSSFvjiOp8/oQCV+GC2zm1I2SyOxCuDzF70D/LCAN+6TRz iv+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749588015; x=1750192815; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:mime-version :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to; bh=n3L3d52oBzwsY0zGxKYqWIMGcRMLLXGvOuKqDZ39gV8=; b=A8i+4AWqHIzSdGIOvO+jGyjBwkFfr3CCXzHSWBM6ealKpl68Tk/nM+jKsjfKCzrVOM 7T6kj5WAa380lcnn1E0ssXx4UuvgezvjYEAZNaOk8zvfAaXmpU5AIRxvgnLXE0gDOnBv eQ8R5HqWx6XTLlirar6muv3UlAf/WfnSh/rYocAO2FF60jFCYdVNIGExlTOT7WERSxuX +drzWa8opQFjcg7jrYJ2adEjLy+Hm5OCoT7i8LxenD73AGI0R4r8eJIYbAmOXDfGGMET hR3kvgY3dOEnNssKnkfmWgJ5EQftdyTP/UGPEynkdl3JG4MM3dCz0r/BSa4rsgevEekt KYkg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVpqgpvvvHk/Oh4JEguMzL7oaQHTosiu8Ewa8zeNKXOUhYPH7nmvduQrTqqNx555VDPuTTC9UV+zh3Z@gnusha.org X-Gm-Message-State: AOJu0Yzpb/TJbllNRxn+YrXpYdbCNQPz5krLLPudV/LD9Ke31QrWhfBp j9tzXFfBTpbW5zXwtOjPFayaoU0uyAbtIXhfObtbIAr7iy2Nn77BEYUa X-Google-Smtp-Source: AGHT+IG/LzLW6Gb1eGDcxoNWxwxUpyevll6FezSkw+lIin3wVbMwE//mh5Rntdm+rb681MQZjj93TQ== X-Received: by 2002:a05:6820:1e06:b0:610:cc02:2137 with SMTP id 006d021491bc7-610ef688ea5mr395563eaf.1.1749588015400; Tue, 10 Jun 2025 13:40:15 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZe6CrbyKsdsbfX2Jn/TPR/yPtpAhjhAhEKGLk1wNVP/eg== Received: by 2002:a05:6820:4105:b0:601:afcc:164d with SMTP id 006d021491bc7-60f283b2afdls1584990eaf.1.-pod-prod-02-us; Tue, 10 Jun 2025 13:40:12 -0700 (PDT) X-Received: by 2002:a05:6808:3206:b0:406:1e0c:319d with SMTP id 5614622812f47-40a5d123ac5mr591914b6e.19.1749588012699; Tue, 10 Jun 2025 13:40:12 -0700 (PDT) Received: by 2002:a50:d6c7:0:b0:604:5e91:86bb with SMTP id 4fb4d7f45d1cf-60846f99c3amsa12; Tue, 10 Jun 2025 13:31:24 -0700 (PDT) X-Received: by 2002:a05:6402:1941:b0:607:6619:1092 with SMTP id 4fb4d7f45d1cf-60846af42f2mr534187a12.13.1749587482162; Tue, 10 Jun 2025 13:31:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1749587482; cv=none; d=google.com; s=arc-20240605; b=Zcz6np0r1JSa7FEARkg6mxzS0h51IONHTByCQH7Q6hPu2lbQgR0hi6NDmSnUHqtYqy sD90KRfoFBiZQJkfEesZAUwuM7JmJIOCe5FGDov5GnR1d+xW+1vGT+TaYBr0Q+o3tbwN bgyBHFoRnS5WojHCBSraI47CAOBgk73Mcgcjhv304tKAdC2uaTQfbnMgGkRdlBue0YOd iQ6yvh1YOlKksbglbhdmSx/UuAuq0/ZJuJtfK3SJGzQGi/we7ns9MmxvkSBMYFQPOKlE Kahw0IEntNE79N5A5ALxMGq3IBZJYtbQ5xRbaZPyTWkbTOnA/4FWQWZLPAjFy3TX8GLS pDnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:mime-version:dkim-signature; bh=jw9Px+r+0pv4HaCVa19R1MUzlBlxVlac32R7owO6Hls=; fh=J4aR1+1k9nQ9J+xtTlCA8yR//0DGKxczo4HNGfDNblg=; b=VFawjbT2d4wsmiHyT/yUFsb37hIBbDAfDWX291BXoeivEgsWqPE7QWitMKhZC7qbH+ J9O0MgiAHw/v8Gok6ith5kwDmZIebN0DCqtLTMqmZH1BaMNynHgkaBcoMfJ740cutSpt YB3vG25uwhmEAzRfjuApnToE1Guj3S/fDRsvDRulkzrMXiANGcq+tv9WFHi5Xtd0UCV9 KLbq2QaZm57KctuY1nJWaK2FEaQMe5WqIFKFZ0BDA2Ne4bc+o1LvXKcR9z56SwtUDIDc rdX6ng/vUj5D/pjjjHlJ/BpqQ/193f5CN+JFHvAd0p8fdLG0/ICtve4anJTI8N6RAGhw Rzhg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=e0EN6iu+; spf=pass (google.com: domain of kanzure@gmail.com designates 2a00:1450:4864:20::535 as permitted sender) smtp.mailfrom=kanzure@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com. [2a00:1450:4864:20::535]) by gmr-mx.google.com with ESMTPS id 4fb4d7f45d1cf-607783750d7si419833a12.2.2025.06.10.13.31.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Jun 2025 13:31:22 -0700 (PDT) Received-SPF: pass (google.com: domain of kanzure@gmail.com designates 2a00:1450:4864:20::535 as permitted sender) client-ip=2a00:1450:4864:20::535; Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-60779962c00so5806912a12.0 for ; Tue, 10 Jun 2025 13:31:22 -0700 (PDT) X-Gm-Gg: ASbGncvVTOpb/HdiViM1o7AqaE6xSob8LFCRr0JOGp0o7tiWumVQuazRbgaY3rpW01u +524fiNaXcptvDy/ZUk9fuxTRmySO6NqmXE91asm+jeP9MM6eFM/GZXcF98ZDx/s8vheGQ2PQBm n62GunO/8Mu3f/a4CzpyW0bD+Mn/c6MlQwC+k+2z8MN+9hrVATftYVIzHNgcmquhJPia0eG9TPr NnN8A== X-Received: by 2002:a17:907:9414:b0:ad8:a329:b4a0 with SMTP id a640c23a62f3a-ade8955eeffmr80178566b.24.1749587480287; Tue, 10 Jun 2025 13:31:20 -0700 (PDT) MIME-Version: 1.0 From: Bryan Bishop Date: Tue, 10 Jun 2025 15:31:07 -0500 X-Gm-Features: AX0GCFuGoLGDvCkTEub2VKzi3c38w5xEdIU5ULGfNnZf5chxUM-Db0mseE108rA Message-ID: Subject: [bitcoindev] The case for privatizing Bitcoin Core To: bitcoindev@googlegroups.com Cc: Bryan Bishop Content-Type: multipart/alternative; boundary="000000000000441df206373d9463" X-Original-Sender: kanzure@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=e0EN6iu+; spf=pass (google.com: domain of kanzure@gmail.com designates 2a00:1450:4864:20::535 as permitted sender) smtp.mailfrom=kanzure@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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 (/) --000000000000441df206373d9463 Content-Type: text/plain; charset="UTF-8" The case for privatizing Bitcoin Core: I believe that reflection is critical for curiosity, understanding, improvement, and progress. And recent activity on the Bitcoin Core github account has given me an opportunity to re-evaluate my beliefs about open-source software 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) 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 like wasting people's valuable time, creating manufactured controversy, misinformation, etc. It is trivial to see how exposure to deep technical content can cause confusion or misunderstanding for non-technical people who may not even know the ethos of open-source development or what bitcoin developers really do or believe about what they do. Unsolicited feedback from random/new people and even noise can sometimes be useful and thankfully 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 whatever our hearts desire, and we can freely do that over the Internet or in person 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 non-developer bitcoiners are not obligated, like they are not obligated to 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 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 values 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 people from security threats, or hundreds of other particular preferences and opinions. All 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 coercive beliefs upon developers that have gifted us so much time, energy 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 development. The solution to brigading is better controls around the presentation layer 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 with another dev.. With some thinking I'm sure we can structure better ways to get exposure to general public sentiment or opinion, while also structuring 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 software 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 would be responsible for configuration, hosting, setup, moderation, 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 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 public 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 what I am proposing is already happening: development inside closed 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 has already produced solutions that are functionally less inclusive than an online 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 the other 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, or it can be contributed from outside sources if someone pulls it in, proposes it, or otherwise posts those patches. Releases can be cut and source code published all at once, if that is desirable to anyone. However, I suspect that for Bitcoin Core, contributors would likely push changes out to various public access githubs or other locations 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 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 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 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 spam while also enabling continued ongoing development activities for collaborators. Bitcoin Core itself has releases and maintainers that push the release button. I fully believe that even after privatizing Bitcoin Core that they still will behave using the same norms and beliefs and systems that they presently do. Public code review will still continue. Public releases 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 severely 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 would not really change. There would be a separate 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 you want a public link on X.com then link to that, but a link to the membership-required site won't work for non-members. For the private work space: I think registration, coupled with a delay, coupled with a probationary period would probably be sufficient. 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 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 chaos 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 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 expiring 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 technical expertise in said movements. I would like to find ways to redirect efforts that would manifest as unusable 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-technical actors in members-only technical discussion forums. The existence of members-only technical discussion forums does not preclude the existence of public channels, nor does it prohibit the flow of information in either direction. It merely carves out a specific space and area. Something along 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 coercive demands that *we* be the ones to create the exact software 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 developer spaces." Open source software has a lot of history behind it and established developer culture norms. Open here usually refers to the source code licensing (see early 90s work from Foresight Institute's Christine Peterson's Open Source Definition initiative). "Open" development does not mean "open to 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 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 possibilities 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 simply 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 restore 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 actively directly hostile to you. Meanwhile dev attention is scarce and while it's individually regulated (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, which would be a detriment to the bitcoin project. Instead we can filter the noise 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 collaborate on Bitcoin 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 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 developers 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 developers to work on specific things any given developer wouldn't have worked on otherwise, and if any developer collaborations voluntarily retreat to their own private work area, then I think those same people might get upset 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 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 protection measure is important for the ongoing and future success of the project. As a moderator in the bitcoin-dev project it 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 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 believe and what bitcoin is or what bitcoin will become. These sorts of threats are completely unlike any other open source software project has ever seen, and if anything I am underestimating what we are up against. This isn't to say to throw out our values and enact 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-by-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 relatively recent and nothing of value will be lost that cannot be re-hosted should 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/bitcoindev/CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w%40mail.gmail.com. --000000000000441df206373d9463 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The case for privatizing Bitcoin Core:

I belie= ve that reflection is critical for curiosity, understanding, improvement, a= nd progress. And recent activity on the Bitcoin Core github account has giv= en me an opportunity to re-evaluate my beliefs about open-source software d= evelopment on GitHub.


# The ongoing problem

What happened= was nothing new. It has happened before and it will happen again, especial= ly if we do nothing new or different. Essentially there is a recurring patt= ern of non-contributors (sometimes even non-developers) intruding into an o= nline forum intended mainly for people collaborating on Bitcoin Core to wor= k together on whatever they are working on. This often causes issues like w= asting people's valuable time, creating manufactured controversy, misin= formation, etc. It is trivial to see how exposure to deep technical content= can cause confusion or misunderstanding for non-technical people who may n= ot even know the ethos of open-source development or what bitcoin developer= s really do or believe about what they do. Unsolicited feedback from random= /new people and even noise can sometimes be useful and thankfully 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 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= that argument. There are no additional explicit obligations beyond the lic= ense. I'll add, though, that many developers have their own moral value= s and beliefs about how they should act and behave, and how that informs wh= o they choose to collaborate with, which is great! Many believe they have a= personal moral value of informing uneducated people, or protecting people = from security threats, or hundreds of other particular preferences and opin= ions. All 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 inflicti= ng coercive beliefs upon developers that have gifted us so much time, energ= y 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 opportunit= y 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<= br>
Unfortunately the situation is that GitHub does not have good modera= tion controls and was only built for a very narrow concept of open source d= evelopment. The solution to brigading is better controls around the present= ation layer or requiring some sort of membership. If you just have a perpet= ual open door policy straight from reddit into your developer den, then yea= h people are going to walk in and take a shit on your desk where you were w= orking with another dev.. With some thinking I'm sure we can structure = better ways to get exposure to general public sentiment or opinion, while a= lso structuring a space for development to take place that does not require= blindly mixing off-topic content with developer content.


# Priv= atization

Here, I would like to make the case for privatizing Bitcoi= n Core software development into a members-only gitlab or other kind of ope= n-source software collaboration system. It would have the following propert= ies. Issues and pull requests would be private and not subject to public hy= perlinking. Anyone can register or apply for access. Whoever runs the site/= repository would be responsible for configuration, hosting, setup, moderati= on, access control, etc. Software development would continue under the same= license. New issues, comments, code review comments would possibly be lice= nsed under a specific license like CC0 or public domain or some other licen= se, possibly with PGP-signature to track agreement if we care about comment= s licensing. Pull requests can be cross-posted to any number of repositorie= s either public 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 altern= ative to what I am proposing is already happening: development inside close= d offices (Chaincode, Brink, Localhost, etc), which is less accessible and = less open than a invite-only developer collab site. And also less "ope= n development" than the current Bitcoin Core GitHub project. So a fail= ure to sort out these issues with Bitcoin Core collaboration can and has al= ready produced solutions that are functionally less inclusive than an onlin= e 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 pub= lic github that the general public can brigade and closed offices on the ot= her end of the spectrum.


# How it would work

Contributors= would be free to collaborate on any branch, pull request, or privatized fo= rk, or even public fork. Issues, issue comments, pull request comments, cod= e review comments, and miscellaneous discussions can also be posted interna= lly. Code can come from inside the members-only repository, or it can be co= ntributed from outside sources if someone pulls it in, proposes it, or othe= rwise posts those patches.

Releases can be cut and source code publi= shed all at once, if that is desirable to anyone. However, I suspect that f= or Bitcoin Core, contributors would likely push changes out to various publ= ic access githubs or other locations 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 any person, including non-developers and incl= uding non-contributors, could freely post code review or comments. This cou= ld even happen on the current GH bitcoin/bitcoin repository. For example, a= ny of the private code review comments can be posted directly into the PR o= n GH. PGP signatures can be used for verifiable comment attribution. Or ano= ther website can be linked from a GH PR to display the private-originated r= eview history.

Brigading will be severely reduced and eliminated. Yo= u can pass around a link to the repository and a comment or issue but nobod= y will be able to see the content unless they are a registered member, whic= h the vast majority of all internet people won't be. This will severely= curtail brigading and spam while also enabling continued ongoing developme= nt activities for collaborators.

Bitcoin Core itself has releases an= d maintainers that push the release button. I fully believe that even after= privatizing Bitcoin Core that they still will behave using the same norms = and beliefs and systems that they presently do. Public code review will sti= ll continue. Public releases will still happen. There will still be open so= urce code. But the ability of attackers to steal attention or time from bit= coin developers will be severely reduced. Likewise for attackers ability to= coerce bitcoin developers through public spectacle where they do their cor= e work. I believe that the community would be more productive and more ener= gized if we regularly used a privatized collaboration platform.

In p= ractice, the way that this would roll out is that the GitHub would continue= to be the GitHub and would not really change. There would be a separate pr= ivate area for some developers to work together. Then they would throw it o= ver the wall or have some sort of (possibly real-time) synchronization prot= ocol to synchronize pull requests to the public GitHub repository. If you w= ant a public link on X.com then link to that, but a link to the membership-= required site won't work for non-members.

For the private work s= pace: I think registration, coupled with a delay, coupled with a probationa= ry period would probably be sufficient. Possibly also with review or, what = could be interesting as if at least two people out of any of the members ha= ve to recommend the user for entry. Or, you can do proof-of-work to get ent= ry 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 mod= eration and rules of engagement such as, if you just show up to cause chaos= then you lose your access to the members-only place and you will have to p= ost code somewhere else on the internet. It won't be that anyone can sh= ow up and cause chaos and never be silenced or banned.

Adoption: wou= ld not be too difficult, as only two or three developers can privately expe= rience some benefits. They can also use private one-time expiring links to = temporarily include non-members as they see fit.


# Theory crafti= ng

Non-technical activist movements have a history of making open di= scussion forums non-viable. Those same non-technical activist movements als= o 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 red= irect efforts that would manifest as unusable discussion forums, instead, t= owards the creation of more non-viable forks.

We can remain committe= d to making forking as frictionless as we can, while also increasing the fr= iction of participation of non-technical actors in members-only technical d= iscussion forums. The existence of members-only technical discussion forums= does not preclude the existence of public channels, nor does it prohibit t= he flow of information in either direction. It merely carves out a specific= space and area.

Something along the lines of: "We are willing = to commit to your freedom to create and run software of your choosing. We a= re not committed to internalizing often coercive demands that *we* be the o= nes to create the exact software of your choosing. We hope that you like th= e software we work on, and we welcome your feedback in the right time and p= lace, just not in private developer spaces."

Open source softwa= re has a lot of history behind it and established developer culture norms. = Open here usually refers to the source code licensing (see early 90s work f= rom Foresight Institute's Christine Peterson's Open Source Definiti= on initiative). "Open" development does not mean "open to co= ercion". It feels very weird to write an email that essentially amount= s to reminding grown adults that they can freely collaborate in any way the= y 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-all places all over the Internet to post that kind of = content, or to read it and review it. There are also other possibilities fo= r structured access and presentation of that kind of data. For example, a r= everse 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 simply = left the public collaboration process to either retreat into office in-pers= on settings or stop contributing to bitcoin development entirely...

= Also, it does not feel good to ban people or clean up brigades to restore s= tructure 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 j= ust wanna code or build cool stuff. It's a partner to free speech.. you= r free speech means that you don't have to say things you don't agr= ee with, including platforming people who disagree with you or hate you out= right. "Coercive platforming" happens when others demand you plat= form their speech content even if it's off-topic or low signal or activ= ely directly hostile to you. Meanwhile dev attention is scarce and while it= 's individually regulated (as it should be), care should be taken to mo= nitor if the obvious default regulation is for developers to simply disenga= ge or not engage at all, which would be a detriment to the bitcoin project.= Instead we can filter the=C2=A0noise going into the system at the top of t= he funnel instead of the bottom (comments level).

One goal is that w= e are interested in having more developers join and collaborate on Bitcoin = 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 collaborate o= n code on GitHub then I think that is sub-optimal and a self-defeating stra= tegy if one of the goals is growth in the number of developers or contribut= ors.

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 t= o coerce developers to work on specific things any given developer wouldn&#= 39;t have worked on otherwise, and if any developer collaborations voluntar= ily retreat to their own private work area, then I think those same people = might get upset to the extent they perceive or feel that they are losing a = coercive lever over developers that they previously thought they had (perha= ps permanent) power over. In reality, it has always been a voluntary non-co= ercive arrangement, it's just that people get confused about the social= dynamics and forget this isn't feudalism slave labor era anymore.
<= br>

# End of remarks

Building this sort of protection measure= is important for the ongoing and future success of the project. As a moder= ator in the bitcoin-dev project it is hard for me to communicate the levels= of attacks that we have seen and that I expect to see going forward. We ar= e talking about a trillion dollar system. We are talking about disrupting t= ens of trillions of dollars of value. And there are massive adversarial for= ces, including nation state and non-state actors with tremendously deep res= ources, that are completely adverse to what we stand for and what we believ= e and what bitcoin is or what bitcoin will become. These sorts of threats a= re completely unlike any other open source software project has ever seen, = and if anything I am underestimating what we are up against. This isn't= to say to throw out our values and enact bitcoin governance or whatever; i= nstead it's an opportunity to look at what tools we have at our disposa= l to counter these threats and ensure our continued productivity and that o= ur open community can remain open without also cutting ourselves off.



Humbly my own,

Bryan Bishop aka = kanzure

June 2025


https://www.lesswr= ong.com/posts/tscc3e5eujrsEeFN4/well-kept-gardens-die-by-pacifism
https://meaningness= .com/geeks-mops-sociopaths
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 val= ue will be lost that cannot be re-hosted should it ever prove necessary 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/ms= gid/bitcoindev/CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w%40mail.g= mail.com.
--000000000000441df206373d9463--