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 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 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.
This option allows one to specify a different option for the wallet
rpc server it will connect to. This is primarily meant to be used in
the config file so that a single dcrctl.conf may be used in the
situation where the wallet is on one host and dcrd is on another host.
dcrctl does not require dcrd so it should not keep complaining about
it missing. Just skip automatic configuration if dcrd's configuration
is missing, but still set it up in the future if one appears and dcrctl
is still lacking a configuration file.
By default, put 'dev' in the prerelease field.
For release builds we can add 'release' with the build scripts.
Update comment for current (post 1.5) usage on ldflags -X while there.
The problem of securely prompting for secrets and not leaving secrets in shell
history can be solved in better ways, such as implementing a tool to read a
secret and write it back to standard output, allowing the secret to be piped to
dcrctl. Luckily dcrctl already supports this feature!
No (official) tool exists so far, but the workflow would look like this:
promptsecret | dcrctl --wallet walletpassphrase - 60
While here removing unneeded deps from the glide files, also throw in an
unrelated dcrrpcclient dep update.
This commit is the first stage of several that are planned to convert
the blockchain package into a concurrent safe package that will
ultimately allow support for multi-peer download and concurrent chain
processing. The goal is to update btcd proper after each step so it can
take advantage of the enhancements as they are developed.
In addition to the aforementioned benefit, this staged approach has been
chosen since it is absolutely critical to maintain consensus.
Separating the changes into several stages makes it easier for reviewers
to logically follow what is happening and therefore helps prevent
consensus bugs. Naturally there are significant automated tests to help
prevent consensus issues as well.
The main focus of this stage is to convert the blockchain package to use
the new database interface and implement the chain-related functionality
which it no longer handles. It also aims to improve efficiency in
various areas by making use of the new database and chain capabilities.
The following is an overview of the chain changes:
- Update to use the new database interface
- Add chain-related functionality that the old database used to handle
- Main chain structure and state
- Transaction spend tracking
- Implement a new pruned unspent transaction output (utxo) set
- Provides efficient direct access to the unspent transaction outputs
- Uses a domain specific compression algorithm that understands the
standard transaction scripts in order to significantly compress them
- Removes reliance on the transaction index and paves the way toward
eventually enabling block pruning
- Modify the New function to accept a Config struct instead of
inidividual parameters
- Replace the old TxStore type with a new UtxoViewpoint type that makes
use of the new pruned utxo set
- Convert code to treat the new UtxoViewpoint as a rolling view that is
used between connects and disconnects to improve efficiency
- Make best chain state always set when the chain instance is created
- Remove now unnecessary logic for dealing with unset best state
- Make all exported functions concurrent safe
- Currently using a single chain state lock as it provides a straight
forward and easy to review path forward however this can be improved
with more fine grained locking
- Optimize various cases where full blocks were being loaded when only
the header is needed to help reduce the I/O load
- Add the ability for callers to get a snapshot of the current best
chain stats in a concurrent safe fashion
- Does not block callers while new blocks are being processed
- Make error messages that reference transaction outputs consistently
use <transaction hash>:<output index>
- Introduce a new AssertError type an convert internal consistency
checks to use it
- Update tests and examples to reflect the changes
- Add a full suite of tests to ensure correct functionality of the new
code
The following is an overview of the btcd changes:
- Update to use the new database and chain interfaces
- Temporarily remove all code related to the transaction index
- Temporarily remove all code related to the address index
- Convert all code that uses transaction stores to use the new utxo
view
- Rework several calls that required the block manager for safe
concurrency to use the chain package directly now that it is
concurrent safe
- Change all calls to obtain the best hash to use the new best state
snapshot capability from the chain package
- Remove workaround for limits on fetching height ranges since the new
database interface no longer imposes them
- Correct the gettxout RPC handler to return the best chain hash as
opposed the hash the txout was found in
- Optimize various RPC handlers:
- Change several of the RPC handlers to use the new chain snapshot
capability to avoid needlessly loading data
- Update several handlers to use new functionality to avoid accessing
the block manager so they are able to return the data without
blocking when the server is busy processing blocks
- Update non-verbose getblock to avoid deserialization and
serialization overhead
- Update getblockheader to request the block height directly from
chain and only load the header
- Update getdifficulty to use the new cached data from chain
- Update getmininginfo to use the new cached data from chain
- Update non-verbose getrawtransaction to avoid deserialization and
serialization overhead
- Update gettxout to use the new utxo store versus loading
full transactions using the transaction index
The following is an overview of the utility changes:
- Update addblock to use the new database and chain interfaces
- Update findcheckpoint to use the new database and chain interfaces
- Remove the dropafter utility which is no longer supported
NOTE: The transaction index and address index will be reimplemented in
another commit.
The configuration autogenerator currently does not work well
and tries to read the sample file based on where the compiled
source's data directory was. This has been fixed so that dcrd
only checks the %PROGRAMFILES% directory on Windows where the
sample configuration file might be stored. Configuration
autogeneration has been disabled for toehr operating systems.
