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