Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2014-12-15 📝 Original message:BtcDrak was working on ...
📅 Original date posted:2014-12-15
📝 Original message:BtcDrak was working on rebasing my CHECKLOCKTIMEVERIFY¹ patch to master a few
days ago and found a fairly large design change that makes merging it currently
impossible. Pull-req #4890², specifically commit c7829ea7, changed the
EvalScript() function to take an abstract SignatureChecker object, removing the
txTo and nIn arguments that used to contain the transaction the script was in
and the txin # respectively. CHECKLOCKTIMEVERIFY needs txTo to obtain the
nLockTime field of the transaction, and it needs nIn to obtain the nSequence of
the txin.
We need to fix this if CHECKLOCKTIMEVERIFY is to be merged.
Secondly, that this change was made, and the manner in which is was made, is I
think indicative of a development process that has been taking significant
risks with regard to refactoring the consensus critical codebase. I know I
personally have had a hard time keeping up with the very large volume of code
being moved and changed for the v0.10 release, and I know BtcDrak - who is
keeping Viacoin up to date with v0.10 - has also had a hard time giving the
changes reasonable review. The #4890 pull-req in question had no ACKs at all,
and only two untested utACKS, which I find worrying for something that made
significant consensus critical code changes.
While it would be nice to have a library encapsulating the consensus code, this
shouldn't come at the cost of safety, especially when the actual users of that
library or their needs is still uncertain. This is after all a multi-billion
project where a simple fork will cost miners alone tens of thousands of dollars
an hour; easily much more if it results in users being defrauded. That's also
not taking into account the significant negative PR impact and loss of trust. I
personally would recommend *not* upgrading to v0.10 due to these issues.
A much safer approach would be to keep the code changes required for a
consensus library to only simple movements of code for this release, accept
that the interface to that library won't be ideal, and wait until we have
feedback from multiple opensource projects with publicly evaluatable code on
where to go next with the API.
1) https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
2) https://github.com/bitcoin/bitcoin/pull/4890
--
'peter'[:-1]@petertodd.org
00000000000000001b18a596ecadd07c0e49620fb71b16f9e41131df9fc52fa6
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141215/c0b5116e/attachment.sig>;
📝 Original message:BtcDrak was working on rebasing my CHECKLOCKTIMEVERIFY¹ patch to master a few
days ago and found a fairly large design change that makes merging it currently
impossible. Pull-req #4890², specifically commit c7829ea7, changed the
EvalScript() function to take an abstract SignatureChecker object, removing the
txTo and nIn arguments that used to contain the transaction the script was in
and the txin # respectively. CHECKLOCKTIMEVERIFY needs txTo to obtain the
nLockTime field of the transaction, and it needs nIn to obtain the nSequence of
the txin.
We need to fix this if CHECKLOCKTIMEVERIFY is to be merged.
Secondly, that this change was made, and the manner in which is was made, is I
think indicative of a development process that has been taking significant
risks with regard to refactoring the consensus critical codebase. I know I
personally have had a hard time keeping up with the very large volume of code
being moved and changed for the v0.10 release, and I know BtcDrak - who is
keeping Viacoin up to date with v0.10 - has also had a hard time giving the
changes reasonable review. The #4890 pull-req in question had no ACKs at all,
and only two untested utACKS, which I find worrying for something that made
significant consensus critical code changes.
While it would be nice to have a library encapsulating the consensus code, this
shouldn't come at the cost of safety, especially when the actual users of that
library or their needs is still uncertain. This is after all a multi-billion
project where a simple fork will cost miners alone tens of thousands of dollars
an hour; easily much more if it results in users being defrauded. That's also
not taking into account the significant negative PR impact and loss of trust. I
personally would recommend *not* upgrading to v0.10 due to these issues.
A much safer approach would be to keep the code changes required for a
consensus library to only simple movements of code for this release, accept
that the interface to that library won't be ideal, and wait until we have
feedback from multiple opensource projects with publicly evaluatable code on
where to go next with the API.
1) https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
2) https://github.com/bitcoin/bitcoin/pull/4890
--
'peter'[:-1]@petertodd.org
00000000000000001b18a596ecadd07c0e49620fb71b16f9e41131df9fc52fa6
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141215/c0b5116e/attachment.sig>;