Skip to content

Adding the json script tests from ABC#53

Open
Danconnolly wants to merge 108 commits into
bitcoinj-cash:cash-0.14from
teranode-group:jsonscripttests
Open

Adding the json script tests from ABC#53
Danconnolly wants to merge 108 commits into
bitcoinj-cash:cash-0.14from
teranode-group:jsonscripttests

Conversation

@Danconnolly
Copy link
Copy Markdown
Collaborator

This pull request incorporates the standard script unit tests from the script_tests.json file. These unit tests are used by the major node implementations. Care has been taken to avoid modifying the script_tests.json file (with the exception of attribution), so that it can be re-imported in the future as new tests are added.

The tests have shown several deficiencies in the BitcoinJ Script implementation. I have corrected enough to get the basic tests working but many are still not working. Tests which cover features that have not been implemented in bitcoinj-cash yet are ignored. See the TODO notes in ScriptDataDrivenTest.java.

These broken tests need to be addressed at some point. I have run out of time to devote on this right now and am posting it here as a "work in progress".

@coveralls
Copy link
Copy Markdown

coveralls commented May 16, 2018

Coverage Status

Coverage increased (+0.02%) to 76.956% when pulling ca6b9a6 on nchain-research:jsonscripttests into 5765668 on bitcoinj-cash:cash-0.14.

@Danconnolly
Copy link
Copy Markdown
Collaborator Author

rebased off cash-0.14 branch

The new NUM2BIN tests in script_tests.json were expecting an IMPOSSIBLE_ENCODING error message.
Added new exception EncodingMessage and adjusted NUM2BIN interpreter to produce this exception.
Exceptions were previously being generated but were the wrong type.
@Danconnolly Danconnolly deleted the jsonscripttests branch June 13, 2018 20:02
@Danconnolly Danconnolly restored the jsonscripttests branch June 13, 2018 20:07
@Danconnolly Danconnolly reopened this Jun 13, 2018
ilozanof and others added 11 commits June 18, 2018 11:39
… are now using the "ScriptError" where all the possible causes for the Script failure can be stored and organized. This way, the Script failure always throws an ScriptException (easier to managed). This is how it's been implementrd in bitcoinJ (reference).
…e there is an specific error that needs to be captured and processed separately.
These scenarios have been fixed (Expected results from script_tests.json): SIG_DER, ILLEGAL_FORKID, SIG_HASHTYPE, SIG_PUSHONLY, CLEANSTACK, PUBKEYTYPE.
ilozanof and others added 14 commits July 16, 2018 15:32
…bitcoinj-cash into jsonscripttests

# Conflicts:
#	core/src/main/java/org/bitcoinj/script/ScriptError.java
#	core/src/test/java/org/bitcoinj/script/ScriptHelpers.java
…is changed and new data is generated (and compatible with the new Verifications implemented in the Script Engine).
…legacy tests.

Until all the legacy tests are refactored, we change slightly the ALL_VERIFY_FLAGS Collection to remove those Flags that are not compatible(SIGHASH_FORKID and PUBKEYTYPE).
After looking into the code, I think the workaround (removing some Flags from ALL_VERIFY_FLAGS) is not a workaround, but a valid and needed change, in order to keep the existing functionality.

Still, I consider that a deep research into the code is needed, in order to refactor all the uses of these Flags. Since these Flags affect the way the script is executed, the different invocations to the script engine should be aware of what flags are being used 8as a parameter, for example). At this moment, these Flags are hardcoded, and that shouldn,t be the case. If we want to harcode the Verification Flags used when validating the script, then we shoul
Still, I consider that a deep research into the code is needed, in order to refactor all the uses of these Flags. Since these Flags affect the way the script is executed, the different invocations to the script engine should be aware of what flags are being used 8as a parameter, for example). At this moment, these Flags are hardcoded in some places, and that shouldn't be the case (unles there is a clear consensus about that).

The current commit runs OK and the legacy tests also run OK. But we should make it clear that ALL_VERIFY_FLAGS doen NOT measn ALL of them, just the ones that allow a "safe" script execution.
…ode).

After looking into the code, I think the workaround (removing some Flags from ALL_VERIFY_FLAGS) is not a workaround, but a valid and needed change, in order to keep the existing functionality.

Still, I consider that a deep research into the code is needed, in order to refactor all the uses of these Flags. Since these Flags affect the way the script is executed, the different invocations to the script engine should be aware of what flags are being used (as a parameter, for example). At this moment, these Flags are hardcoded, and that should not be the case (unless there is a clear consensus about that).

The current commit runs OK and the legacy tests also run OK. But we should make it clear that ALL_VERIFY_FLAGS doen NOT measn ALL of them, just the ones that allow a "safe" script execution.
November 15, 2018 Hard fork. Code from SV branch used as a reference.
November 15, 2018 Hard fork. Code from SV branch used as a reference.
the test classes have also been refactored, to make them more flexible
for future OpCodes test coverage.
A new class "StackItem" has been added to add more flexibility for
testing, and the test classes have been refactorized.
It makes it easier to perform tests on OP_CODEs. It includes more "casting" mehods, to allow to use it with different data types or fortmats /binary, hex, numbers, etc).
Includes LSHIFT and RSHIFT functionality and tests, and some refactoring has ¡been made in the testing classes, to make them more modular and flexible.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants