Published on: 2015-08-29T23:30:39+00:00
Bitcoin developer Tamas Blummer has proposed a new infrastructure for enterprise applications, emphasizing the importance of building consensus on the ledger. He believes that enterprises have the resources to solve business problems and that mainstream adoption requires their involvement. To facilitate this, Blummer suggests a slim protocol server with no wallet, RPC, or QT, but with a high-performance remoting API.The discussion also highlights the need for modularization in Bitcoin's code. Modularization allows more people to contribute and review code, reduces risks associated with changes, and enables alternative code bases without fear of consensus bugs. Contributors like Jorge Timón, Wladimir, Pieter, Cory, Jonas Schnelli, and Eric Lombrozo advocate for modularization to resolve political challenges and improve software engineering.There is a focus on separating the BIP process into distinct areas, including consensus rule change proposals, update/deployment mechanisms, hard fork proposals, soft fork proposals, peer policies, RPC, and more. The idea is to specify core protocol layers and interfaces, allowing independent improvements and convergence on a common history and state.Tamas Blummer and Jorge Timón discuss the risks and benefits of re-implementation, refactoring, and copy-pasting in Bitcoin development. Blummer argues that quality is achieved at a high cost and is difficult to maintain over generations of developers. Timón emphasizes the need for code that is not only high quality but also easy to maintain with a development team experiencing high attrition.The conversation delves into the potential implementation of a libconsensus API, which would provide a correctly implemented consensus layer accessible to all Bitcoin developers. Blummer suggests expanding libconsensus to include functions like VerifyTx, VerifyHeader, and VerifyBlock. The plan is for the C API to interface with external storage by passing a function pointer to it.Tamas Blummer discusses his goal of creating an implementation that can extract consensus rules from Bitcoin Core so that they do not need to be re-implemented. He suggests using modern tool sets and a slim API server. Matt Corallo suggests that a libconsensus should ideally have a simple API for blocks and the current chain, with the possibility of pluggable block storage. Tamas Blummer expresses his eagerness to integrate secp256k1 (c) as part of consensus. Jorge Timon highlights the importance of extracting consensus rules from Bitcoin Core to avoid the need for future re-implementations. He proposes steps to implement libconsensus in Bitcoin Core, but acknowledges the risk of consensus fork bugs during the process. Eric Voskuil disagrees with forking Bitcoin Core and suggests separating libconsensus into a separate repository. In a conversation between Wladimir J. van der Laan and Jorge Timón, they discuss the possibility of Bitcoin Core using libconsensus. Wladimir notes the risk of introducing fork bugs if the code is refactored, but expresses support for the change if this can be avoided. They also discuss the need for code review capacity and the possibility of using libsecp256k1 instead of OpenSSL.The discussion focuses on separating current-libconsensus from future-libconsensus in the Bitcoin Core code. The plan is to complete future-libconsensus that implements all consensus rules and expose more functions through its API. There are concerns about code incompatibility and the need for code review capacity. The author maintains a fork of consensus sources until they are properly isolated from the satoshi client. They express willingness to work on the project but note that fear of consensus bugs keeps people on the satoshi client.Eric Voskuil discusses the removal of the OpenSSL dependency in their stack and the activation of BIP66. The need for a separate repository for libconsensus is mentioned to ensure alternative implementations can be consensus-safe.In conclusion, there is a strong discussion about the creation and implementation of libconsensus to extract consensus rules from Bitcoin Core. The goal is to avoid re-implementations and allow for the creation of other blockchains with different rules. There are discussions about the API, pluggable block storage, and the integration of secp256k1 (c). Concerns about code compatibility, code review capacity, and OpenSSL dependency are also addressed.The goal of the Bitcoin Core codebase is to be modularized, allowing for easy swapping out of consensus rules and reducing the risk of consensus fork bugs. Mike Hearn, a Bitcoin developer, expressed his desire for Bitcoin Core to have a benevolent dictator, similar to other free software projects. This is because decentralization still requires someone to make decisions for changes to occur.In an email exchange in 2015, Jorge Timón apologized for mentioning Mike Hearn and diverting attention from the topic at hand.
Updated on: 2023-08-01T14:31:40.955368+00:00