Libconsensus separated repository (was Bitcoin Core and hard forks)



Summary:

The conversation discusses the importance of functional equivalence when it comes to re-implementing or refactoring code, and how this can be achieved through code review and unit testing. It is suggested that simpler consensus code written in a style that allows for provability of correctness will make future comparisons between implementations easier. Before swapping out implementations, it is recommended to run them through testing and potentially run both side-by-side. The API should treat all I/O abstractly. One individual prefers using a bare-bones signal template for async message handling in C++, while others may have different stylistic preferences.The conversation then shifts to the goal of extracting consensus rules from Bitcoin Core to avoid the need for re-implementation, but different individuals have different goals. Compatibility with Bitcoin is important, but there is also a desire to create and serve other block chains with different rules. Bits of Proof uses various languages and tools depending on what works best for each piece. There is also discussion about integrating secp256k1 as part of consensus and the use of libconsensus for VerifyScript. The suggestion is made to expand libconsensus to offer VerifyTx, VerifyHeader and VerifyBlock, while still allowing for control over storage, concurrency, networking, and policy.


Updated on: 2023-06-10T03:41:24.085003+00:00