The case for privatizing Bitcoin Core

The ongoing discourse surrounding the privatization of Bitcoin Core has elicited varied reactions from members of the bitcoin development community. One significant point of contention is the differentiation between consensus rule changes and other types of modifications such as transaction relay policy, wallet features, GUI updates, and testing improvements. It's emphasized that while forks of Bitcoin Core that are compatible with the consensus can introduce diverse mempool policies, wallet functionalities, and user interfaces without risking a chain split—assuming no consensus bugs are introduced—this freedom doesn't extend to consensus rule changes. Instances like Knots and Libre Relay adopting different mempool policies without fragmenting the network underscore this distinction.

The debate further highlights the recent practices by Bitcoin Core in how it handles transaction relay policy changes, particularly praising the clarity and communication surrounding the merge decision of a specific transaction relay policy pull request (32404). This practice, however, is pointed out as not being directly transferrable to how consensus rule changes should be managed. The insistence on Core contributors prioritizing review of certain proposals within six months was critiqued for potentially overlooking the broader implications such changes could have on network unity. The unilateral approach to transaction policy decisions by Core is accepted due to the lack of risk in splitting the chain or network, but a similar stance on consensus rule changes is deemed problematic due to the potential for creating divergent currencies and fracturing the community.

Another concern raised touches upon the maintenance of consensus-compatible forks. If actions by Core render these forks difficult or impossible to maintain, especially when users may disagree with specific transaction relay policies, it restricts user options and compromises the ecosystem's diversity. This scenario draws a parallel with the management of the Linux kernel, suggesting that Bitcoin Core should not only monitor but actively engage with consensus-compatible forks to ensure a balanced and inclusive development environment.