rich1.0npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8https://nostr.ae/npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8njumphttps://nostr.ae📅 Original date posted:2015-02-14 📝 Original message:On Sat, Feb 14, 2015 at 3:23 PM, Tamas Blummer <tamas at bitsofproof.com> wrote: > Peter, > We have seen that the consensus critical code practically extends to Berkley > DB limits or OpenSSL laxness, therefore > it is inconceivable that a consensus library is not the same as Bitcoin > Core, less its P2P service rules, wallet and RPC server. Right now libconsensus' only dependency is openSSL. Most of the testing in libsecp256k1 has been in signing rather than verifying signatures (please, anyone with more knowledge in the library don't hesitate to correct me or clarify things). But eventually openSSL will be completely replaced by libsecp256k1. It does not store anything, 0.1 is just a dynamic library with a c API to a single function: VerifyScript(). This function saves the hassle of reimplementing signature checking (which is a really hard part) and reimplementing an interpreter that must function in exactly the same way in many as many other nodes with different software and/or hardware. Guido van Rossum can say "some behaviours in python the language are not specified, so it is ok if cpython and pypy do different things, they're still both running python which is more abstract than any of its implementation". But a consensus system like bitcoin doesn't have the luxury of leaving consensus rules unspecified. And the simplest way to fully specify a language interpreter is by implementing it. But coupling the consensus rules specification with a bigger project like bitcoin core can result in implementation details of that bigger project accidentally and unexpectedly becoming consensus rules. This is what happened with bdb and nobody wants that to happen again, that's the whole point. Note that many parts of the bitcoin protocol (like the p2p messages) are NOT part of the consensus rules. You can have a look at https://github.com/jtimon/bitcoin/commits/consensus2 and maybe you would be surprised about how small they actually are. This branch is incomplete and still a mess that needs to be cleaned up. And none of that is included in libconsensus yet. I was planning on writing a post here asking for feedback on the interfaces for these higher level checks. I'm just putting the code together in the same module, but obviously class CCoinsViewCache cannot be an argument in functions of a c API. > The Core code base is unfriendly to feature extensions because of its > criticality, legacy design and ancient technology. It is also a commodity > that the ecosystem takes for granted and free. > > I honestly admire the core team that works and progresses within these > limits and perception. > > I am not willing to work within the core’s legacy technology limits. Does it > mean I am dicking around? I think not. > It was my way to go down the rabbit hole by re-digging it and I created > successful commercial products on the way. Nobody is attacking alternative implementations. This tool was created mostly with alternative implementations in mind. So input from them it's very welcomed on how to continue libconsensus (or of course correct any flaws in verifyScript if there's any). I just wanted to wait to have some more code to make things easier to explain (and have a clearer idea of it myself). There's a more limited branch on "next steps for libconsensus" in #5669. > It is entirely rational for me to focus on innovation that uses the core as > a border router for this block chain. Sure, I think he is complaining that at the moment that's probably the only safe way to operate with alternative implementations and still have full node guarantees. > I am rather thankful for the ideas of the side chains, that enable > innovation that is no longer measured on unapologetic compatibility with a > given code base, but its services to end user. Sidechains are completely orthogonal to this discussion and, in fact, it would be good to have libconsensuses for sidechains too, since their nodes also need to come to consensus.