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 all code in the main module to use the latest major modules
versions to pull in the latest updates.
A more general high level overview of the changes is provided below,
however, there is one semantic change worth calling out independently.
The verifymessage RPC will now return an error when provided with
an address that is not for the current active network and the RPC server
version has been bumped accordingly.
Previously, it would return false which indicated the signature is
invalid, even when the provided signature was actually valid for the
other network. Said behavior was not really incorrect since the
address, signature, and message combination is in fact invalid for the
current active network, however, that result could be somewhat
misleading since a false result could easily be interpreted to mean the
signature is actually invalid altogether which is distinct from the case
of the address being for a different network. Therefore, it is
preferable to explicitly return an error in the case of an address on
the wrong network to cleanly separate these cases.
The following is a high level overview of the changes:
- Replace all calls to removed blockchain merkle root, pow, subsidy, and
coinbase funcs with their standalone module equivalents
- Introduce a new local func named calcTxTreeMerkleRoot that accepts
dcrutil.Tx as before and defers to the new standalone func
- Update block locator handling to match the new signature required by
the peer/v2 module
- Introduce a new local func named chainBlockLocatorToHashes which
performs the necessary conversion
- Update all references to old v1 chaincfg params global instances to
use the new v2 functions
- Modify all cases that parse addresses to provide the now required
current network params
- Include address params with the wsClientFilter
- Replace removed v1 chaincfg constants with local constants
- Create subsidy cache during server init and pass it to the relevant
subsystems
- blockManagerConfig
- BlkTmplGenerator
- rpcServer
- VotingWallet
- Update mining code that creates the block one coinbase transaction to
create the output scripts as defined in the v2 params
- Replace old v2 dcrjson constant references with new types module
- Fix various comment typos
- Update fees module to use the latest major module versions and bump it v2
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 defines several new functions on the Params struct which return
some subsidy-related parameters.
The new functions are:
- BaseSubsidyValue
- SubsidyReductionMultiplier
- SubsidyReductionDivisor
- SubsidyReductionIntervalBlocks
- WorkSubsidyProportion
- StakeSubsidyProportion
- TreasurySubsidyProportion
This will allow the parameters to be used directly as input to an
interface in the future.
This defines several new functions on the Params struct which return
some stake-related parameters.
The new functions are:
- VotesPerBlock
- StakeValidationBeginHeight
- StakeEnableHeight
- TicketExpiryBlocks
This will allow the parameters to be used directly as input to an
interface in the future.
chaincfg/v2 modified the Params type to contain the required payouts
created by the miner of the block at height 1. However, it was
discovered that, due to code generation issues of the Go compiler,
this caused the package's weight (measured by
github.com/jondot/goweight) to explode to 7.7 MB. This appears to be
due to an enormous amount of function calls, all of which could panic,
when building the large slice literal.
This improves the compiled size of the package by using code
generation techniques to optimize the memory layout and code
transformation of the subsidy values each time a params function is
called. A single string contains all scripts for subsidy payouts
concatenated together, in hex encoding, and a slice contains the index
in the script data and the required payout amount. This is iterated
in a loop to create a []TokenPayout each time it is needed.
The new size of the compiled package using Go 1.12.7 on OpenBSD/amd64
is 379 kB, a reduction of 7.32 MB, and about 5% of the original size.
This defines several new functions on the Params struct which return the
magic prefix bytes for addresses.
The new functions are:
- AddrIDPubKeyV0
- AddrIDPubKeyHashECDSAV0
- AddrIDPubKeyHashEd25519V0
- AddrIDPubKeyHashSchnorrV0
- AddrIDScriptHashV0
This will allow the parameters to be used directly as input to an
interface in the future.
This updates the chaincfg module to make use of the recently-tagged
dcrec/edwards v1 module and thereby corrects the dependencies for the
chainec package within the chaincfg/v2 module.
The current network parameter definitions are all package-level globals
which have a few undesirable characteristics:
- They are subject to mutation and thus can easily cause subtle and hard
to find bugs
- Many of the fields are defined in terms of others, but due to the
struct being defined at the top level, it's not possible to reference
other fields within it
- They require a lot of unexported global variable state
- It makes it difficult to introduce a base set of parameters that would
likely help highlight exactly what the differences are between the
networks
Consequently, this converts all of the global network parameter
defintions to functions that return a new instance of the relevant
parameters which either directly addresses the aforementioned point, or
at the very least, allows them to be addresses in future commits.
The following is a high level overview of the changes:
- Move all default definitions into functions that return a new instance
of the relevant params
- Move global defintions of variables used in the structs into the
relevant funcs
- Improve consistency in the tests for each set of network params
- Update example in README.md
- Update example doc.go
This modifies the definitions for the required payouts in block one to
define required scripts instead of an address string as well as specify
the required script version and updates all of the network params
accordingly.
This is being done because addresses are a non-consensus construct that
essentially provide a human-readable method of specifying the actual
underlying cryptographic primitives. Thus, the consensus rules
themselves must not directly rely on the ability to interpret and parse
addresses.
It is important to note that, once the blockchain code is updated to
make use of the changes this introduces, it is technically a fork since
the code will be more restrictive, but since it only applies to block
one, it's irrelevant because:
- It's buried under years of blocks
- The actual ledger of block one is unchanged
This modifies the Params struct to store the genesis hash directly
instead of a pointer to it. This makes it more consistent with the rest
of the code base and avoids the need for a separate variable.
This moves the various code that is specific to regnet to the
regnetparams.go file to keep the information housed together. Along the
same lines, it moves the tests specific to the regnet params to
regnetparams_test.go.
It also unexports the block one ledger definition since it should only
be exposed via the params.
This moves the various code that is specific to simnet to the
simnetparams.go file to keep the information housed together. Along the
same lines, it moves the tests specific to the simnet params to
simnetparams_test.go.
It also unexports the block one ledger definition since it should only
be exposed via the params.
This moves the various code that is specific to testnet to the
testnetparams.go file to keep the information housed together. Along
the same lines, it moves the tests specific to the testnet params to
testnetparams_test.go.
It also unexports the block one ledger definition since it should only
be exposed via the params.
This moves the various code that is specific to mainnet to the
mainnetparams.go file to keep the information housed together. Along
the same lines, it moves the tests specific to the mainnet params to
mainnetparams_test.go.
It also unexports the block on ledger definition since it should only be
exposed via the params.
This removes all of the global registration capabilities from chaincfg
as part of the overall drive towards removing side effects that alter
the global state when importing packages and providing cleaner module
boundaries by reducing tight coupling betwee them.
For a bit of history, the package was designed back near the time Go
released before anyone had much experience with Go based on some other
early examples in the stdlib which many, including most of the original
authors, have come to realize is not ideal because it essentially alters
global state and has side effects merely by importing the package. This
can cause issues if multiple copies of the same package try to register
themselves.
Also, on a less theoretical note, with the benefit of hindsight and
experience, there isn't really any practical benefit to registering the
networks and allowing custom ones to be registered over just accepting a
params interface into the packages that need them whereas there are
tangible downsides having global registration factories as mentioned.
Accepting interfaces to the relevant functions in the other packages
will also significantly reduce the tight coupling that currently exists
with chaincfg and limit the scope of the needed parameters to
specifically those required by the functions in question.
An overview of the changes is as follows:
- Remove the following functions:
- Register
- IsPubKeyAddrID
- IsPubKeyHashAddrID
- IsPKHEdwardsAddrID
- IsPKHSchnorrAddrID
- IsScriptHashAddrID
- HDPrivateKeyToPublicKeyID
- ParamsByNetAddrPrefix
- Remove the following (now unused) errors:
- ErrDuplicateNet
- ErrUnknownHDKeyID
- ErrDuplicateNetAddrPrefix
- ErrUnknownNetAddrPrefix
- Remove all associated tests
- Update README to call out correct number of default net params
This adds a test to ensure that all of the network parameter fields that
are required to be unique are in fact unique for all of the provided
default parameters.
It should be noted that part of this is currently redundant with the
network registration code, however, that is going to be removed.
This removes the exported CPUMinerThreads constant because it is not a
per-chain parameter and therefore does not belong here.
Further, it is only used in the mining code and since it's an exported
constant, it couldn't be changed without a major version bump and there
is no reason this shouldn't be defined in the mining code itself.
This removes the exported CheckForDuplciateHashes constant because it is
not a per-chain parameter and therefore does not belong here.
Further, it is only used in blockchain and since it's an exported
constant, it couldn't be changed without a major version bump, which
would cause everything that relies on it to also bump majors.
This removes the exported SigHashOptimization constant because it is not
a per-chain parameter and therefore does not belong here.
Further, it is only used in txscript and since it's an exported
constant, it couldn't be changed without a major version bump, which
would cause everything that relies on it to also bump majors.
This renames the recently introduced accessor functions for obtaining
the hierarchical deterministic extended private and public key magic
version bytes based on feedback.
Ordinarily this would require a major module version bump, however,
since a new version with the functions has not been released yet, it is
acceptable to rename them without breaking callers.
This defines two new functions named XPrivKeyID and XPubKeyID on the
Params struct which return the hierarchical deterministic extended
private and public key magic version bytes, respectively.
This will allow the parameters to be used directly as input to an
interface in the future.
This adds the go 1.11 directive to all of the modules in order to
clearly mark they build and work with that version. Go 1.12 modified
the tools such that tidy will automatically add the new version to
modules that do not already have a directive and that would prevent
builds on Go 1.11 through Go 1.11.3 which is not desirable.
This modifies the registration process to enforce the already implicit
assumption that the network address prefix is unique per network so that
it is now an explicit requirement.
This is desirable because the address format contains a network
identification byte which is used elsewhere in the code to uniquely
identify which parameters to use.
This uses the expected merkle root variable in the genesis block
definition for the regression test network. It's the same value so
there is no functional change.
This moves a test in chaincfg which belongs to chainhash package.
The test case that has been moved has already been covered in
chainhash test suite, but instead of deleting the test case it has
been moved, so to have a stronger test suite.
This modifies all of the modules, with the exception of the root module,
to remove all replacement directives from their go.mod files and update
the requirements and module sums accordingly.
While it is nice to be able to build and test directly from each module
directory and have it pull in the latest untagged changes when
developing, having all of the overrides in each module makes it
infeasible to use the module tools to help maintain the modules and thus
makes it quite difficult to ensure they are all independently accurate
for external consumers.
By maintaining all of the overrides in the root module and invoking all
builds and tests from it, the overrides will apply to ensure the latest
code is being built and tested.
This also modifies the tests script used with in CI to run all of the
tests from the root module accordingly.
This adds a new definition for the upcoming agenda vote to enable the
corrected sequence locks behavior as defined by DCP0004. It does not
include any code to make decisions or bump the versions. It is only the
definition.
Also, bump the chaincfg module to v1.3.0 so the new definitions are
available to consumers.
This adds a checkpoint to mainnet at height 295940 and testnet at height
83520.
Also, bump the chaincfg module to v1.2.1 so the new checkpoint are
available to consumers.
This bumps the various module versions as follows:
- github.com/decred/dcrd/dcrec/secp256k1@v1.0.1
- github.com/decred/dcrd/dcrjson@v1.1.0
- github.com/decred/dcrd/database@v1.0.3
- github.com/decred/dcrd/blockchain/stake@v1.1.0
- github.com/decred/dcrd/mining@v1.1.0
- github.com/decred/dcrd/certgen@v1.0.2
- github.com/decred/dcrd/connmgr@v1.0.2
- github.com/decred/dcrd/mempool@v1.1.0
In addition, it serves as a base for tagging releases of the following
module versions that have previous been bumped since the last release,
but not yet tagged:
- github.com/decred/dcrd/wire@v1.2.0
- github.com/decred/dcrd/chaincfg@v1.2.0
- github.com/decred/dcrd/dcrutil@v1.2.0
- github.com/decred/dcrd/txscript@v1.0.2
- github.com/decred/dcrd/blockchain@v1.1.0
- github.com/decred/dcrd/hdkeychain@v1.1.1
- github.com/decred/dcrd/peer@v1.1.0
- github.com/decred/dcrd/rpcclient@v1.1.0
Finally, it updates all of the dependencies for every module accordingly,
adds a few missing overrides for transitive dependencies, and tidies up
some of the go module sum files.
These errors are only used internally and thus should not be exported.
While here, it also removes the completely unused VoteBitsNotFound
error.
It should be noted that this is a breaking change to the API and thus
will need a v2 major version bump of the chaincfg module to be published
before the changes can be externally consumed.
This modifies simnet to include the latest consensus changes that have
been successfully voted into mainnet to date starting from its genesis
block. This means it is no longer necessary to vote those changes in to
simnet first before making use of them.
The changes entail removing the deployment entries for those votes,
updating the mining templates to start from version 5, which matches the
current mainnet version, and modifying the various sections in
blockchain which make decisions accordingly.
The chaincfg and blockchain modules are affected, but since their
version has already been bumped since their last release tags, they are
not bumped again.
This resurrects the regression test network that was removed before
initial launch although it really should not have been. The simulation
test network and the regression test network do not serve the same
purpose. Specifically, the regression test network is intended for unit
tests, RPC server tests, and consensus tests. On the other hand, the
simulation test network is intended for private use within a group of
individuals doing simulation testing and full integration tests between
different applications such as wallets, voting service providers, mining
pools, block explorers, and other services that build on Decred.
Keeping the concerns separate will allow the simulation test network to
be modified in ways such as activating consensus changes that have been
successfully voted into mainnet without also needing to vote them in on
the simulation test network while still preserving the ability for the
unit tests to properly test the voting semantics and handling to help
prevent regressions.
In addition to resurrecting the regression test network, this also fully
fleshes out new values for the various addresses prefixes (Rk, Rs, Re,
etc), HD key prefixes (rprv, rpub), and treasury multisig details.
As a part of resurrecting the network, a new CLI flag `--regnet` is
added to allow the RPC test harness connect to a running instance, the
areas of the code which involve votes have been modified to allow the
votes to apply to the new network, and tests have been added to the
relevant modules.
This bumps the affected module versions as follows:
- github.com/decred/dcrd/wire@v1.2.0
- github.com/decred/dcrd/chaincfg@v1.2.0
- github.com/decred/dcrd/dcrutil@v1.2.0
- github.com/decred/dcrd/hdkeychain@v1.1.1
The blockchain module is also affected, but since its version has
already been bumped since the last release tag, it is not bumped again.
Finally, this does not include switching unit tests or the RPC test
harness over the new network since that will be done in a separate
commit.
This bumps the various module versions as follows:
- github.com/decred/dcrd/addrmgr@v1.0.2
- github.com/decred/dcrd/wire@v1.1.0
- github.com/decred/dcrd/chaincfg@v1.1.1
- github.com/decred/dcrd/connmgr@v1.0.1
- github.com/decred/dcrd/dcrutil@v1.1.1
- github.com/decred/dcrd/database@v1.0.1
- github.com/decred/dcrd/hdkeychain@v1.1.0
- github.com/decred/dcrd/txscript@v1.0.1
- github.com/decred/dcrd/blockchain/stake@v1.0.1
- github.com/decred/dcrd/gcs@v1.0.1
- github.com/decred/dcrd/blockchain@v1.0.1
- github.com/decred/dcrd/mining@v1.0.1
- github.com/decred/dcrd/mempool@v1.0.1
- github.com/decred/dcrd/peer@v1.0.1
- github.com/decred/dcrd/rpcclient@v1.0.1
It also updates all of the dependencies for every module accordingly and
adds a few missing overrides for transitive dependencies.
