OP_CODESEPARATOR is an actual executed instruction, not a declarative thing, so if it's wrapped in an OP_IF it can be turned off. Looks like we weren't testing this before.
Using this to implement Rivest's Paywords is left as an exercise for the reader. (seriously, this is the first time I've found something useful to do with OP_CODESEPARATOR right now)
OP_CODESEPARATOR is an actual executed instruction, not a declarative
thing, so if it's wrapped in an OP_IF it can be turned off.
Using this to implement Rivest's Paywords is left as an exercise for the
reader.
tACK
scriptPubKey: IF CODESEPARATOR ENDIF 0x21 0x0378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71 CHECKSIGVERIFY CODESEPARATOR 1
Valid
scriptSig: 304502207a6974a77c591fa13dff60cabbb85a0de9e025c09c65a4b2285e47ce8e22f761022100f0efaac9ff8ac36b10721e0aae1fb975c90500b50c56e8a0cc52b0403f0425dd01 0
data: IF ENDIF 0x21 0x0378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71 CHECKSIGVERIFY 1
scriptSig: 3045022100fa4a74ba9fd59c59f46c3960cf90cbe0d2b743c471d24a3d5d6db6002af5eebb02204d70ec490fd0f7055a7c45f86514336e3a7f03503dacecabb247fc23f15c835101 1
data: ENDIF 0x21 0x0378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71 CHECKSIGVERIFY 1
Invalid
scriptSig: 304502207a6974a77c591fa13dff60cabbb85a0de9e025c09c65a4b2285e47ce8e22f761022100f0efaac9ff8ac36b10721e0aae1fb975c90500b50c56e8a0cc52b0403f0425dd01 1
data: ENDIF 0x21 0x0378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71 CHECKSIGVERIFY 1
scriptSig: 3045022100fa4a74ba9fd59c59f46c3960cf90cbe0d2b743c471d24a3d5d6db6002af5eebb02204d70ec490fd0f7055a7c45f86514336e3a7f03503dacecabb247fc23f15c835101 0
data: IF ENDIF 0x21 0x0378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71 CHECKSIGVERIFY 1
Will read up on PayWords.
untested ACK; this should be safe in any case.
I would prefer it if TestBuilder could be used, so it's easier to add variations later without needing to manually build the signatures. TestBuilder right now has no way to correctly deal with OP_CODESEPARATORs, so I'll see if I can add that after this PR.
Semi NACK re: testbuilder - I think there's a lot of value in a skilled human going through this stuff manually. Testbuilder + a skilled human can be useful, but there has to be a core set of tests built manually.
For example, I have another codebase I'm working on where the unittests test some fairly complex cryptographic hashing code by manually building up trees of hashes from scratch.
@petertodd I think that whatever tests can be built automatically, should be built automatically. They're just more readable and reusable. Currently this is a type of test which we can't build automatically, so ACK on adding it manually.
Note that the TestBuilder tests are included in the JSON code (and verified that they are), so they are available to other codebases, and modifications which would unintentionally modify both the actual implementation and the testing code in a way that is consistent with each other will still be caught.
@sipa Yeah, I don't fully agree there for consensus critical stuff. "More readable" can easily mean you've missed what the test actually does because you're at too high a level of abstraction. For instance for that hashing code mentioned above you really did need that assurance that what you thought was being hashed actually was.
Having additional automatically built tests on top of that case be useful to get more coverage, but you gotta start with the basics.
@petertodd No objection to having both automated and manual tests for tricky cases.