This updates the following modules to use the secp256k1/v2 module:
- blockchain
- chaincfg/v2
- dcrutil/v2
- hdkeychain/v2
- mempool/v3
- txscript/v2
- main
The hdkeychain/v3 and txscript/v2 modules both use types from secp256k1
in their public API.
Consequently, in order avoid forcing them to bump their major versions,
secp256k1/v1.0.3 was released with the types redefined in terms of the
secp256k1/v2 module so callers still using v1 of the module that are not
ready to upgrade to the v2 module yet can interoperate by updating to
the latest patch version.
This updates the main module to use the latest available minor and patch
versions of all modules and reverts the recent change that incorrectly
removed all of the blake256 references from the various go.sum files.
The following required direct dependencies are bumped as follows:
- github.com/decred/dcrd/blockchain/stake@v1.2.1
- github.com/decred/dcrd/blockchain/stake/v2@v2.0.1
- github.com/decred/dcrd/certgen@v1.1.0
- github.com/decred/dcrd/chaincfg@v1.5.2
- github.com/decred/dcrd/chaincfg/chainhash@v1.0.2
- github.com/decred/dcrd/chaincfg/v2@v2.2.0
- github.com/decred/dcrd/dcrutil/v2@v2.0.0
- github.com/decred/dcrd/gcs@v1.1.0
- github.com/decred/dcrd/hdkeychain/v2@v2.0.1
- github.com/decred/dcrd/txscript/v2@v2.0.0
- github.com/decred/dcrwallet/rpc/jsonrpc/types@v1.2.0
This updates the code to make use of the new crypto/blake256 module instead of
github.com/dchest/blake256.
* change the references in the chaincfg/chainhash and gcs modules
* update chaincfg/chainhash to use the new Sum256 API
* remove references to dchest/blake256 from all go.sum files
This udpates the txscript module to use v2 of the dcrutil module and v2
of the chaincfg module since dcrutil/v2 requires it.
While here, it also modifies the signing functions to accept the new
dcrutil.AddressParams instead of a pointer to a chaincfg.Params struct
in order to remove the tight coupling between txscript and chaincfg at
the API boundary.
It also updates the tests accordingly.
This modifies the signature cache to accept concrete secp256k1
signatures and pubkeys to break its dependency on the chainec package
which is planned to be removed in the future.
There are no other types that are currently using the signature cache
and, if additional types are desired, they should be handled uniquely,
either through the use of a separate cache or through specialized and
efficient conversion code.
Not all signature algorithms are based on EC crypto, particularly
post-quantum algorithms, so it doesn't make sense to try to shoehorn all
signature algorithms into an EC interface.
This removes the DefaultScriptVersion constant and updates the code and
tests to use version 0 scripts accordingly.
It is being removed because it is highly error prone since anything that
is working with scripts needs to understand the version it is dealing
with and having a constant that could change that version out from under
them could easily lead to buggy behavior.
This breaks the dependency on chaincfg.SigHashOptimization which is no
longer available in v2 of the chaincfg module. The constant is set to
false to ensure the same semantics are kept and an additional comment
has been added regarding the status.
This updates the txscript dependencies and serves as a base for
txscript/v1.1.0.
The updated direct dependencies in this commit are as follows:
- github.com/decred/dcrd/dcrec/secp256k1@v1.0.2
- github.com/decred/dcrd/dcrutil@v1.3.0
- golang.org/x/crypto@v0.0.0-20190611184440-5c40567a22f8
The full list of updated direct dependencies since the previous
txscripti/v1.0.2 release are as follows:
- github.com/decred/dcrd/chaincfg@v1.5.1
- github.com/decred/dcrd/dcrec@v1.0.0
- github.com/decred/dcrd/dcrec/edwards@v1.0.0
- github.com/decred/dcrd/dcrec/secp256k1@v1.0.2
- github.com/decred/dcrd/dcrutil@v1.3.0
- golang.org/x/crypto@v0.0.0-20190611184440-5c40567a22f8
This refactors the consensus code which extracts the null data from the
coinbase from txscript.ExtractCoinbaseNullData so that it is performed
directly in the validation code where it more properly belongs.
The only reason the extraction was previously done in txscript is
because it was not possible to parse scripts outside of it, but that is
no longer the case now that txscript offers an exported tokenizer for
that purpose.
The extraction code is ever so slightly more efficient now that it no
longer needs to be as generic since it now has direct knowledge of the
conditions that need to be handled.
Great care was taken to ensure the semantics are not changed while
refactoring the code and no additional tests are added in this commit
because all of the conditions and code paths are covered by the tests
recently added to the full block tests.
While here, also perform some related code cleanup in the function and
improve the error messages .
Since the txscript.ExtractCoinbaseNullData is no longer necessary, this
deprecates the function and releated error code and constant so they can
be removed in the next major version of txscript.
Finally, since this relies on the script tokenizer which is not yet in a
released version of the txscript module, bump the requirement to include
an as yet unreleased version of txscript to ensure the next time the
blockchain module is released, it will require a newer version of
txscript to be released first.
This updates all of the modules that still rely on v1 of the chaincfg
module to use v1.5.1 which builds correctly with the major API bump
introduced in the edwards v1.0.0 module.
While here, it also updates all references to the v0 edwards and dcrec
modules to their tagged v1 counterparts, tidies all of the modules via
go mod tidy, and removes all unnecessary indirect entries from the mod
files to keep the modules using the versions the dependencies are tested
with.
The primary motivation for this change is that the chaincfg/v2 module
requires edwards/v1 which is not API compatible with edwards/v0.
Consequently, in order for each module to be incrementally updated to
use chaincfg/v2, all of its dependencies must also be able to build with
edwards/v1 which is the case as of chaincfg v1.5.1.
This removes a couple of checks for impossible conditions found by the
staticcheck linter. In the case of executeOpcode, bytes are always >= 0
and, similarly for SigCache.Add, uint are always >= 0.
This converts the test definitions for TestRemoveOpcodeByData to make
use of mustParseShortForm which improves the readability and
construction of the tests as well as makes them more consistent with the
rest of the code base.
It also cleans up the recently added stake tx tests so that they don't
exceed col 80 and sets their names to indicate they are p2pkh and p2sh
forms.
This converts the callback function defined on the internal opcode
struct to accept the opcode and data slice instead of a parsed opcode as
the final step towards removing the parsed opcode struct and associated
supporting code altogether.
It also updates all of the callbacks and tests accordingly and finally
removes the now unused parsedOpcode struct.
This converts the executeOpcode function defined on the engine to accept
an opcode and data slice instead of a parsed opcode as a step towards
removing the parsed opcode struct and associated supporting code altogether.
It also updates all callers accordingly.
This refactors the script engine to store and step through raw scripts
by making using of the new zero-allocation script tokenizer as opposed
to the less efficient method of storing and stepping through parsed
opcodes. It also improves several aspects while refactoring such as
optimizing the disassembly trace, showing all scripts in the trace in
the case of execution failure, and providing additional comments
describing the purpose of each field in the engine.
It should be noted that this is a step towards removing the parsed
opcode struct and associated supporting code altogether, however, in
order to ease the review process, this retains the struct and all
function signatures for opcode execution which make use of an individual
parsed opcode. Those will be updated in future commits.
The following is an overview of the changes:
- Modify internal engine scripts slice to use raw scripts instead of
parsed opcodes
- Introduce a tokenizer to the engine to track the current script
- Remove no longer needed script offset parameter from the engine since
that is tracked by the tokenizer
- Add an opcode index counter for disassembly purposes to the engine
- Update check for valid program counter to only consider the script
index
- Update tests for bad program counter accordingly
- Rework the NewEngine function
- Store the raw scripts
- Setup the initial tokenizer
- Explicitly check against version 0 instead of DefaultScriptVersion
which would break consensus if changed
- Check the scripts parse according to version 0 semantics to retain
current consensus rules
- Improve comments throughout
- Rework the Step function
- Use the tokenizer and raw scripts
- Create a parsed opcode on the fly for now to retain existing
opcode execution function signatures
- Improve comments throughout
- Update the Execute function
- Explicitly check against version 0 instead of DefaultScriptVersion
which would break consensus if changed
- Improve the disassembly tracing in the case of error
- Update the CheckErrorCondition function
- Modify clean stack error message to make sense in all cases
- Improve the comments
- Update the DisasmPC and DisasmScript functions on the engine
- Use the tokenizer
- Optimize construction via the use of strings.Builder
- Modify the subScript function to return the raw script bytes since the
parsed opcodes are no longer stored
- Update the various signature checking opcodes to use the raw opcode
data removal and signature hash calculation functions since the
subscript is now a raw script
- opcodeCheckSig
- opcodeCheckMultiSig
- opcodeCheckSigAlt
This converts the engine's current program counter disasembly to make
use of the standalone disassembly function to remove the dependency on
the parsed opcode struct.
It also updates the tests accordingly.
This converts the checkMinimalDataPush function defined on a parsed
opcode to a standalone function which accepts an opcode and data slice
instead in order to make it more flexible for raw script analysis.
It also updates all callers accordingly.
This converts the isConditional function defined on a parsed opcode to a
standalone function named isOpcodeConditional which accepts an opcode as
a byte instead in order to make it more flexible for raw script
analysis.
It also updates all callers accordingly.
This converts the alwaysIllegal function defined on a parsed opcode to a
standalone function named isOpcodeAlwaysIllegal which accepts an opcode
as a byte instead in order to make it more flexible for raw script
analysis.
It also updates all callers accordingly.
This converts the isDisabled function defined on a parsed opcode to a
standalone function which accepts an opcode as a byte instead in order
to make it more flexible for raw script analysis.
It also updates all callers accordingly.
This introduces a new function named removeOpcodeByDataRaw which accepts
the raw scripts and data to remove versus requiring the parsed opcodes
to both significantly optimize it as well as make it more flexible for
working with raw scripts.
There are several places in the rest of the code that currently only
have access to the parsed opcodes, so this only introduces the function
for use in the future and deprecates the existing one.
Note that, in practice, the script will never actually contain the data
that is intended to be removed since the function is only used during
signature verification to remove the signature itself which would
require some incredibly non-standard code to create.
Thus, as an optimization, it avoids allocating a new script unless there
is actually a match that needs to be removed.
Finally, it updates the tests to use the new function.
This converts SignTxOutput and supporting funcs, namely sign,
mergeScripts and mergeMultiSig, to make use of the new tokenizer as well
as some recently added funcs that deal with raw scripts in order to
remove the reliance on parsed opcodes as a step towards utlimately
removing them altogether and updates the comments to explicitly call out
the script version semantics.
It is worth noting that this has the side effect of optimizing the
function as well, however, since this change is not focused on the
optimization aspects, no benchmarks are provided.