Libconsensus separated repository (was Bitcoin Core and hard forks)



Summary:

In a Bitcoin development thread, Tamas Blummer responds to Matt Corallo's suggestion of creating a libconsensus API with plugable block storage and networking. Blummer suggests that the design should have NO networking and instead focus on isolation of bitcoin specific decisions and algorithms from generic blockchain code. He also notes that supporting altcoins is not important since nobody cares about it. When Corallo suggests that building such an API would require a complete rewrite, Blummer disagrees, stating that the refactoring required to build such an API would be easier than a complete rewrite. Furthermore, he suggests that having a correct consensus implementation that everyone could use would be a huge deal. Blummer thinks that a slim API server would be a lower hanging fruit in Core’s case, and mentions that there are a number of good development tools for C++ that allow this. In response, Corallo notes that libconsensus would not have any kind of networking layer, nor is C++ an antique tool set. Ideally, it would have a simple API to give it blocks and a simple API for it to inform you of what the current chain is. He suggests that if someone really wants to get fancy, maybe it has pluggable block storage too. When Jorge Timon writes that the goal is not reimplementing the consensus rules but rather extract them from Bitcoin Core so that nobody needs to re-implement them again, Blummer notes that his goal is different. While compatibility with Bitcoin is important, he wants to be able to create and serve other blockchains with other rules as well. He is eager to integrate secp256k1 (c) as soon as part of consensus. The choices were made because each piece appears best in what they do.


Updated on: 2023-05-19T21:35:15.468979+00:00