Published on: 2014-11-15T04:43:43+00:00
Jean-Pierre Rupp from Haskoin advocates for a hard fork to fix consensus bugs in the Bitcoin protocol. He believes that bugs should not be tolerated and that the protocol should be clearly documented. Rupp suggests thoroughly documenting and repairing consensus bugs on a separate branch, which would eventually lead to a scheduled hard fork. This approach would eliminate known bugs and establish a process for addressing future bugs. The hard fork would primarily impact mining pools, while most bitcoin transactions would remain unaffected. Rupp argues that convincing mining pools to upgrade their software well in advance should not be difficult.Justus Ranvier also emphasizes the importance of fixing bugs in Bitcoin due to its extra consensus requirements. Clément Elbaz suggested separating the Bitcoin consensus code into a project similar to the Linux Kernel. This idea has already been put into motion with the creation of a stand-alone script verification library, which will eventually become part of a larger project called the Bitcoin Kernel. The Bitcoin Kernel would contain only the minimum code necessary for consensus and leave the implementation of other aspects to applications built with it.In an email conversation, Tamas Blummer asked Peter Todd about the possibility of forking the consensus code. Todd responded that the consensus code is essentially frozen, and any changes made are due to mistakes rather than intentional modifications. However, he mentioned two soft-fork proposals, BIP62 and CHECKLOCKTIMEVERIFY, which are being considered. Todd highlights the challenges of making changes in an environment where multiple implementations use the same consensus-critical code.Peter Todd explains that hard-forking upgrades are not regularly done in protocols, even when there are no consensus problems. He argues that scheduling and planning necessary upgrades to fix bugs in the Bitcoin protocol is preferable to waiting for a crisis. Todd questions who benefits from not fixing bugs and provides a link to a video on email encryption for online privacy.Justus Ranvier criticizes the way Bitcoin Core handles bugs and argues for scheduling upgrades to fix bugs in the protocol. He suggests forking Bitcoin Core to avoid centralized control and ensure multiple forks maintain strong consensus. Peter Todd disagrees with regular hard-fork upgrades and emphasizes the rarity of flag days in engineering.In a discussion on Bitcoin development, various developers express their opinions on soft forks and hard forks. Jeff Garzik suggests adding CHECKLOCKTIMEVERIFY and discusses the risks and benefits of both types of forks. Matt Corallo explains the necessity of BIP62 for basic contracts and atomic swaps but also highlights its limitations. The discussion emphasizes the difficulty of writing bug-for-bug compatible code and the importance of consensus-compatible implementations derived from Bitcoin Core.In light of the bugs present in Bitcoin's consensus code, some propose freezing the code and conducting a thorough study to address these issues. Blockstream has been actively discussing this approach as an alternative to soft-fork-ready versioning, which they find unsatisfactory. It is crucial to note that bug-for-bug compatibility in Bitcoin's consensus code is critical and needs to be addressed. The exploitation of bugs like the SIGHASH_SINGLE bug and the CHECKSIG* opcode evaluation bug can result in forks and block rejections. Ensuring the consistency of the encoding of CScript() is also important to maintain the integrity of the network.
Updated on: 2023-08-01T10:38:25.868985+00:00