Upcoming changes constitute breaking public API changes to the chaincfg
module, therefore, this follows the process for introducing major API
breaks which consists of:
- Bump the major version in the go.mod of the affected module if not
already done since the last release tag
- Add a replacement to the go.mod in the main module if not already done
since the last release tag
- Update all imports in the repo to use the new major version as
necessary
- Make necessary modifications to allow all other modules to use the
new version in the same commit
- Repeat the process for any other modules the require a new major as a
result of consuming the new major(s)
This modifies blockchain to expose a new field named Checkpoints in the
Config struct which allows the checkpoints to use to be specified by the
caller instead of assuming the checkpoint associated with the current
chain parameters. This allows the caller to customize the checkpoints
as it sees fit, such as adding custom checkpoints or removing default
checkpoints.
In addition, this removes the DisableCheckpoints function in favor of
the caller simply configuring the chain instance without checkpoints
when they're disabled and updates the code to remove the associated flag
accordingly. This produces simpler code and is faster since the mutex
that was required to protect the aforementioned flag is no longer
required.
Finally, this also paves the way to significantly simplify the
checkpoint finding logic and make further progress towards the overall
effort to decouple the connection code from the download logic.
This decouples and removes the orphan handling from blockchain in favor
of implementing it in the block manager as part of the overall effort to
decouple the connection code from the download logic.
The change might not make a ton of sense in isolation, since there is no
major functional change, however, decoupling the orphan handling
independently helps make the review process easier and alleviates what
would otherwise result in additional intermediate code to handle cases
that ultimately will no longer exist.
The following is a high level overview of the changes:
- Introduce blockchain function to more easily determine if an error is
a rule error with a given error code
- Move core orphan handling code from blockchain to block manager
- Move data structures used to cache and track orphan blocks
- Move all functions releated to orphans
- BlockChain.IsKnownOrphan -> blockManager.isKnownOrphan
- BlockChain.GetOrphanRoot -> blockManager.orphanRoot
- BlockChain.removeOrphanBlock -> blockManager.removeOrphanBlock
- BlockChain.addOrphanBlock -> blockManager.addOrphanBlock
- Implement orphan handling in block manager
- Rework to use the moved functions and data structs
- Add check for known orphans in addition HaveBlock calls to retain
the same behavior
- Modify the semantics of the process block func exposed by the block
manager so that it no longer stores orphans since all consumers of
it ultimately reject orphans anyway
- Remove remaining orphan related code from blockchain
- Update ProcessBlock to return an error when called with an orphan
- Remove additional orphan processing from ProcessBlock
- Remove orphan cache check from HaveBlock
- Adjust example to account for the removed parameter
- Change chaingen harness tests to detect orphans via returned error
- Modify fullblock tests to detect orphans via returned error
- Adapt process order logic tests to cope with lack of orphan
processing
- Update all other tests accordingly
- Update various comments and the README.md and doc.go to properly
reflect the removal of orphan handling
Some indexes require all of the previous output scripts referenced as
inputs by the blocks they are indexing. Currently, the indexing code
relies on a concrete blockchain.UtxoViewpoint to provide that
information which makes the indexing code more rigid than it needs to be
and prevents the possibility of using other sources, such as the spend
journal, to provide the necessary scripts.
In addition, the index initialization code also currently requires
access to a concrete blockchain.BlockChain to query the current chain
state which also makes the code more rigid than it should ideally be.
Consequently, this modifies the indexing code to accept a PrevScripter
interface to remove the tight coupling to a specific type in the former
case, and introduces a new ChainQueryer interface to remove the tight
coupling in the latter case.
In order to fully remove the blockchain dependency from the indexers
package, this also moves the IndexManager interface from blockchain to
indexers and modifies it to use the new ChainQueryer interface in order
to provide the necessary information.
Finally, all code is updated to satisfy and use the interfaces.
Several upcoming changes constitute breaking public API changes to the
blockchain module, therefore, this follows the process for introducing
major API breaks which consists of:
- Bump the major version in the go.mod of the affected module if not
already done since the last release tag
- Add a replacement to the go.mod in the main module if not already done
since the last release tag
- Update all imports in the repo to use the new major version as
necessary
- Make necessary modifications to allow all other modules to use the
new version in the same commit
- Repeat the process for any other modules the require a new major as a
result of consuming the new major(s)
This removes the getblocktemplate and its helpers from the codebase.
Ongoing mining updates focused on the voting/block validation process
with respect to generating block templates for getwork makes it the
better option for decred. Also getblocktemplate rpc was buggy and
has been disabled for a while.
Some lint related issues have been addressed as well.
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 modifies the code to use the decred fork of the go-socks module
throughout and updates the affected modules to use the v1.0.0 release of
the socks module.
This commit introduces a new major version of the dcrjson module which
removes all dcrd RPC type support, instead focusing only on method and
type registration. The dcrd methods and types are moved to the
github.com/decred/dcrd/rpc/jsonrpc/types module.
In order to improve backwards compatibility with dcrjson/v2, the API
has been modified to register methods as interface{} instead of
string. This allows different method string types to be used to key
parameter types during registration and lookup, and will allow
dcrjson/v2 to forward registrations of RPC methods to v3 without
causing duplicate registrations errors for incompatible types.
With the introduction of the new types package, the RPC API has been
modified to replace concatenated hash blobs to JSON string arrays of
hash strings. The RPC API major version is bumped to reflect this
change.
A future update to dcrjson/v2 will add additional registrations,
forwarding the registrations to v3 and replacing command types with
type aliases where possible. Unfortunately, this can not be done
entirely in a single commit due to dcrjson/v2 and dcrjson/v3 sharing
the same directory in the source tree, and a branch will need to be
used for this update.
Module replacements are temporarily used to enable the changes for the
main module, including dcrctl. After the aforementioned update to
dcrjson/v2 and a forthcoming update to dcrwallet's RPC types package,
these replacements will be removed.
This updates dcrctl to use version 2 of the dcrjson module and to make
use of the new separate type definitions provided by wallet so it
continues supporting communication with dcrwallet.
This makes the version string printed by the -V/--version flag
consistent with dcrd. In particular it will now include the runtime
version, OS, and architecture.
This introduces a new internal package named version to house the
version information and updates the various code to use it. This allows
both dcrd and dcrctl to make use of the package so the version
information only needs to be bumped in one place and also ensure that
any link-time overrides to the pre-release and/or build metadata apply
to both.
Also, while here, include the OS and architecture in the version log at
start of day as well as the output from the version CLI flag.
This marks the start of a new release process as compared to previous
releases.
Instead of bumping the version just before a release and releasing from
the master branch, as has been done up to this point, the minor (or
major when necessary) will now be bumped on the master branch at the
beginning of a release cycle. In addition, the pre-release portion of
the semantic version is now the string "pre" to help make it more
obvious that the master branch represents a pre-release build of work
leading up to the next release.
When a new release is prepared, a new release branch will be created
that has a naming scheme of "release-vX.Y", where X is the major and Y
is the minor. Any additional commits needed to prepare the release
leading up to a release candidate will be cherry-picked to the release
branch, and all tags for releases and release candidates will be created
against that.
This implies that should any additional patch releases be necessary, the
relevant commits will also be cherry-picked to the release branch as
needed, followed by a new release candidate for the patch release and
the eventual patch release.
This adds a new testnet3 network with new genesis block, block one
ledger, treasury address, and network magic.
All consensus rules that were voted in by testnet2 are automatically
active on the new testnet3 without having to vote them in again.
Consequently, there are no consensus vote agendas defined for it.
This removes the funcs which were used to override the test network name
as they were inherited from the upstream code and, once testnet v2 was
introduced, were no longer needed, but unfortunately weren't removed
accordingly.
This modifies the ProcessBlock function in the blockchain package to
return the fork length for the connected block and updates all callers
and tests accordingly. Several of the internal functions which
ProcessBlock calls are also updated in order to bubble the necessary
information back up so it can be returned. It does not make any
behavioral changes.
This is being done to better expose information about the position of
the block within the chain to callers without them having to make
additional queries.
This modifies all packages within the repository to the use the Decred
fork of btclog which has been renamed to slog and updates the dependency
files accordingly.
This corrects an issue introduced by commit
c6f9474348 which resulted in empty paths
that were cleaned and expanded being transformed into "." instead of
having no effect as intended.
This fixes the behavior of expanding ~ on Windows and macOS, as well
as adding support for ~otheruser to expand to the home directory of
otheruser.
Modify the default sample config to reflect the change in the meaning
of ~ on Windows, and the unintended meaning of ~ on macOS. Include
defaults for all 3 of the major operating system classes since
uncommenting the default Unix option on macOS or Windows would change
the blockchain data directory to a non-default location.
This modifies the BestState struct in the blockchain package to store
hashes directly instead of pointers to them and updates callers to deal
with the API change in the exported BestState struct.
In general, the preferred approach for hashes moving forward is to store
hash values in complex data structures, particularly those that will be
used for cache entries, and accept pointers to hashes in arguments to
functions.
Some of the reasoning behind making this change is:
- It is generally preferred to avoid storing pointers to data in cache
objects since doing so can easily lead to storing interior pointers into
other structs that then can't be GC'd
- Keeping the hash values directly in the structs provides better
cache locality
This modifies the IsSStx, IsSSGen, and IsSSRtx functions to only return
a bool and introduces CheckSStx, CheckSSGen, and CheckSSRtx to return
the actual error as needed by consensus.
This is being done because "is" functions are much nicer to use when
they don't return an error and the callers that use them almost never
care why they aren't of the type, they just want to determine if they
are. In the few cases where the caller does care, they can use of the
new check functions.
While here, also update the comments to call out what the more common
names for the transaction types are and to add comments to the test
functions for consistency.
Finally, it updates all callers in the repo accordingly.
This merge commit adds the following code from the
github.com/decred/dcrutil package into a new
github.com/decred/dcrd/dcrutil package:
* Address handling
* Amount type
* AppDataDir func
* bitflags functions
* Block wrapper type
* Hash160 func
* Tx wrapper type
* WIF type
as well as all tests for this code.
The old github.com/decred/dcrutil/hdkeychain package has also been
merged and moved to github.com/decred/dcrd/dcrutil/hdkeychain.
dcrd packages have been updated to use the new packages and the dep
files have been updated for this change.
Contains the following upstream commits:
- 42a4366ba8
- This is a NOOP since it has already previously been applied
- 77913ad2e8
Most of the changes related to this merge have already previously
applied, so this primarily just minimizes the differences versus
upstream.
