{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-12-15\n📝 Original message:BtcDrak was working on rebasing my CHECKLOCKTIMEVERIFY¹ patch to master a few\ndays ago and found a fairly large design change that makes merging it currently\nimpossible. Pull-req #4890², specifically commit c7829ea7, changed the\nEvalScript() function to take an abstract SignatureChecker object, removing the\ntxTo and nIn arguments that used to contain the transaction the script was in\nand the txin # respectively. CHECKLOCKTIMEVERIFY needs txTo to obtain the\nnLockTime field of the transaction, and it needs nIn to obtain the nSequence of\nthe txin.\n\nWe need to fix this if CHECKLOCKTIMEVERIFY is to be merged.\n\nSecondly, that this change was made, and the manner in which is was made, is I\nthink indicative of a development process that has been taking significant\nrisks with regard to refactoring the consensus critical codebase. I know I\npersonally have had a hard time keeping up with the very large volume of code\nbeing moved and changed for the v0.10 release, and I know BtcDrak - who is\nkeeping Viacoin up to date with v0.10 - has also had a hard time giving the\nchanges reasonable review. The #4890 pull-req in question had no ACKs at all,\nand only two untested utACKS, which I find worrying for something that made\nsignificant consensus critical code changes.\n\nWhile it would be nice to have a library encapsulating the consensus code, this\nshouldn't come at the cost of safety, especially when the actual users of that\nlibrary or their needs is still uncertain. This is after all a multi-billion\nproject where a simple fork will cost miners alone tens of thousands of dollars\nan hour; easily much more if it results in users being defrauded. That's also\nnot taking into account the significant negative PR impact and loss of trust. I\npersonally would recommend *not* upgrading to v0.10 due to these issues.\n\nA much safer approach would be to keep the code changes required for a\nconsensus library to only simple movements of code for this release, accept\nthat the interface to that library won't be ideal, and wait until we have\nfeedback from multiple opensource projects with publicly evaluatable code on\nwhere to go next with the API.\n\n1) https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki\n2) https://github.com/bitcoin/bitcoin/pull/4890\n\n-- \n'peter'[:-1]@petertodd.org\n00000000000000001b18a596ecadd07c0e49620fb71b16f9e41131df9fc52fa6\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 650 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141215/c0b5116e/attachment.sig\u003e"}