The case for privatizing Bitcoin Core
1,157 views
Skip to first unread message
Bryan Bishop
Jun 10, 2025, 4:40:15 PMJun 10
to bitco...@googlegroups.com, Bryan Bishop
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.
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.
Dave Scotese
Jun 11, 2025, 8:02:07 PMJun 11
to Bryan Bishop, bitco...@googlegroups.com
Thanks for the great write-up!
I don't think "Please be less shy about moderation on Github" is too much to ask. I'm not sure much else needs to be done. I also suspect that there's a lot of deep understanding of the tools (github, gitlab, etc.) that can already be used to thwart coercive brigading. Perhaps those who control the public facing accounts could benefit from some help from people who understand those tools better than I do.
Dave Scotese.
--
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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w%40mail.gmail.com.
I own Litmocracy and Meme Racing (in alpha).
I'm the webmaster for The Voluntaryist which now accepts Bitcoin.
"He ought to find it more profitable to play by the rules" - Satoshi Nakamoto
I'm the webmaster for The Voluntaryist which now accepts Bitcoin.
"He ought to find it more profitable to play by the rules" - Satoshi Nakamoto
Michael Folkson
Jun 11, 2025, 8:02:07 PMJun 11
to Bitcoin Development Mailing List
Hi Bryan
Thanks for your email and thanks for maintaining an archive of the bitcoin-dev mailing list.
I'm personally sympathetic with a lot of this with one significant caveat. I've stated this caveat multiple times before ([0], [1], [2] etc) but I will state it again because it is critically important and people who really should know better (not necessarily you) should have understood and accepted this by now.
A consensus rule change is different to any other change (transaction relay policy, wallet, GUI, test etc). If consensus compatible forks of Bitcoin Core want to maintain different mempool policies, wallet features, GUIs etc they are free to with no chain split risk assuming they don't accidentally introduce a consensus bug which Core has made as easy to avoid as possible over the years. Hence we have seen Knots, Libre Relay etc introduce different mempool policies to Core without a chain split or a split of the network. The recent statement by Core stating what its current contributors prioritize when designing transaction relay policy [3] and the communication around the recent transaction relay policy pull request (#32404) merge decision [4] I thought was excellent. However to take that precedent on Core *transaction relay policy* (a signed statement by a set of Core contributors and signposting around the merge decision) and assume it can be applied to a *consensus rule change* (CTV and CSFS or whatever the current set of opcodes is currently in vogue) requesting Core contributors prioritize review within 6 months is short sighted to put it mildly. Core can make unilateral decisions on transaction policy because consensus compatible forks can have different transaction policy without splitting the chain or the network. It can't make unilateral decisions on a consensus rule change. If there is significant disagreement on a consensus rule change an attempted consensus rule change can split the network and create two currencies.
Hence if Core wants to make merge decisions on transaction relay policy pull requests based on its recent statement I think that is fine. If it wants to hide comments on such a pull request that don't accept that statement I think that is fine. But if it wants to create a set of contributors who think they can effectively decide on consensus rule changes without the input of the broader community that is clearly not fine.
There is a secondary issue that in a world of consensus compatible forks Core really shouldn't make maintaining those consensus compatible forks unnecessarily difficult or impossible. If users disagree with that aforementioned transaction relay statement for example but Core also makes merge decisions that makes maintaining consensus compatible forks unnecessarily difficult or impossible then those users have nowhere to go. In that sense Core is shaping up to effectively be like the Linux kernel and however the project is managed in the repo it needs to be monitoring and engaging with consensus compatible forks.
Thanks
Michael
Christopher Allen
Jun 12, 2025, 1:27:47 PMJun 12
to Bryan Bishop, bitco...@googlegroups.com
In response to: https://groups.google.com/g/bitcoindev/c/43yjt8MXMvo
moderation limitations are real. We've seen how open platforms without
clear boundaries invite persistent disruption — not just trolling, but
sustained efforts to derail meaningful technical collaboration.
But rather than framing this as a call for *privatization*, I think
it's more productive to view the problem through the lens of
*decentralization*. Git is already a distributed protocol — we should
be using it that way. We need infrastructure that supports secure,
accountable collaboration without relying on centralized gatekeepers,
corporate platforms, or closed offices.
## Git is Already Distributed — Let's Lean Into That
Git is a distributed version control system by design. In principle,
any developer or group of developers can work together on their own
forks, branches, or remotes — and coordinate externally from GitHub if
necessary. What we often lack is robust and usable *infrastructure*
for decentralized collaboration: systems that offer structure,
provenance, access control, and cryptographic guarantees, without
reverting to centralized or closed development.
## Open Source vs. Open Development
It’s also important to recognize that an open-source license alone is
insufficient for true "Open Development". Sustainable open development
depends not just on permissive licensing, but on values like
transparent governance, verifiable contributions, and non-coercive
collaboration. "Open Development" is a broader process that considers
who can participate, how trust is earned, and what incentives shape
behavior. These questions are especially vital in a high-stakes
project such as Bitcoin Core.
I've written an article on Open Development
https://www.blockchaincommons.com/articles/Open-Development/ that I
invite you to read as a parallel stream to this discussion.
## Transparency Is Not a Given — It’s a Design Decision
One criticism that has surfaced around Open Development is the idea
that Bitcoin Core developers have a "duty of transparency." But this
expectation is rarely defined. Is it a duty to publish *code*, to
explain *decisions*, to make *deliberations* public in real time — or
something else entirely?
If transparency is important to Bitcoin’s social contract, then we
should talk about what it actually entails, how it's balanced against
resilience, and where it begins and ends. Developers already meet
significant transparency obligations: reproducible builds, tagged
releases, and open review processes. That’s not nothing.
But assuming an *unlimited* or *unspecified* duty to perform
transparently — in every venue, at every stage — can easily become a
vector for coercion or burnout. Like every part of this system,
transparency needs intentional architecture, not moral ambiguity.
## A Proof-of-Concept: Open Integrity Project
I help maintain the [Open Integrity
Project](https://github.com/OpenIntegrityProject/core), which explores
how Git repositories can be used as cryptographic roots of trust. Our
work includes:
* "Inception Commits" to establish a verifiable origin.
* A signed `.allowed_commit_signers` policy to verify contributors.
* Future plans for branch distribution via Bittorrent's DHT,
FROST-based threshold signing, decentralized governance, and other
methods.
Open Integrity is *not a proposal for Bitcoin Core Developement*. But
it proves that decentralized coordination around open-source codebases
can be more secure, intentional, and resilient — while remaining
transparent and permissively licensed.
## Radicle and Other Directions
Radicle (https://radicle.xyz) is another working example. It shows
that peer-to-peer Git hosting and identity infrastructure are real and
usable today. It may not fit every contributor, but it makes clear
that **decentralization** — not privatization — is a viable and
thoughtful alternative to GitHub’s constraints.
## Structuring for Sovereignty
Public dev spaces come with power dynamics — and attackers exploit
them. We need tools and norms that protect developer autonomy without
killing transparency. That’s not impossible. But we have to build for
it, not assume it comes for free.
As I said, we shouldn't frame these transitions as “privatizing”
development, but we should instead focus on how to **structure
decentralized collaboration** more effectively — with clear
boundaries, strong tooling, and healthy expectations. Still open, but
designed to resist coercion and chaos.
Let’s explore optional decentralized spaces where trust is earned,
review is rigorous, and participation remains open — but under
conditions that developers can actually work within. No gates, just
better scaffolding.
-- Christopher Allen, Blockchain Commons
P.S. As context for those who don't know me: I've been working on
secure software since the early '90s — contributing to projects like
RSAREF (used by PGP, Digicash, and other early cryptographic tools),
SSLREF which led to TLS 1.0, and more recently the W3C DID 1.0 spec.
I’ve participated in and helped shape multiple open-source and
standards communities over the decades, including during my brief time
at Blockstream and now with Blockchain Commons. My long view informs
my belief that better tooling and clearer boundaries can preserve both
openness and resilience.
> The case for privatizing Bitcoin Core:
The concerns Bryan raised about coordination noise and GitHub's
moderation limitations are real. We've seen how open platforms without
clear boundaries invite persistent disruption — not just trolling, but
sustained efforts to derail meaningful technical collaboration.
But rather than framing this as a call for *privatization*, I think
it's more productive to view the problem through the lens of
*decentralization*. Git is already a distributed protocol — we should
be using it that way. We need infrastructure that supports secure,
accountable collaboration without relying on centralized gatekeepers,
corporate platforms, or closed offices.
## Git is Already Distributed — Let's Lean Into That
Git is a distributed version control system by design. In principle,
any developer or group of developers can work together on their own
forks, branches, or remotes — and coordinate externally from GitHub if
necessary. What we often lack is robust and usable *infrastructure*
for decentralized collaboration: systems that offer structure,
provenance, access control, and cryptographic guarantees, without
reverting to centralized or closed development.
## Open Source vs. Open Development
It’s also important to recognize that an open-source license alone is
insufficient for true "Open Development". Sustainable open development
depends not just on permissive licensing, but on values like
transparent governance, verifiable contributions, and non-coercive
collaboration. "Open Development" is a broader process that considers
who can participate, how trust is earned, and what incentives shape
behavior. These questions are especially vital in a high-stakes
project such as Bitcoin Core.
I've written an article on Open Development
https://www.blockchaincommons.com/articles/Open-Development/ that I
invite you to read as a parallel stream to this discussion.
## Transparency Is Not a Given — It’s a Design Decision
One criticism that has surfaced around Open Development is the idea
that Bitcoin Core developers have a "duty of transparency." But this
expectation is rarely defined. Is it a duty to publish *code*, to
explain *decisions*, to make *deliberations* public in real time — or
something else entirely?
If transparency is important to Bitcoin’s social contract, then we
should talk about what it actually entails, how it's balanced against
resilience, and where it begins and ends. Developers already meet
significant transparency obligations: reproducible builds, tagged
releases, and open review processes. That’s not nothing.
But assuming an *unlimited* or *unspecified* duty to perform
transparently — in every venue, at every stage — can easily become a
vector for coercion or burnout. Like every part of this system,
transparency needs intentional architecture, not moral ambiguity.
## A Proof-of-Concept: Open Integrity Project
I help maintain the [Open Integrity
Project](https://github.com/OpenIntegrityProject/core), which explores
how Git repositories can be used as cryptographic roots of trust. Our
work includes:
* "Inception Commits" to establish a verifiable origin.
* A signed `.allowed_commit_signers` policy to verify contributors.
* Future plans for branch distribution via Bittorrent's DHT,
FROST-based threshold signing, decentralized governance, and other
methods.
Open Integrity is *not a proposal for Bitcoin Core Developement*. But
it proves that decentralized coordination around open-source codebases
can be more secure, intentional, and resilient — while remaining
transparent and permissively licensed.
## Radicle and Other Directions
Radicle (https://radicle.xyz) is another working example. It shows
that peer-to-peer Git hosting and identity infrastructure are real and
usable today. It may not fit every contributor, but it makes clear
that **decentralization** — not privatization — is a viable and
thoughtful alternative to GitHub’s constraints.
## Structuring for Sovereignty
Public dev spaces come with power dynamics — and attackers exploit
them. We need tools and norms that protect developer autonomy without
killing transparency. That’s not impossible. But we have to build for
it, not assume it comes for free.
As I said, we shouldn't frame these transitions as “privatizing”
development, but we should instead focus on how to **structure
decentralized collaboration** more effectively — with clear
boundaries, strong tooling, and healthy expectations. Still open, but
designed to resist coercion and chaos.
Let’s explore optional decentralized spaces where trust is earned,
review is rigorous, and participation remains open — but under
conditions that developers can actually work within. No gates, just
better scaffolding.
-- Christopher Allen, Blockchain Commons
P.S. As context for those who don't know me: I've been working on
secure software since the early '90s — contributing to projects like
RSAREF (used by PGP, Digicash, and other early cryptographic tools),
SSLREF which led to TLS 1.0, and more recently the W3C DID 1.0 spec.
I’ve participated in and helped shape multiple open-source and
standards communities over the decades, including during my brief time
at Blockstream and now with Blockchain Commons. My long view informs
my belief that better tooling and clearer boundaries can preserve both
openness and resilience.
Antoine Poinsot
Jun 14, 2025, 4:45:11 PMJun 14
to Bryan Bishop, bitco...@googlegroups.com
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 in private and source code would be made available at the same time as (reproducible) binary releases. I think there are a few major issues with this approach. Among 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 instance the optech newsletter or simply searchable through Github);
- It would increase the cost, in relation to the previous point, of "grassroot" onboarding to the project. 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-contributor-but-not-full-time-project-member, but it seems to me such a project structure would erect significant barriers to this approach and could make it almost necessary to go through one of the development 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 Core repository with a public mirror. The public mirror would have comment threads on pull requests originating from the private repository and the possibility to open issues. It would essentially enable developer to opt into engaging on public comment threads (for bug reports, contentious pull requests if they see fit, etc..) while always having the possibility to retreat in the private repository to focus. This does sound more appealing to me, although it raises question with regard to its feasibility and the churn it could introduce (could the public mirror insert public comments within the synced private thread? or would it have to duplicate every single thread?).
You touch on the office culture and the need for a platform that would be a better sweet spot between unmoderated public discussions and entirely private discussions happening in the confines of a Bitcoin developer organization's offices. However it's unclear that what drives a lot of discussions to happen in offices is the occasional disruption of online fora, rather than just the natural advantages of in-person discussions.
You also state that brigading would be severely reduced and eliminated. However it seems contrary to having publicly available comment threads? It would just contain the brigading to the publicly available comment threads. You could make the point that this containment would disincentivize the brigading in the first place, but it would only be the case if there is no expectation that the low-quality comments be taken into account in the decision making. And removing this expectation does not require such an involved project structure, which brings me to my last point.
I agree with your problem statement. I believe there is a dangerous perception that the Bitcoin Core Github repository somehow controls Bitcoin and is worthy of political pressure. And this is not only the case of the filter enjoyers, this misperception is also used for example to justify legal threats[^0] against developers. It is important to push back against this confusion, but it seems achievable with a lot less disruption than by changing the project structure. We just need to face the fact that Bitcoin Core is a centralized project. It has a central website, releases binaries and updates its software based on rough technical consensus. Bitcoin is decentralized, Bitcoin Core is not. Setting expectations that misinformed rants and conspiracy theories will be considered at all in deciding whether code should be changed is entirely self-inflicted and does not need a change in the project structure to correct. 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 instance) or for worse (here).
In conclusion, i don't think yours is a bad idea. If the Bitcoin 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 tolerating them.
Best,
Antoine Poinsot
Antoine Poinsot
[^0]: It was the case with Craig Wright, but also more recently: https://github.com/bitcoin-core/meta/issues/19#issuecomment-2843664280
Andrew Poelstra
Jun 15, 2025, 12:30:24 PMJun 15
to Bryan Bishop, bitco...@googlegroups.com
I have a few thoughts about this -- bearing in mind that I am a drive-by
contributor to Core, at best, and don't have much personal opinion other
than maybe "I wish it were easier to get stuff in".
1. I think that Antoine is correct that "it's easier and more natural"
is a bigger motivation for "office work" than is the fear of brigade.
So one thing is that any change to public processes shouldn't make it
_harder_ for people to collaborate online, since that could push
people more to in-person fora and we'd just have the worst of both
worlds. Or at least, anyone making such a change should have a lot of
confidence that the increased friendliness to earnest contributors
would outweigh the extra friction.
2. On the other hand, fear of brigades _does_ clearly have a nonzero
chilling effect. I certainly think about it when publicly communicating
near the project, and I commonly bring it up when doing things in
rust-bitcoin (i.e. "fortunately, we're not Core, so we can just do
[some change that would constrain wallet workflows, or which could
make ordinals particularly hard, or particularly easy, or whatever]"
and not have to worry about fallout.)
So at the very least, it's a factor that discourages some external
developers from being bigger contributors to the project.
3. And of course, it's not just obvious brigades -- when one or two
nontechnical people show up with strong political views about
something which really is not a political change (or at least,
doesn't have the political effect they believe it does, because of
their own misunderstanding), it's still discouraging and sometimes
stressful. And this happens all the time around mempool policy,
even if PRs with 100+ comments that get locked are fairly rare.
4. However, after (ironically) discussing this email off-list with a
bunch of people, I think that these problems stem from a fairly small
cultural issue: that the Github repo appears to be a totally open
forum where anyone is welcome to participate, even in code review
threads, because technically anybody _can_ participate with no
obvious sense that they're leaving X and entering somebody's
workplace.
And _this_, IMHO, might be solvable by something extremely simple. It
might be sufficient to just move from Github to Gitlab or Codeberg or
something where far fewer people have accounts. It would probably be
sufficient to just find a platform where you have to register on the
Core repo somehow then wait 24 hours before you can post, with the
implication that if you're not there to contribute technically, you
might lose your access. (This is true on Github but the only
mechanism is that you can be banned from the org, something that
feels heavy and scary for maintainers to use -- I really hate doing
this to non-bots on rust-bitcoin and I don't even have to worry that
they'll go on twitter to scream censorship and that I'm taking over
Bitcoin or whatever -- and is also more-or-less invisible to users
until it happens to them, so it's not an effective deterrent.)
It would certainly be effective to put a strong technical barrier,
e.g. you have to produce a custom mining share to join, or a strong
social barrier, e.g. you need personal invitations from two people.
But I think such tech barriers would be unnecessary and the social
barriers wouldn't be worth the cries of censorship and centralization
that they'd inevitably (and somewhat reasonably) cause.
5. I don't see much of benefit to making the repo *unreadable* to
outsiders. It sorta prevents linking on Twitter but if we expect
there to be mirrors, people can just link to the mirrors.
Again, it's not my project and I don't mean to advocate for anything in
particular. Just trying to organize thinking on the topic a bit.
--
Andrew Poelstra
Director, Blockstream Research
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster
contributor to Core, at best, and don't have much personal opinion other
than maybe "I wish it were easier to get stuff in".
1. I think that Antoine is correct that "it's easier and more natural"
is a bigger motivation for "office work" than is the fear of brigade.
So one thing is that any change to public processes shouldn't make it
_harder_ for people to collaborate online, since that could push
people more to in-person fora and we'd just have the worst of both
worlds. Or at least, anyone making such a change should have a lot of
confidence that the increased friendliness to earnest contributors
would outweigh the extra friction.
2. On the other hand, fear of brigades _does_ clearly have a nonzero
chilling effect. I certainly think about it when publicly communicating
near the project, and I commonly bring it up when doing things in
rust-bitcoin (i.e. "fortunately, we're not Core, so we can just do
[some change that would constrain wallet workflows, or which could
make ordinals particularly hard, or particularly easy, or whatever]"
and not have to worry about fallout.)
So at the very least, it's a factor that discourages some external
developers from being bigger contributors to the project.
3. And of course, it's not just obvious brigades -- when one or two
nontechnical people show up with strong political views about
something which really is not a political change (or at least,
doesn't have the political effect they believe it does, because of
their own misunderstanding), it's still discouraging and sometimes
stressful. And this happens all the time around mempool policy,
even if PRs with 100+ comments that get locked are fairly rare.
4. However, after (ironically) discussing this email off-list with a
bunch of people, I think that these problems stem from a fairly small
cultural issue: that the Github repo appears to be a totally open
forum where anyone is welcome to participate, even in code review
threads, because technically anybody _can_ participate with no
obvious sense that they're leaving X and entering somebody's
workplace.
And _this_, IMHO, might be solvable by something extremely simple. It
might be sufficient to just move from Github to Gitlab or Codeberg or
something where far fewer people have accounts. It would probably be
sufficient to just find a platform where you have to register on the
Core repo somehow then wait 24 hours before you can post, with the
implication that if you're not there to contribute technically, you
might lose your access. (This is true on Github but the only
mechanism is that you can be banned from the org, something that
feels heavy and scary for maintainers to use -- I really hate doing
this to non-bots on rust-bitcoin and I don't even have to worry that
they'll go on twitter to scream censorship and that I'm taking over
Bitcoin or whatever -- and is also more-or-less invisible to users
until it happens to them, so it's not an effective deterrent.)
It would certainly be effective to put a strong technical barrier,
e.g. you have to produce a custom mining share to join, or a strong
social barrier, e.g. you need personal invitations from two people.
But I think such tech barriers would be unnecessary and the social
barriers wouldn't be worth the cries of censorship and centralization
that they'd inevitably (and somewhat reasonably) cause.
5. I don't see much of benefit to making the repo *unreadable* to
outsiders. It sorta prevents linking on Twitter but if we expect
there to be mirrors, people can just link to the mirrors.
Again, it's not my project and I don't mean to advocate for anything in
particular. Just trying to organize thinking on the topic a bit.
--
Andrew Poelstra
Director, Blockstream Research
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster
waxwing/ AdamISZ
Jun 16, 2025, 11:28:16 AMJun 16
to Bitcoin Development Mailing List
My personal opinion is that the best solution is to create a very strong ruleset on disallowing any non-technical contribution on github, and applying that rule rigorously no matter whether the content *feels* acceptable or not, and no matter how well respected the contributor is and might rightfully be given some slack. This would be for PRs; for Issues, I don't know how much of a similar problem you have, but templates aren't bad I guess.
Such extreme discipline is only needed in that repo, virtually no other repo needs it.
I also do realize this could end up a bit of a weak-sauce suggestion compared to others in this thread (I quite like Andrew's suggestion but, not sure it's exactly the right one).
This would have to be accompanied by a very strong cohesion around what *is* the correct forum for technically-adjacent bitcoin policy discussion (as just one example, advocating for or against soft forks goes in this bucket), and also tonally to *encourage* such discussion; that encouragement would have to be broadcast from the github repo itself, certainly in messages to people whose discussion contribution is blocked. Obviously it would have to be noted elsewhere too like the main distribution website for the software.
Unfortunately I don't think this mailing list *quite* fits the job, though it's close ... on the other hand, where else? If this list is manually moderated (as I believe it is), do we have a bitcoin-"policy" mailing list or other channel?
I think the biggest problems arise when you insist that there is *no* place for what you see as "brigading", "sock puppetry" etc. I have seen several times in the past (most notably around the blocksize wars) where many highly respected engineers dismissed all opposing opinions as sock puppetry. This is not realistic, nor is it healthy. If you stuff all contrary opinions (uneducated or not!) into a garbage bin that you label "politics" (imagine the phrase "go and discuss it on bitcoin-politics" with the tacit assumption that no one serious is ever going to read that dumpster fire), it invites the exact conflict you're trying to avoid. I suggest "bitcoin policy" as a general title for such things, because bitcoin does indeed have "policies" in the general sense (not just the technical meaning of "policy" in bitcoin-the-software but also consensus itself is a flavor of policy). If it doesn't end up being a place that serious people talk seriously, then of course it will have failed in the intention.
Cheers,
AdamISZ/waxwing
AdamISZ/waxwing
Bryan Bishop
Jun 16, 2025, 12:56:36 PMJun 16
to waxwing/ AdamISZ, Bitcoin Development Mailing List, Bryan Bishop
Hi,
On Mon, Jun 16, 2025 at 10:28 AM waxwing/ AdamISZ <ekag...@gmail.com> wrote:
My personal opinion is that the best solution is to create a very strong ruleset on disallowing any non-technical contribution on github, and applying that rule rigorously no matter whether the content *feels* acceptable or not, and no matter how well respected the contributor is and might rightfully be given some slack. This would be for PRs; for Issues, I don't know how much of a similar problem you have, but templates aren't bad I guess. Such extreme discipline is only needed in that repo, virtually no other repo needs it.
Interesting idea. Worth trying. I would not be opposed to seeing this tried. However, my intuition is that manual, vigorous disciplined moderation like that is difficult to execute especially across many people, compared to systems that push that discipline into automation mechanisms, such as "must apply to post" or "first-timers have their posts moderated" or other variations.
I think the biggest problems arise when you insist that there is *no* place for what you see as "brigading", "sock puppetry" etc. I have seen several times in the past (most notably around the blocksize wars) where many highly
Nobody can stop such discussion forums from being created anywhere on the Internet. There will always be a place so long as at least one person wants to publicly discuss an idea or concept. I recall there were various "pro block size wars" discussion channels during that time period.
respected engineers dismissed all opposing opinions as sock puppetry. This is not realistic, nor is it healthy. If you stuff all contrary opinions (uneducated or not!) into a garbage bin that you label "politics" (imagine the phrase "go
I have some confusion here: is this a discussion about existing public communication channels and allowing arbitrary content posting? is it about what an individual does and what they choose to engage with or not engage in? Is it a condemnation of the aggregate behavior of the volunteer developers?
1) Existing communication channels: see my previous text on compelled platforming of speech in my original email.
2) Whether individuals choose to engage or label it "politics" or "cool random" or "trash bin" or any other label they choose: This is entirely up to the individual level and cannot be regulated. Nor can they be forced to participate or discuss things they don't want to discuss or aren't interested in. However, sometimes people for example do engage in online arguments, against their better judgment haha.
3) Aggregate group behavior: this one is likely more of an issue of narratives and perceptions around group behavior in aggregate. For example, a perception that "respected engineers dismissed all opposing opinions as sockpuppetry" in the incident you are referencing when there was, to my recollection, extensive prolonged good faith engagement to a radical extent. Have we such a short memory? Of course, when such engagement does not lead to a desired outcome, it's easy to spin a narrative of non-cooperation or non-engagement ("you didn't cause the outcome that we demanded! if you did not come to our conclusion then you did not do any consideration!" -- see how easy it is?).
and discuss it on bitcoin-politics" with the tacit assumption that no one serious is ever going to read that dumpster fire), it invites the exact conflict you're trying to avoid. I suggest "bitcoin policy" as a general title for such things,
I don't see my original goal as "avoid conflict". It was about creating an online space exclusively for bitcoin developers that want to work together on bitcoin development. I posit that even with such an exclusive space, and even if it had higher adoption than the current private development efforts, that there would still be various online fora with various people of all kinds (angry, confused, informed, etc), or even cool-headed non-confused people that developers simply don't have time or interest to individually read-- or maybe they would; who knows! But it's separate from having a place for bitcoin development.
If [a bitcoin-policy fora] doesn't end up being a place that serious people talk seriously, then of course it will have failed in the intention.
That... might be okay? Who's fault is that if "serious people", such as "serious developers", don't wish to participate in those fora? Does fault-finding even matter there? And, if there is non-participation from "serious developers" or other "serious people", the default assumption should not be "therefore we need to clutter up public developer communication channels" - which in some ways seems sort of paternalistic, on the order of "developers can't decide for themselves how to hear from users or what to individually work on"- thankfully nobody has explicitly asserted this, although a few replies I received on X.com seem pretty close to it......
- Bryan
https://x.com/kanzure
https://x.com/kanzure
waxwing/ AdamISZ
Jun 16, 2025, 12:56:41 PMJun 16
to Bitcoin Development Mailing List
Bryan,
If I'm honest, I realize that my commentary here was flawed in at least
two ways:
> However, my intuition is that manual, vigorous disciplined
moderation like that is difficult to execute especially across many
people
1/ as you correctly picked up on here, an "extremely rigorous moderation
policy on PRs" as i was advocating sounds nice, but in what world can
that actually be done? the difficulty of turning that abstract idea into
reality might be related to point 2/ :
re:
> Nobody can stop such discussion forums from being created anywhere
on the Internet.
2/ with regard to a separate forum, mailing list (perhaps like this one)
etc. I again may have glossed over the most difficult real point: what
represents a consequential conclusion to a discussion, even if such a
forum were perfectly set up? The energy around github is IMO mostly from
the natural (partly correct?) interpretation that github is mostly
where the final decision gets made on inclusion of features into
bitcoin-the-software *AND* bitcoin-the-protocol, even if obviously the
latter, if we're talking consensus is a really non-trivial deal and in
no way is it just a matter of counting ACKs on a PR. The unpleasantly
difficult-to-answer question of how (and where) decisions get made is
what's causing this.
> I don't see my original goal as "avoid conflict". It was about
creating an online space exclusively for bitcoin developers that want to
work together on bitcoin development. I posit that even with such an
exclusive space, and even if it had higher adoption than the current
private development efforts, that there would still be various online
fora with various people of all kinds (angry, confused, informed, etc),
or even cool-headed non-confused people that developers simply don't
have time or interest to individually read-- or maybe they would; who
knows! But it's separate from having a place for bitcoin development.
Good point. What I'm trying to get at is that if you just cleanly
separate the two things, with no conscious, or perhaps even existent,
communication from one (the fora) in to the other (the dev process),
then nobody will care about the former (as today probably nobody cares
about opinions on *many* bitcoin fora), which means nobody strongly
motivated, will use them. I think it'll depend on some sense of
decisions not being exclusively made on github or via private
discussion, into the repository. I'm not sure your idea of a private
repo is wrong, I see where you come from, but I fear it will exacerbate a
pre-existing growing perception of "Bitcoin Core" as a distinct entity
with its own policy approach (and even politics, though that is a false
perception). Can I express for the 100th time my severe regret that the
name "Bitcoin Core" for the Satoshi client was adopted? (Side note: does
anyone actually think it was good that it got renamed to "Bitcoin Core"
because I haven't met any such person, lol).
I don't have any easy solutions to "how the decisions get made", of
course, which is the root cause of the problem, and inflammatory
communications are related mainly to that (even worse, I am leery of
people trying to fully solve it!). If making the environment tolerable
and workable for people doing the actual engineering work is possible
without completely solving that, then that is a very valid goal.
But enough windbaggery from me, I should leave the discussion from here
on to people with some actual skin in the game!
Cheers,
AdamISZ/waxwing
Bryan Bishop
Jun 16, 2025, 6:06:58 PMJun 16
to Antoine Poinsot, bitco...@googlegroups.com, Bryan Bishop
Hi,
On Sat, Jun 14, 2025 at 1:29 PM Antoine Poinsot <daro...@protonmail.com> wrote:
I started reading by speculating you were defending the case for something akin to a "source-available" Bitcoin Core. [... ]However you are not making the case for this, but for a private Bitcoin Core repository with a public mirror.
I will not claim I am an eloquent writer. In fact, Adam Back rightly points out that some of my phrasing is deeply dumb: in one paragraph I started off a chain of ORs of alternatives that began with publishing cut releases instead of every incremental commit. I didn't mean to suggest Bitcoin Core should only publish cut releases, only that it was an option that could be supported by social coding tools. It was followed by a chain of "ORs" of alternatives, and overall I could have worded that paragraph better. Oops.
The public mirror would have comment threads on pull requests originating from the private repository and the possibility to open issues. It would essentially enable developer to opt into engaging on public comment threads (for bug reports, contentious pull requests if they see fit, etc..) while always having the possibility to retreat in the private repository to focus. This does sound more appealing to me, although it raises question with regard to its feasibility and the churn it could introduce (could the public mirror insert public comments within the synced private thread? or would it have to duplicate every single thread?).
All kinds of arrangements are possible, including bi-directional synchronization, or one-way synchronization and pingbacks with "review" before posting synced content internally, ... or many other options. It's up to the developers using the tools to decide if they find them useful. It could be beneficial for a variety of different private development tools to exist and be tried by different devs. There likely isn't one workflow that works best for everyone, instead a bunch of differentiated preferences or ways about getting their work done.
You touch on the office culture and the need for a platform that would be a better sweet spot between unmoderated public discussions and entirely private discussions happening in the confines of a Bitcoin developer organization's offices. However it's unclear that what drives a lot of discussions to happen in offices is the occasional disruption of online fora, rather than just the natural advantages of in-person discussions.
I don't know how to reply to this. I thought I had brought up offices as an example of existing private development efforts that already exist and are already more private than an online members-only social coding tool. To the extent that "private development is bad" is a motivation to not do the things I have suggested, then I wanted to point to offices as a trend that already exists and highlight how members-only open source software development is a better option for some of us and somewhat disproves "private development is bad" is a blocking concern that e.g. somehow prohibits private development. It doesn't.
You also state that brigading would be severely reduced and eliminated. However it seems contrary to having publicly available comment threads? It would just contain the brigading to the publicly available comment threads. You could make the point that this containment would disincentivize the brigading in the first place, but it would only be the case if there is no expectation that the low-quality comments be taken into account in the decision making.
Great point. I should have said that brigadier intrusions into developer spaces would be reduced or eliminated, not that all bitcoin-related brigading on the Internet for all time would be eliminated, which is well outside of my powers to enact or promise.
I agree with your problem statement. I believe there is a dangerous perception that the Bitcoin Core Github repository somehow controls Bitcoin and is worthy of political pressure. And this is not only the case of the filter enjoyers, this misperception is also used for example to justify legal threats[^0] against developers. It is important to push back against this confusion,
I have toyed around with the idea of proposing changes to Bitcoin Core's github repository to minimize the perception of prestige. I don't have a great suggestion at the moment so I haven't posted publicly on this. I'm also not sure if lowering perceived prestige is the right thing to do or if that would be beneficial to bitcoin, Bitcoin Core, users of Bitcoin Core, or its developers. For example, what if Bitcoin Core started merging random ads and spam into the README?
We just need to face the fact that Bitcoin Core is a centralized project. It has a central website, releases binaries and updates its software based on rough technical consensus. Bitcoin is decentralized, Bitcoin Core is not.
There are some aspects of Bitcoin Core that are centralized, such as the domain name registration, or the GitHub org, where unambiguously some specific people have control of a project resource. Many other project resources including a great number of volunteers freely allocate their time and resources to help write and review code, propose changes, or otherwise move the project forward with minimal coordination and no central control over those people. Arguably a lot of the value of Bitcoin Core is from those contributors.
To the extent that Bitcoin Core is centralized, then bitcoiners ought to be thoughtful about the ways in which it is centralized (or not) and the design goals should be the result of careful strategy or thinking. Strengthening the decentralized aspects, or increasing decentralized aspects, of the Bitcoin Core project may be prudent, depending on the design goals. Based on other replies in this thread it may be possible to achieve exclusive developer spaces by increasing decentralization for Bitcoin Core with systems like Radicle or other social coding tools. I guess depending on how you squint some might call that increasing the centralization (proliferation of independent but private collaboration spaces) or others might call it decentralization (anyone can fork/mirror write-privately spaces). And this might even help people avoid incorrectly seeing Bitcoin Core's centralized aspects as Bitcoin being centralized.
To the extent that Bitcoin Core is centralized, then bitcoiners ought to be thoughtful about the ways in which it is centralized (or not) and the design goals should be the result of careful strategy or thinking. Strengthening the decentralized aspects, or increasing decentralized aspects, of the Bitcoin Core project may be prudent, depending on the design goals. Based on other replies in this thread it may be possible to achieve exclusive developer spaces by increasing decentralization for Bitcoin Core with systems like Radicle or other social coding tools. I guess depending on how you squint some might call that increasing the centralization (proliferation of independent but private collaboration spaces) or others might call it decentralization (anyone can fork/mirror write-privately spaces). And this might even help people avoid incorrectly seeing Bitcoin Core's centralized aspects as Bitcoin being centralized.
Setting expectations that misinformed rants and conspiracy theories will be considered at all in deciding whether code should be changed is entirely self-inflicted and does not need a change in the project structure to correct.
- Bryan
https://x.com/kanzure
https://x.com/kanzure
TheCharlatan
Jun 17, 2025, 6:36:45 PMJun 17
to Bitcoin Development Mailing List
I kind of hate that my first email to the list is commenting on a meta issue. My impression is that the concerns raised here are overblown.
The question around how to handle data embedding and meta protocols through policy has been a major discussion point on the repository for more than a decade. Even with a clear majority of regular contributors agreeing, a decision on the topic was always going to arouse major controversy. The perceived brigading did not impede the project from making progress on the issue. It led to a rare moment of alignment in the form of a common statement, brought more eyes to reviewing the pull requests, and finally led to a resolution of the question. The discussion was also focused on the two pull requests, and did not impede progress on the 300+ others. Contrary to public perception, I also think moderation of the pull requests in question was ok. I especially like that it was kept open by the moderators for people to comment on, since people are clearly still confused on what the change actually does. More importantly it also shows that our organization is still the same scrappy, loose collective of individuals with individual approaches and opinions capable of tolerating dissent. If I were to choose a client to run my money on, these are all soft qualities I'd look out for.
On the topic of giving people a platform for spreading lies through a public issue tracker and review mechanism, regular posting on social media seems way more effective at this. Soliciting public feedback from users during pull request review is very useful. If somebody tries out the new API I am working on, I'd like their feedback to be visible and easily submitted.
The question around how to handle data embedding and meta protocols through policy has been a major discussion point on the repository for more than a decade. Even with a clear majority of regular contributors agreeing, a decision on the topic was always going to arouse major controversy. The perceived brigading did not impede the project from making progress on the issue. It led to a rare moment of alignment in the form of a common statement, brought more eyes to reviewing the pull requests, and finally led to a resolution of the question. The discussion was also focused on the two pull requests, and did not impede progress on the 300+ others. Contrary to public perception, I also think moderation of the pull requests in question was ok. I especially like that it was kept open by the moderators for people to comment on, since people are clearly still confused on what the change actually does. More importantly it also shows that our organization is still the same scrappy, loose collective of individuals with individual approaches and opinions capable of tolerating dissent. If I were to choose a client to run my money on, these are all soft qualities I'd look out for.
On the topic of giving people a platform for spreading lies through a public issue tracker and review mechanism, regular posting on social media seems way more effective at this. Soliciting public feedback from users during pull request review is very useful. If somebody tries out the new API I am working on, I'd like their feedback to be visible and easily submitted.
Antoine Riard
Jun 17, 2025, 6:36:46 PMJun 17
to Bitcoin Development Mailing List
Hi Kanzure and others,
Thanks for your thoughts on this subject.
(...I initially swear to myself to not comment on this thread,
though after seeing Poinsot mentioning my GH comment, I think
I have to answer, a bit at least. So doing it with a real effort
of goodwill and courtesy).
> voluntary non-coercive arrangement (kanzure)
That's where there is a glitch, because somehow it all depends
how you define coercion, i.e the axiom of non-coercion (rothbard)
or the monopoly of the means of production (marx) ? Among many
political traditions...A short look on the history of the last
one hundred and fifty years says that "coercion" is far from
being a non-equivocal concept.
Moreover, I think it's very single sided when you're saying that
the crowd of bitcoin core users and other adjacent stakeholders.
shouldn't estimate itself entitled on the backs of developers.
Let's remember that a subset of those same developers were I
think really relieved to call to public charity when the CSW
lawsuits did happen. The bdlf did accept external donations
for a while, and you have also people like Paul Storcz who said
to have contributed to the legal defense of the devs. I don't
think he was the only one.
Though it's also forgetting the numerous low-key contributors
who might have contributed to bitcoin core quid a small review,
a testing of the release binaries, help for the lang translations,
improving rpc documentations, etc. Those low-key contributors
without names who were celebrated in the past by one of the
bitcoin optech newsletter [0]
[0] https://bitcoinops.org/en/newsletters/2021/12/22/
And I'm not going to mention that some grant-giving
organizations have been accepting bitcoin donations to
fund their own devs program [1]. How can they be sure that
the people who are vocablly asking for some code change
are not the same who are anonymously donating ? It's not
an easy problem...
[1] https://btcpay0.voltageapp.io/i/Cpb3V6SQsd131ib6U5GHrU/BTC-CHAIN
We're all suffering from the bias that our contribution, be it code,
catching sec flaw, providing financial ressources or operational support,
giving time as a forum / ml moderator or onboarding newbies at your
local meetup is the most significative one...
> There is a secondary issue that in a world of consensus compatible
> forks Core really shouldn't make maintaining those consensus compatible
> forks unnecessarily difficult or impossible (michaelfolkson).
Libbitcoinkernel is out there and it's usable. It might be a high
technical bar, though it slashes the engineering cost of developing
a consensus-compatible full-node by order of magnitude clearly.
I would give it's a rough cost of $2-5M in engineering time to develop
a full-node from libbitcoinkernel. This might sounds huge, though if
you're familiar with the development cost of specialized OSes in the
areonautics or banking field, it's similar. The Blockstream of the
day can be critized in medias, though they're clearly burning money
in the dev process.
At some point, I do understand a lot of the bitcoin core contributors
who are exceeded by the bridaging on social networks (...though no
one force you to be on twitter and you can still have a career in
the space I'm just saying...) or eventually systematic shitposting
on their pull requests.
> If transparency is important to Bitcoin’s social contract, then we
> should talk about what it actually entails, how it's balanced against
> resilience, and where it begins and ends. Developers already meet
> significant transparency obligations: reproducible builds, tagged
> releases, and open review processes. That’s not nothing. (ChristopherA)
I'm generally agreeing with a lot of the ideas presented by ChristopherA,
and I've advocated over the last weeks that it could be very valuable
to move bitcoin core on nostr (or experiment with radicle). This would be
along the lines of what has been proposed in the past by a former maintainer [2]
[2] https://laanwj.github.io/2021/01/21/decentralize.html
> I agree with your problem statement. I believe there is a dangerous perception
> that the Bitcoin Core Github repository somehow controls Bitcoin and is worthy
> of political pressure. And this is not only the case of the filter enjoyers,
> this misperception is also used for example to justify legal threats[^0] against developers
(poinsot)
Okay that one I have to clarify. I did my first commit in core in 2018 and
more in 2019, i.e before that any of the current maintainers have been nominated
(the people with a key in contrib/verify-commits/trusted-keys). While moderation
was always a thing for spam and in the pathological case like for Gavin kick-out,
it was never said that a subset of contributors can arbitrarly change the moderation
rules at invitation-only meetings (in the `CONTRIBUTING.md` of the time). And when
I ACKed some maintainers for this janitorial role it was never to grant them the
permission to moderate my posts _arbitrarly_.
I'm still thinking that the way moderation was established last year was in disrespect
of the hundreds of contributors that have poured their works in the git tree along
the years and who are still active (even if it's monthly or twice a year, some episodic
contributions can be always of high-quality), but not present at the meeting for a reason
or other.
In my view, the constrain of logistics in the impossibility of inviting hundrefs
of people to a physical location at the same time is not a good reason to banalize
unilateral change to the development process. Especially, when the emphasis of said
dev process culture is put on "decentealization" and at every CoreDev it is reminded
that "we're not a decision-making body".
This situation is all so clear that when I opened a pull request saying that bitcoin
core code might be an unintentional and accidental joint authorship among all the
code contributors, no one has been able to tell me clearly either why it would be
or why it would be not, and the pull request for that is still opened...
So in the present state of things I'm confirming in public that I'm not going
to pursue Alex and Suhas for that disagreement on moderations. No legal actions
has been opened. And somehow this thread is the opportunity to point out more verbosly
all the disagreement we have on moderation and "privatizing" or "decentralizing"
bitcoin core or not.
That was to clarify by giving my version.
All of that said, I'll start to review again Poinsot's BIP54 proposal, sometimes
a bit of goodwill in open-source it can have a lot of positive effects, rather
than pointing an accusating finger towards each other.
Clearly the kind of situations when you have to show heightness of soul and
a bit of foresight...and "eviter de rajouter de l'huile sur le feu".
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
To conclude, I don't have a strong opinion on the privatization of bitcoin core
or not in view of solving "social abuse". You're going to make things better on
one dimensions to downgrade on others. There is no free lunch.
By personal philosophy, I'm always a bit skeptical of that kind of "top-down"
approach, especial when it's asked to dozens of contributors spread in many parts of the
worlds and with different professional culturue to all suddenly move in the same
direction.
Said even less of the crowd of node operators, that might estimate
themselves "betrayed" by a diminution in the transparency of the dev process.
Generally, successful open-source projects are organic, bottom-up process.
If you're a bitcoin contributor and you wish (unilaterally) to diminish the
"social attacks", you're free to quit twitter to favor more long-text mode
of communications. There are some historical contributors that have never been
on twitter (e.g andytoshi, nullc or myself), and it has never been a drawback
to make a career in the industry.
Long-text mode of communications generally calls to the reasoning abilities of an audience.
With patience and a zest of stoicism,
Antoine
OTS hash: 6ba4a996fb99f397d2207317bbca8614d27895fbe9a2cb1e4fd74ccc2b8c7b09
Thanks for your thoughts on this subject.
(...I initially swear to myself to not comment on this thread,
though after seeing Poinsot mentioning my GH comment, I think
I have to answer, a bit at least. So doing it with a real effort
of goodwill and courtesy).
> voluntary non-coercive arrangement (kanzure)
That's where there is a glitch, because somehow it all depends
how you define coercion, i.e the axiom of non-coercion (rothbard)
or the monopoly of the means of production (marx) ? Among many
political traditions...A short look on the history of the last
one hundred and fifty years says that "coercion" is far from
being a non-equivocal concept.
Moreover, I think it's very single sided when you're saying that
the crowd of bitcoin core users and other adjacent stakeholders.
shouldn't estimate itself entitled on the backs of developers.
Let's remember that a subset of those same developers were I
think really relieved to call to public charity when the CSW
lawsuits did happen. The bdlf did accept external donations
for a while, and you have also people like Paul Storcz who said
to have contributed to the legal defense of the devs. I don't
think he was the only one.
Though it's also forgetting the numerous low-key contributors
who might have contributed to bitcoin core quid a small review,
a testing of the release binaries, help for the lang translations,
improving rpc documentations, etc. Those low-key contributors
without names who were celebrated in the past by one of the
bitcoin optech newsletter [0]
[0] https://bitcoinops.org/en/newsletters/2021/12/22/
And I'm not going to mention that some grant-giving
organizations have been accepting bitcoin donations to
fund their own devs program [1]. How can they be sure that
the people who are vocablly asking for some code change
are not the same who are anonymously donating ? It's not
an easy problem...
[1] https://btcpay0.voltageapp.io/i/Cpb3V6SQsd131ib6U5GHrU/BTC-CHAIN
We're all suffering from the bias that our contribution, be it code,
catching sec flaw, providing financial ressources or operational support,
giving time as a forum / ml moderator or onboarding newbies at your
local meetup is the most significative one...
> There is a secondary issue that in a world of consensus compatible
> forks Core really shouldn't make maintaining those consensus compatible
Libbitcoinkernel is out there and it's usable. It might be a high
technical bar, though it slashes the engineering cost of developing
a consensus-compatible full-node by order of magnitude clearly.
I would give it's a rough cost of $2-5M in engineering time to develop
a full-node from libbitcoinkernel. This might sounds huge, though if
you're familiar with the development cost of specialized OSes in the
areonautics or banking field, it's similar. The Blockstream of the
day can be critized in medias, though they're clearly burning money
in the dev process.
At some point, I do understand a lot of the bitcoin core contributors
who are exceeded by the bridaging on social networks (...though no
one force you to be on twitter and you can still have a career in
the space I'm just saying...) or eventually systematic shitposting
on their pull requests.
> If transparency is important to Bitcoin’s social contract, then we
> should talk about what it actually entails, how it's balanced against
> resilience, and where it begins and ends. Developers already meet
> significant transparency obligations: reproducible builds, tagged
I'm generally agreeing with a lot of the ideas presented by ChristopherA,
and I've advocated over the last weeks that it could be very valuable
to move bitcoin core on nostr (or experiment with radicle). This would be
along the lines of what has been proposed in the past by a former maintainer [2]
[2] https://laanwj.github.io/2021/01/21/decentralize.html
> I agree with your problem statement. I believe there is a dangerous perception
> that the Bitcoin Core Github repository somehow controls Bitcoin and is worthy
> of political pressure. And this is not only the case of the filter enjoyers,
> this misperception is also used for example to justify legal threats[^0] against developers
Okay that one I have to clarify. I did my first commit in core in 2018 and
more in 2019, i.e before that any of the current maintainers have been nominated
(the people with a key in contrib/verify-commits/trusted-keys). While moderation
was always a thing for spam and in the pathological case like for Gavin kick-out,
it was never said that a subset of contributors can arbitrarly change the moderation
rules at invitation-only meetings (in the `CONTRIBUTING.md` of the time). And when
I ACKed some maintainers for this janitorial role it was never to grant them the
permission to moderate my posts _arbitrarly_.
I'm still thinking that the way moderation was established last year was in disrespect
of the hundreds of contributors that have poured their works in the git tree along
the years and who are still active (even if it's monthly or twice a year, some episodic
contributions can be always of high-quality), but not present at the meeting for a reason
or other.
In my view, the constrain of logistics in the impossibility of inviting hundrefs
of people to a physical location at the same time is not a good reason to banalize
unilateral change to the development process. Especially, when the emphasis of said
dev process culture is put on "decentealization" and at every CoreDev it is reminded
that "we're not a decision-making body".
This situation is all so clear that when I opened a pull request saying that bitcoin
core code might be an unintentional and accidental joint authorship among all the
code contributors, no one has been able to tell me clearly either why it would be
or why it would be not, and the pull request for that is still opened...
So in the present state of things I'm confirming in public that I'm not going
to pursue Alex and Suhas for that disagreement on moderations. No legal actions
has been opened. And somehow this thread is the opportunity to point out more verbosly
all the disagreement we have on moderation and "privatizing" or "decentralizing"
bitcoin core or not.
That was to clarify by giving my version.
All of that said, I'll start to review again Poinsot's BIP54 proposal, sometimes
a bit of goodwill in open-source it can have a lot of positive effects, rather
than pointing an accusating finger towards each other.
Clearly the kind of situations when you have to show heightness of soul and
a bit of foresight...and "eviter de rajouter de l'huile sur le feu".
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
To conclude, I don't have a strong opinion on the privatization of bitcoin core
or not in view of solving "social abuse". You're going to make things better on
one dimensions to downgrade on others. There is no free lunch.
By personal philosophy, I'm always a bit skeptical of that kind of "top-down"
approach, especial when it's asked to dozens of contributors spread in many parts of the
worlds and with different professional culturue to all suddenly move in the same
direction.
Said even less of the crowd of node operators, that might estimate
themselves "betrayed" by a diminution in the transparency of the dev process.
Generally, successful open-source projects are organic, bottom-up process.
If you're a bitcoin contributor and you wish (unilaterally) to diminish the
"social attacks", you're free to quit twitter to favor more long-text mode
of communications. There are some historical contributors that have never been
on twitter (e.g andytoshi, nullc or myself), and it has never been a drawback
to make a career in the industry.
Long-text mode of communications generally calls to the reasoning abilities of an audience.
With patience and a zest of stoicism,
Antoine
OTS hash: 6ba4a996fb99f397d2207317bbca8614d27895fbe9a2cb1e4fd74ccc2b8c7b09
Reply all
Reply to author
Forward
0 new messages