Libconsensus separated repository (was Bitcoin Core and hard forks)



Summary:

In an email exchange between Tamas Blummer and Jorge Timón, the former expressed his view that every re-implementation, refactoring, and even copy-paste introduces a risk of disagreement and failure in software engineering. Timón responded by referring to a presentation by sipa on why "the implementation is the specification" and the reasons to separate libconsensus. Blummer clarified that he wants something better, not because what others produce was not high quality, but because quality is achieved at a very high cost and is hard to uphold over generations of developers. He claimed that building consensus on the ledger is a cornerstone for an infrastructure for enterprise applications, but it is only a piece of the solution. Blummer suggested that enterprises have sufficient resources to solve business problems even at magnitudes higher cost than a hobbyist would bear. For mainstream adoption, getting enterprises on board is necessary, so code needs to be high quality and easy to maintain with a development team with high attrition. He stated that Bits of Proof's own implementation of scripts was not practically relevant in his commercially successful deployments due to the use of a border router, but it helped development, enabling easier debugging and precise error feedback especially after Core had a reject message. Blummer also mentioned that he has freicoin, sidechains, and private chains in mind, and some of the consensus changes he has in mind are support for multiple assets or interest-bearing assets. He said that if there is a need to change the consensus rules, changing the code is inevitable. It will be much simpler to adapt libconsensus to other chains than it is to adapt the entire Bitcoin Core codebase. Blummer added that he integrated libconsensus only for the hope that it significantly fastens application-side transaction verification, which it turned out it does not yet do until secp256k1 is integrated. He stated that he would likely use another extended libconsensus too, but he does not think there was a dependency on that for enterprise development. Blummer suggested that instead of libconsensus offering VerifyScript, it would be better if it also offered VerifyTx, VerifyHeader, and VerifyBlock. In response to Blummer's suggestion, Timón said that his plan is for the C API to interface with external storage by passing a function pointer to it. However, Blummer expressed his preference to not use function pointers again.


Updated on: 2023-06-10T03:39:55.401833+00:00