Bitcoin Core has a monopoly on soft forks? A Core developer's rebuttal

Since the development of SegWit, a growing number of Bitcoin hard fork supporters have criticized Bitcoin Core’s soft fork implementation process, claiming that Core developers have a complete monopoly over the process.

Jeff Garzik, a former Bitcoin Core developer, and Vitalik Buterin, a co-founder of Ethereum, specifically pointed out that the proposed soft fork must be based on the consensus of the vast majority of Bitcoin Core developers before a decision can be made on whether to implement a soft fork on the Bitcoin network.

Garzik said in his State of Bitcoin report at the On-Chain Scaling Conference on August 30:

“From the perspective of a general user, soft forks are very special and are not even considered because the entire network is locked into a new consensus rule.”

Buterin stressed that soft forks involve various political issues because they limit and restrict the possibility of creating and launching innovative projects, such as the ZCash project.

Essentially, Garzik and Buterin argue that soft fork implementations fail to reflect the true views of the Bitcoin open source community because soft forks are validated, accepted, and implemented by Bitcoin Core developers, not miners and node operators.

However, Bitcoin Core developer and Ciphrex CEO Eric Lombrozo opposed Garzik and Buterin's statements, saying that Core developers will verify Bitcoin Improvement Protocol (BIP) ideas before writing them to confirm their technical aspects and applicability to Bitcoin Core software. In an interview with BitcoinMagazine, Lombrozo explained why he believes that Bitcoin's decentralization is very strong and that miners and node operators are key.

Lombrozo explained that in the first phase, a BIP idea is submitted to the mailing list, where the idea's creator, developers and Bitcoin technical community members can simply discuss the soft fork and assign a BIP number. Once the idea is added to the repository, everyone can view, comment and evaluate the proposal. The whole process is open and everyone has the opportunity to participate.

In the Bitcoin network, all node operators and miners have the right to run any software or BIP they want. They can even refuse to run Bitcoin Core and choose to implement alternative Bitcoin software. When the network deploys a soft fork, every miner and node operator can choose to upgrade their nodes to support the proposed BIP. If they disagree with the technical concept of the proposal, they can simply choose not to run the updated code. Therefore, neither the Core developers nor the creators of the BIP can force anyone to implement a newly drafted proposal.

Lombrozo said:

“It is the responsibility of the BIP creator to ensure that the BIP repository is properly maintained and that all BIPs follow the procedure and are properly formatted. The BIP creator does not decide whether a soft fork will be activated and whether it will be merged into Bitcoin Core.”

Once a soft fork proposal is drafted and submitted to the repository, the code writing and review process begins. Bitcoin Core developers and community members can choose to ACK (approve) or NACK (disapprove) the BIP code. Once the BIP code is confirmed, the code merge and release process will begin, followed by further testing and evaluation.

“The creator of the BIP is also responsible for submitting code to implement the BIP. The code is then reviewed on Github in a form open to the entire community. If the Bitcoin Core maintainers feel that the code has been well reviewed and tested, then they will ACK, and there can be no obvious and justified NACKs, after which the code will be merged and enter the release process. After further testing, when everyone feels that the code is ready to be released, the code will enter the release stage and eventually become the next version of Bitcoin Core.”

At this stage, the soft fork is still far from being activated, because for the soft fork to be activated in Bitcoin Core, it will need to obtain at least 95% of the miners' computing power to activate.

This 95% threshold means that, contrary to Garzik and Buterin's views, neither Bitcoin Core developers nor the creators of the BIP can coax the majority of the network to support the proposal. If miners feel that the BIP is good and suitable for Bitcoin Core software, the activation process will begin. Bitcoin Core software gives miners a clear choice whether to support this BIP.

However, Lombrozo stressed that this 95% activation procedure would not apply to hard forks.

“Unlike soft forks, hard forks are not guaranteed to converge to a single chain. Even with a supermajority of hash power, it is possible to have multiple blockchains with incompatible histories.”

It is also important to note that everyone in the community can participate in the BIP verification and approval process, and can even participate in the review of technical code.

Therefore, Bitcoin Core developers will not benefit from monopolizing the Bitcoin network soft fork implementation process. The verification process during the BIP drafting phase is only designed for developers to confirm its technical aspects. Even if the soft fork passes the Core developer verification phase, without support from the community, the soft fork cannot be integrated into Bitcoin Core.

If more than 5% of miners refuse to run the soft fork, the network will not activate the proposal and nothing will change. If the soft fork cannot be activated by the deadline, it will be permanently deactivated. If 95% of the network hashrate approves the soft fork by the specified date, the remaining miners and node operators will have enough time to upgrade before the soft fork takes effect.

Lombrozo said that from the submission stage to the implementation stage, members of the Bitcoin community or anyone in the Bitcoin open source community can work with Core developers to integrate soft forks into the Bitcoin network. This process ensures that neither miners nor developers can unilaterally force the implementation of soft forks.