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 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 dcrutil dependencies and serves as a base for
dcrutil/v1.3.0.
The updated direct dependencies 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
- golang.org/x/crypto@v0.0.0-20190611184440-5c40567a22f8
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 serves as the final release of version 1 of the chaincfg module.
All future releases will be moving to version 2 of the module.
Consequently, it bumps the module version as follows:
- github.com/decred/dcrd/chaincfg@v1.5.0
It also removes the chaincfg override in the root module and updates it
so building the software will still produce binaries based on the v1
module until the v2 module is fully released.
This adds the function NewEd25519TLSCertPair which uses Ed25519 keys
rather than ECDSA keys as required by NewTLSCertPair.
Conditional compilation is used to provide the function only on Go 1.13.
It also updates the documentation accordingly.
This is a port of btcd commit b26daffac9dfe496c91a859c35a8bbe33c054b61.
This commit extends the work started by roasbeef in the
previous commit to bring full cancellation of pending
connection requests. It also adds minor refactors to
channel send/receives to help cleanup potentially
lingering go routines.
The tests in the original commit were adapted to conform to dcrd's
function signatures and a few typos were fixed. The new state introduced
by the commit (ConnCanceled) was changed to be a new one at the end of
the possible states list and the ConnFailing state was renamed back to
ConnFailed. This was done to prevent having to perform a major version
bump in the connmgr module, given those states are part of the public
API.
This is a port of btcd commit 548c0f499b24e31fa18fe6a48493e01175b54fe8.
This commit adds the ability for callers to remove pending connections
via a call to the Remove() method. With this change, upstream users of
this package can use the connmgr for more elaborate connectivity needs
as they can now cancel pending connections that are no longer needed.
The test was adapted to use the new DialAddr function, given the
difference in the function signature for Dial between btcd and dcrd.
This allows rpctest users to set a custom mining function for the voting
walles. Externally, this will be used to provide a simnet mining
function that generates blocks without triggering a difficulty increase.
This modifies the UpdateLastBlockHeight function to ensure the new
height is after the existing height before updating it in order to
prevent it from going backwards so it properly matches the intent of the
function which is to report the latest known block height for the peer.
Without this change, the value will properly start out at the latest
known block height reported by the peer during version negotiation,
however, it will be set to lower values when syncing from the peer due
to requesting old blocks and blindly updating the height.
It also adds a test to ensure proper functionality.
Race-enabled testing is an order of magnitude slower. This causes issues
for pull requests which add more tests, due to elapsed timeouts on the
CI infrastructure, and it is more desirable to have a comprehensive test
suite running without -race than few tests with it.
To test with -race locally, just run go test -race as usual, or (better)
build and run a race-enabled binary.
