Since the beginning of the development of Segregated Witness, an increasing number of alternative Bitcoin hard fork supporters have criticized the implementation process of soft forks on Bitcoin Core, claiming that Core developers have a complete monopoly over the process.

Former Bitcoin Core developer Jeff Garzik and Ethereum co-founder Vitalik Buterin particularly stated that proposed soft forks have to undergo a majority consensus among Bitcoin Core developers that ultimately decide whether a soft fork becomes implemented into the BItcoin network.

“Soft forks very specifically, from an average user point of view, cannot be considered opt-in because the entire network is locked into the new consensus rule, regardless or not,” said Garzik in a Bitcoin Status Report on the OnChain Scaling Conference on August 30.

Buterin further emphasized that soft forks involve various political issues as they limit and restrict the possibility of building and launching innovative projects and networks like ZCash.

Essentially, Garzik and Buterin believe that soft fork implementations fail to reflect the view of the open source community of Bitcoin, since soft forks are verified, accepted, and implemented by the Bitcoin Core developers, instead of miners and node operators in the industry.

However, Bitcoin Core developer and Ciphrex CEO Eric Lombrozo opposes the claims of Garzik and Buterin, stating that Core developers verify Bitcoin Improvement Proposal (BIP) ideas prior to their write-up only to confirm their technical aspects and applicability to Bitcoin Core software. In an interview with Bitcoin Magazine, Lombrozo elaborated on the reasons why he thinks that decentralization is strong, and how the role of miners and node operators is key.

Lombrozo explained that at the very first stage, a BIP idea is submitted to the mailing list, where the author, developers and Bitcoin technical community members briefly discuss the soft fork and assign it a BIP number. Once added to the repository, anyone can view, comment, and evaluate the proposal. The entire process takes place publicly giving the opportunity for different people to weigh in.

In the Bitcoin network, all node operators and miners have the authority to run whichever software or BIPs they wish to run. They can even refuse to run Bitcoin Core and choose to implement alternative Bitcoin software. When a soft fork is deployed on the network, every miner and node operator can choose to update 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 node. Thus, neither the Core Developers nor the author of the BIP are forcing anyone to implement the newly drafted proposal.

“The BIP editor’s responsibility is to make sure the BIP repository is properly maintained and that all the BIPs that get merged into it follow procedure and have the proper format. The BIP editor does not decide whether the soft fork will activate nor even if the code for it will get merged into Bitcoin Core,” said Lombrozo.

Once a soft fork proposal is drafted and submitted to the repository, the code authoring and review process begin. Bitcoin Core developers and community members either choose to ACK (approve) or NACK (disapprove) the code of the BIP. Upon the confirmation of the BIP’s code, the code merging and release process begin for further tests and evaluation.

“The BIP author is responsible for also submitting code to implement the BIP. This code is then reviewed on Github in a public process open to the entire community. If Bitcoin Core maintainers feel the code has been sufficiently well-reviewed, tested and ACKed, and there are no outstanding NACKs with good reasoning, the code is merged and now there’s the release process. It gets further tested, then once everyone feels the code is ready for release, it gets put into a release branch, which will eventually become the next version of Bitcoin Core,” explained Lombrozo.

At this stage, the soft fork is still far from being activated. For the soft fork to be activated in Bitcoin Core, it requires at least 95 percent of hashpower from miners to active it.

This 95 percent threshold means that, in contrast to Garzik and Buterin’s comments, neither Bitcoin Core developers nor the author of the BIP can coax the majority of the network to accept the proposal. If miners perceive the BIP to be genuine and applicable to Bitcoin Core software, the activation process begins. The Bitcoin Core software gives miners the explicit choice of whether to signal support.

However, Lombrozo emphatically notes that the 95 percent activation process does not work for hard forks.

“Hard forks, unlike soft forks, are not guaranteed to converge to a single chain. Even with a hashpower supermajority, multiple blockchains with different incompatible histories can result,” said Lombrozo.

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

Thus, Bitcoin Core developers don’t benefit from a monopoly over the Bitcoin network in the soft fork implementation process. The verification process in the drafting stage of the BIP is merely designed for developers to confirm its technical aspects. Even if a soft fork passes the Core developer verification stage, without the support from the community, it will not be integrated into Bitcoin Core.

If over 5 percent of miners refuse to run the soft fork, then the network doesn’t activate the proposal and nothing changes. If the soft fork is not activated before a deadline, it becomes permanently deactivated. If 95 percent of the network hashpower approves the soft fork within that deadline, the remaining miners and node operators have sufficient time to upgrade before the soft fork comes into effect.

From the submission phase to the implementation stage, says Lombrozo, Bitcoin community members or anyone in the Bitcoin open source community can collaborate with Core developers in integrating a soft fork into the Bitcoin network. This process ensures that neither miners nor developers have the ability to unilaterally impose a soft fork.

The post Understanding Soft Forks: A Core Developer’s View on Network Monopoly appeared first on Bitcoin Magazine.