This updates the txscript module dependencies, the copyright year in the
files modified since the previous release, and serves as a base for
txscript/v4.1.0.
The updated direct dependencies in this commit are as follows:
- github.com/dchest/siphash@v1.2.3
- github.com/decred/base58@v1.0.5
- github.com/decred/dcrd/chaincfg/chainhash@v1.0.4
- github.com/decred/dcrd/chaincfg@3.2.0
- github.com/decred/dcrd/crypto/blake256@v1.0.1
- github.com/decred/dcrd/crypto/ripemd160@v1.0.2
- github.com/decred/dcrd/dcrec@v1.0.1
- github.com/decred/dcrd/dcrec/edwards/v2@v2.0.3
- github.com/decred/dcrd/dcrec/secp256k1/v4@v4.2.0
- github.com/decred/dcrd/wire@v1.6.0
The updated indirect dependencies in this commit are as follows:
- github.com/agl/ed25519@v0.0.0-20170116200512-5312a6153412
- github.com/klauspost/cpuid/v2@v2.0.9
- lukechampine.com/blake3@v1.2.1
The full list of updated dependencies since the previous txscript/v4.0.0
release are the same as above.
Finally, all modules in the repository are tidied to ensure they are
updated to use the latest versions hoisted forward as a result.
This modifies the encoding logic for script numbers to support encoding
min int64s. This was previously not supported since the type was not
public and it is not possible to achieve a min int64 within the context
of the script system itself due to the strict limits it imposes.
However, now that script numbers are exported for external use and
callers are not bound by the aforementioned strictness, it should be
possible to encode the entire range for completeness.
In practice, callers should never realistically need to encode the value
since the purpose of the type is to create encoded numbers for scripts
and the value in question will be rejected upon any attempt to use it as
a number when verifying scripts given it is out of range.
This exports the MathOpCodeMaxScriptNumLen constant which defines the
maximum number of bytes data being interpreted as an integer may be for
the majority of op codes.
Among other cases, it can be useful when doing complex script analysis
to ensure consensus semantics are observed in addition to the extra
semantics needed by the analysis.
This exports the ScriptNum type and associated MakeScriptNum constructor
in order to expose the ability to better analyze more complex scripts
while respecting the special handling needed to deal with the subtle
semantics required by consensus.
This updates the txscript package to provide support for the errors.Is
and errors.As functions introduced in Go 1.13 per the recently
documented best practices.
The following is an overview of the changes:
- Rename the ErrorCode type to ErrorKind and make it a string
- Implement the error interface on ErrorKind
- Update all error code definitions to the new type
- Remove error code string map that is no longer required
- Remove unused ErrInternal definition
- Change the error code field of the Error type to Err
- Implement Unwrap on the Error type to support unwrapping via
errors.Is/As
- Remove the IsErrorCode function since it is no longer needed due to
errors.Is
- Update IsDERSigError to cope with the changes
- Modify various comments to refer to error kinds instead of codes
- Update all test code to use the new ErrorKind directly along with
errors.Is for detecting the expect errors
- Add full test coverage to ensure the new error definitions work as
intended
- Update the doc.go errors section accordingly
This removes the flag to require minimal encoding when create script
numbers since since all callers now call the function with true due to
the recent removal of the minimal data script verification flag from the
script engine and updates the tests accordingly.
This converts the majority of script errors from generic errors created
via errors.New and fmt.Errorf to use a concrete type that implements the
error interface with an error code and description.
This allows callers to programmatically detect the type of error via
type assertions and an error code while still allowing the errors to
provide more context.
For example, instead of just having an error the reads "disabled opcode"
as would happen prior to these changes when a disabled opcode is
encountered, the error will now read "attempt to execute disabled opcode
OP_FOO".
While it was previously possible to programmatically detect many errors
due to them being exported, they provided no additional context and
there were also various instances that were just returning errors
created on the spot which callers could not reliably detect without
resorting to looking at the actual error message, which is nearly always
bad practice.
Also, while here, export the MaxStackSize and MaxScriptSize constants
since they can be useful for consumers of the package and perform some
minor cleanup of some of the tests.
While current existing numeric opcodes are limited to 4 bytes, new
opcodes may need different limits.
This mimics Bitcoin Core commit 99088d60d8a7747c6d1a7fd5d8cd388be1b3e138
This commit implements a new type, named scriptNum, for handling all
numeric values used in scripts and converts the code over to make use of
it. This is being done for a few of reasons.
First, the consensus rules for handling numeric values in the scripts
require special handling with subtle semantics. By encapsulating those
details into a type specifically dedicated to that purpose, it
simplifies the code and generally helps prevent improper usage.
Second, the new type is quite a bit more efficient than big.Ints which
are designed to be arbitrarily large and thus involve a lot of heap
allocations and additional multi-precision bookkeeping. Because this
new type is based on an int64, it allows the numbers to be stack
allocated thereby eliminating a lot of GC and also eliminates the extra
multi-precision arithmetic bookkeeping.
The use of an int64 is possible because the consensus rules dictate that
when data is interpreted as a number, it is limited to an int32 even
though results outside of this range are allowed so long as they are not
interpreted as integers again themselves. Thus, the maximum possible
result comes from multiplying a max int32 by itself which safely fits
into an int64 and can then still appropriately provide the serialization
of the larger number as required by consensus.
Finally, it more closely resembles the implementation used by Bitcoin
Core and thus makes is easier to compare the behavior between the two
implementations.
This commit also includes a full suite of tests with 100% coverage of
the semantics of the new type.
