NOP1 through NOP10 are reserved for future soft-fork upgrades. When
such an upgrade occurs, the NOP argument will then require verification.
Rejecting transactions that contain these NOPs into the mempool will
discourage those transactions from being mined elsewhere and ensure
btcd will never mine such transactions. This prevents now
invalid scripts (according to the majority of hashing power) even if the
client has not yet upgraded.
Non-executed upgradable NOPs are still allowed as they will still be
valid post-upgrade.
Mimics Bitcoin Core commit 03914234b3c9c35d66b51d580fe727a0707394ca
BIP0062 defines specific rules and canonical encodings for data pushes.
The existing script builder code already conformed to all but one of the
canonical data push rules that was added after it was originally
implemented (adding a single byte of 0x81 must be converted to
OP_1NEGATE). This commit implements that case and expands the existing
tests to explicitly cover all cases mentioned in BIP0062.
In addition, as a part of this change, the AddData function has been
modified so that any attempt to push more than the maximum script element
size bytes (520) in one push or any pushes the would cause the script to
exceed the maximum script bytes allowed by the script engine (10000) will
result in the final call to the Script function to only return the script
up to the point of the first error along with the error. This change
should have little effect on existing callers since they are almost
positively not creating scripts which violate these rules as they could
never be executed, however it does mean they need to check the new error
return.
Since the regression tests intentionally need to be able to exceed that
limit, a new function named AddFullData has been added which does not
enforce the limits, but still provides canonical encoding of the pushed
data.
Note that this commit does not affect consensus rules nor modify the
script engine.
Also, the tests have been marked so they can run in parallel.
This commit adds an example test file so it integrates nicely with Go's
example tooling.
This allows the example output to be tested as a part of running the
normal Go tests to help ensure it doesn't get out of date with the code.
It is also nice to have the example in one place rather than repeating it
in doc.go and README.md.
Links and information about the example have been included in README.md in
place of the example.
PushedData returns an array of byte slices containing any pushed data
found in the passed script. This includes OP_0, but not OP_1 - OP_16.
help from and ok @owainga
This commit addes a couple of tests to ensure performing math operations
on a 5-byte integer, even if the result is a 4-byte integer, is considered
invalid.
Both the script tests (positive and negative) and tx texts (ditto) are
present. Some of the tx tests in the negative section have been
replaced by a comment line explaining why that test is elided, to add in
diffing. The reasons were always that they test things handled by other
parts of the btcd stack (normally chain). For example MAX_MONEY, number
of outputs, coinbase sizes etc.
Much of the inital test logic from @dajohi using hand transcribed tables
for selected tests. The json parsers, script format parser and a lot of
cleaning up/bugfixing from your truly. @davecgh had some input too.
