The discussion considers possible contradictions regarding community participation. There were no conclusions after the proposal and further discussions are expected in the future.
Bitcoin developer, Matt Corallo, submitted on the Bitcoin-Dev mailing list a proposal with his considerations to improve the conditions for the execution of soft forks in the Bitcoin blockchain.
The Bitcoin Optech newsletter issued on January 15th reviews Corallo’s proposal, which is based on five elements that he considers as desirable in this type of upgrades. Unlike hard forks, a soft fork introduces updates to the software without making it incompatible with previous versions. The idea is to make aesthetic changes, and add features not affecting the network’s structure, among other aspects.
However, among these new attributes is the ability to abort the process if a “serious objection to the proposed changes is found in the consensus rules,” the definition of “enough time” for most nodes to be updated after the launch or “the expectation that the network’s hash rate will be approximately the same before and after the change, as well as during any transition.”
The proposal also includes preventing as much as possible the creation of invalid blocks under the new rules. According to the newsletter, this could lead to false confirmations in non-updated nodes and SPV (simple payment verification) clients, a Bitcoin implementation that relies on information from a trusted node for the validity of transactions.
Another desirable feature, according to the developer, is to ensure that it is not possible to “misuse abortion mechanisms to retain a widely desired update without known problems.”
Activation Process
Regarding the inclusion of the features that he proposes, Corallo expressed some doubts. He considers that if the update is implemented under the BIP9 mechanism, with good community participation, the first four attributes can be ensured. But it would not guarantee the fifth, related to “following the will of the community, regardless of people or objections, but never canceling any reasonable objection.”
The counterpart would be to use the BIP8 mechanism, with which the latter criterion could be met but there could be conflicts with the rest. Another concern regarding this mechanism is that its use “gives the impression that node software developers can decide system rules,” as the newsletter highlights.
In response to Corallo, Luke Dash Jr. and Jorge Timón propose the implementation of the fork through a mechanism that provides the mandatory implementation date. However, this would contradict some of the five attributes mentioned, according to Corallo.
The debate around the issue did not lead to a definitive conclusion, so it will continue. Therefore, the newspaper indicates that “a continuous discussion” on the subject is expected.
Continuous Development in Bitcoin
Bitcoin developers keep proposing advances and new features to optimize the network’s operation and capacity. Among the proposals recently highlighted, there is the implementation of Tapscript, Schnorr, and Taproot signatures, whose intention is to improve privacy and scalability in Bitcoin.
The proposals for new technologies for Bitcoin point to the constant development of the network. Lucas Nuzzi, director of Technology Research at Digital Asset Research assured last December that Bitcoin is a constantly evolving technology and innovation.
By Willmen Blanco
