This updates the comments detailing the origin of the polynomial
coefficients in the ASERT calculation to the more precise values which
also matches up with the standalone code.
This updates the blockchain module dependencies, the copyright year in
the files modified since the previous release, and serves as a base for
blockchain/v5.0.0.
The updated direct dependencies in this commit are as follows:
- github.com/decred/dcrd/chaincfg/v3@v3.2.0
- github.com/decred/dcrd/dcrec@v1.0.1
- github.com/decred/dcrd/dcrec/secp256k1/v4@v4.2.0
- github.com/decred/dcrd/dcrutil/v4@v4.0.1
- github.com/decred/dcrd/txscript/v4@v4.1.0
The updated indirect dependencies in this commit are as follows:
- github.com/dchest/siphash@v1.2.3
- github.com/decred/base58@v1.0.5
- github.com/decred/dcrd/crypto/ripemd160@v1.0.2
- github.com/decred/dcrd/dcrec/edwards/v2@v2.0.3
The full list of updated direct dependencies since the previous
blockchain/v4.1.0 release are as follows:
- github.com/decred/dcrd/chaincfg/chainhash@v1.0.4
- github.com/decred/dcrd/chaincfg/v3@v3.2.0
- github.com/decred/dcrd/dcrec@v1.0.1
- github.com/decred/dcrd/dcrec/secp256k1/v4@v4.2.0
- github.com/decred/dcrd/dcrutil/v4@v4.0.1
- github.com/decred/dcrd/txscript/v4@v4.1.0
- github.com/decred/dcrd/wire@v1.6.0
The full list of updated indirect dependencies since the previous
blockchain/v4.1.0 release are as follows:
- github.com/agl/ed25519@v0.0.0-20170116200512-5312a6153412
- github.com/dchest/siphash@v1.2.3
- github.com/decred/base58@v1.0.5
- github.com/decred/dcrd/crypto/blake256@v1.0.1
- github.com/decred/dcrd/crypto/ripemd160@v1.0.2
- github.com/decred/dcrd/dcrec/edwards/v2@v2.0.3
- github.com/decred/slog@v1.2.0
- github.com/klauspost/cpuid/v2@v2.0.9
- lukechampine.com/blake3@v1.2.1
Finally, all modules in the repository are tidied to ensure they are
updated to use the latest versions hoisted forward as a result.
This updates the blockchain/stake module dependencies, the copyright
year in the files modified since the previous release, and serves as a
base for blockchain/stake/v5.0.0.
The updated direct dependencies in this commit are as follows:
- github.com/decred/dcrd/chaincfg/chainhash@v1.0.4
- github.com/decred/dcrd/chaincfg@v3.2.0
- github.com/decred/dcrd/database/v3@v3.0.1
- github.com/decred/dcrd/dcrec/secp256k1/v4@v4.2.0
- github.com/decred/dcrd/dcrutil/v4@v4.0.1
- github.com/decred/dcrd/txscript/v4@v4.1.0
- github.com/decred/dcrd/wire@v1.6.0
The updated indirect dependencies in this commit are as follows:
- github.com/dchest/siphash@v1.2.3
- github.com/decred/base58@v1.0.5
- github.com/decred/dcrd/crypto/blake256@v1.0.1
- github.com/decred/dcrd/crypto/ripemd160 v1.0.2
- github.com/decred/dcrd/dcrec@v1.0.1
- github.com/decred/dcrd/dcrec/edwards/v2@v2.0.3
- github.com/klauspost/cpuid/v2@v2.0.9
- lukechampine.com/blake3@v1.2.1
The full list of updated direct dependencies since the previous
blockchain/stake/v4.0.0 release are the same as above.
The full list of updated indirect dependencies since the previous
blockchain/stake/v4.0.0 release are as follows:
- github.com/agl/ed25519@v0.0.0-20170116200512-5312a6153412
- github.com/dchest/siphash@v1.2.3
- github.com/decred/base58@v1.0.5
- github.com/decred/dcrd/crypto/blake256@v1.0.1
- github.com/decred/dcrd/crypto/ripemd160 v1.0.2
- github.com/decred/dcrd/dcrec@v1.0.1
- github.com/decred/dcrd/dcrec/edwards/v2@v2.0.3
- github.com/golang/snappy@v0.0.4
- github.com/klauspost/cpuid/v2@v2.0.9
- github.com/syndtr/goleveldb@v1.0.1-0.20210819022825-2ae1ddf74ef7
- lukechampine.com/blake3@v1.2.1
Finally, all modules in the repository are tidied to ensure they are
updated to use the latest versions hoisted forward as a result.
This updates the chaincfg module dependencies and serves as a base for
chaincfg/v3.2.0.
The updated direct dependencies in this commit are as follows:
- github.com/decred/dcrd/chaincfg/chainhash@v1.0.4
- github.com/decred/dcrd/wire@v1.6.0
The updated indirect dependencies in this commit are as follows:
- github.com/decred/dcrd/crypto/blake256@v1.0.1
- github.com/klauspost/cpuid/v2@v2.0.9
- lukechampine.com/blake3@v1.2.1
The full list of updated direct dependencies since the previous
chaincfg/v3.1.1 release are the same as above.
Finally, all modules in the repository are tidied to ensure they are
updated to use the latest versions hoisted forward as a result.
This updates the module dependencies, the copyright year in the files
modified since the previous release, and serves as a base for
blockchain/standalone/v2.2.0.
The updated direct dependencies in this commit are as follows:
- github.com/decred/dcrd/chaincfg/chainhash@1.0.4
- github.com/decred/dcrd/wire@v1.6.0
The updated indirect dependencies in this commit are as follows:
- github.com/decred/crypto/blake256@v1.0.1
- github.com/klauspost/cpuid/v2@v2.0.9
- lukechampine.com/blake3@v1.2.1
The full list of updated direct and indirect dependencies since the
previous blockchain/standalone/v2.1.0 release are the same as above.
Finally, all modules in the repository are tidied to ensure they are
updated to use the latest versions hoisted forward as a result.
This updates the wire module dependencies, the copyright year in the
files modified since the previous release, and serves as a base for
wire/v1.6.0.
The updated direct dependencies in this commit are as follows:
- github.com/decred/dcrd/chaincfg/chainhash@v1.0.4
The updated indirect dependencies in this commit are as follows:
- github.com/decred/dcrd/crypto/blake256@v1.0.1
The full list of updated direct dependencies since the previous
wire/v1.5.0 release are as follows:
- github.com/decred/dcrd/chaincfg/chainhash@v1.0.4
- lukechampine.com/blake3@v1.2.1
The full list of updated indirect dependencies since the previous
wire/v1.5.0 release are as follows:
- github.com/decred/dcrd/crypto/blake256 v1.0.1
- github.com/klauspost/cpuid/v2@v2.0.9
Finally, all modules in the repository are tidied to ensure they are
updated to use the latest versions hoisted forward as a result.
This adds support for generating blocks that require the new difficulty
algorithm defined in DCP0011 to the test chain generator.
It accomplishes this by introducing a new type and method, named
PowDifficultyAlgorithm and UsePowDiffAlgo, respectively, to the chain
generator along with logic to calculate the appropriate difficulty
accordingly. The method takes a parameter of the new type in order to
allow the caller selectively choose which difficulty algorithm to use.
This will allow future code to test all edge conditions around switching
the difficulty algorithm over to the new one defined in DCP0011.
This adds a new exported function to the blockchain/standalone module
named CalcASERTDiff which can be used to calculate a required target
difficulty using the Absolutely Scheduled Exponentially weighted Rising
Targets (ASERT) algorithm defined in DCP0011.
It also updates the documentation and includes comprehensive tests.
Note that this commit only makes the new function available and
does not implement any logic based on it.
This adds a new function to the blockchain/standalone module named
CheckProofOfWorkHash which can be used to independently verify that a
provided hash is less than a provided compact target difficulty without
also additionally checking that the compact difficulty is within a valid
range.
Since there is already CheckProofOfWorkRange to perform the latter, this
provides callers additional flexibility of performing the required
checks independently without being forced to re-check the range.
It also updates includes comprehensive tests.
This adds support for generating blocks solved by blake3 to the test
chain generator.
It accomplishes this by introducing a new type and method, named
PowHashAlgorithm and UsePowHashAlgo, respectively, to the chain
generator along with logic to change the hash function accordingly. The
method takes a parameter of the new type in order to allow the caller
selectively choose which hash function to use.
This will allow future code to test all edge conditions around switching
the hash function over to blake3 as defined in DCP0011.
This adds methods for computing the version 2 proof of work hash using
blake3 as defined by DCP0011 to the block and block header types.
Note that this commit only makes the new methods available and does not
implement any logic based on them.
This separates the notion of the block hash from the proof of work hash
so the proof of work hashing function can independently be changed
without affecting anything else that relies on the block hash as
generated by blake256r14.
This makes the functions the chain generator test code provides for
determining if blocks are solved and solving blocks methods on the
generate type itself so they are able to make decisions based on the
generator state in the future.
This adds two new exported functions to the subsidy cache in
blockchain/standalone to calculate the work and stake vote subsidies
according to a provided subsidy split variant flag along with tests to
ensure expected behavior.
The available variants are:
- The original subsidy split used at launch
- The modified subsidy split defined by DCP0010
- The modified subsidy split defined by DCP0012
It should be noted that the values for the modified split are hard coded
as opposed to using the subsidy cache params in order to avoid the need
for a major module bump that would be required if the subsidy params
interface were changed. The values are the same for all networks, so no
additional logic is necessary on a per-network basis.
This adds a new definition for the upcoming agenda vote to change the
subsidy split to 1% PoW, 89% PoS, and 10% Treasury defined in DCP0012.
It does not include any code to make decisions based on the status of
the agenda or bump block versions. It only adds the definition for the
agenda.
This adds a new definition for the upcoming agenda vote to change the
proof-of-work hashing function to BLAKE3 as defined in DCP0011.
It does not include any code to make decisions based on the status of
the agenda or bump block versions. It only adds the definition for the
agenda.
This modifies the entire repository to use the new formatting of doc
comments in the upcoming Go 1.19 release.
The primary motivating factors for this are:
- Builds check that files are formatted per gofmt and that will no
longer be true as of Go 1.19 without these changes
- Separating all the updates into a single commit ensures these
documentation only formatting changes do not clutter up diffs that
actually change code
For the most part, the changes are just the automated changes suggested
by the Go 1.19 version of gofmt, but there are also a few cases where
the comments were reworded a bit to play nicely with the new formatting
requirements.
For example, the new version of gofmt reformats and collapses nested
lists where as the existing version does not. Thus, instances of nested
lists have been changed to either eliminate them or use mixed markers
which produce expect results.
The moves the blockchain package from the blockchain module to an
internal package of the root module meaning that it is no longer a part
of the exported blockchain module. Nearly all of the logic it provides
is really for the internal implementation of dcrd itself and thus having
it exported module significantly increases the maintenance burden.
Note that as of this change the blockchain module still exists and
provides the chaingen and fullblocktests packages both or which are
useful and used by external consumers.
This is part of a continuing overall effort to reduce the total number
of exported packages and modules and eventually get to the point it will
be possible to follow semver for the root module.
Overview of the major changes:
- Move all go files from blockchain -> internal/blockchain
- Move testdata from blockchain -> internal/blockchain
- Remove doc.go in favor of the README.md since godoc now displays it
- Move README.md from blockchain -> internal/blockchain and update to
match the new reality
- Add a new README.md in the exported blockchain module that documents
it contains the remaining exported packages
- Update all import paths in the repository accordingly
- Run go mod tidy on all modules
This modifies the chain logic to create and store the individual
commitment hashes covered by the commitment root field of the header of
each block and also adds code to migrate the database to retroactively
create and store entries for all applicable historical blocks.
The upgrade can be interrupted at any point and future invocations will
resume from the point it was interrupted.
The following is a high level overview of the changes:
- Introduce a new database bucket to house the header commitments
- Add serialization code for use when storing and loading the individual
header commitment hashes
- Add full test coverage for new serialization code
- Store the commitment hashes in the db when connecting blocks
- Implement database migration code to retroactively store the
commitment hashes for all applicable historical blocks
- Bump the chain database version to 13
- Support resuming from interrupted upgrades
- Add a new func on the internal header commitment data struct that
returns the v1 header commitment hashes to consolidate the logic
- Update FilterByBlockHash to load the header commitments from the db
and generate the inclusion proof accordingly
This adds logic to avoid hitting the database when a compact filter that
can't possibly be available by first checking the block index to ensure
the requested block is both available and its data is known.
This adds a field to the header commitment data struct to store the hash
of the filter along with the filter so that it can be reused without
needing to recalculate the hash.
starting
The blockchain/fullblocktests package currently has a cyclic dependency
on blockchain since the tests directly return the error codes in
blockchain that are expected to be violated while blockchain itself
needs to import the package in order to run the tests.
This resolves that cyclic dependency by defining all of the errors the
fullblocktests produce in the package itself and then converting them to
the associated error in blockchain when running the tests and checking
for the expected error.
It also moves the code that runs the fullblocktests into the blockchain
itself instead of a separate blockchain_test to match all other tests
now that there is no longer a cyclic dependency that forced it to be
be separated.
While duplication of the errors in question is a little less convenient,
this approach ensures the blockchain package can be made internal in the
future while still providing the publicly-available fullblocktests
package for use both in testing the internal blockchain implementation
as well as integration tests with other implementations.
This adds a new exported function to the blockchain/standalone module
named CheckTransactionSanity which can be used to perform basic
transaction sanity checks.
It also updates the documentation and includes comprehensive tests.
The primary motivation for this change is that there are several
consumers that currently make use of this functionality and it lives in
the blockchain package which is slated to made internal and therefore
would otherwise become inaccessible to external consumers.
Another nice benefit of making this logic available via the
blockchain/standalone module is that it intentionally requires way less
dependencies which is ideal for consumers.
This removes support for the address index which also entails removal of
the --addrindex and --dropaddrindex flags as well as all related
indexing infrastructure.
The legacy index is now automatically dropped if it exists to ensure
clients that are upgrading are not left with unneeded data in their
databases.
This is part of the overall removal of the deprecated address index.
This deprecates the Checkpoints field of the chain parameters and
removes all manually-specified entries for all networks since manual
checkpoints no longer exist.
Historically, checkpoints have been manually specified and used both for
various optimizations and to protect against cheap DoS attacks by
rejecting forks deep in history. The primary motivation for manually
specifying the checkpoints was said optimizations, however, those
optimization portions have now been decoupled from checkpoints in favor
of other methods, so the only remaining use of checkpoints is the
aforementioned rejection of forks deep in history.
Thus, this reworks the old fork rejection logic to make it automatic
based on an ancestor that is two weeks worth of blocks behind the
hard-coded assumevalid block (clamped to the genesis block if necessary)
that is manually specified at each release as opposed to needing to
additionally manually specify checkpoints.
Note the distinction here between the hard-coded assumevalid block
specified at each release and the potentially overridden value specified
by a user via CLI configuration options. This is an important
distinction because old fork rejection affects consensus and thus must
not move around based on user configuration.
This approach means the user can still specify a more recent assume
valid hash or disable assume valid optimizations independently without
affecting the consensus logic while still removing the need to manually
specify additional checkpoints.
The following is a high level overview of the changes:
- Modifies the blockchain.Config struct as follows:
- Removes the LastestCheckpoint option
- Adds a AllowOldForks option
- Removes all code related to manually specified checkpoints and finding
candidates
- Removes the following errors since they are no longer used:
- ErrBadCheckpoint
- ErrCheckpointTimeTooOld
- Renames checkpointNode to rejectForksCheckpoint to make it clear that
is the only thing it applies to
- Adds logic to potentially reject forks deep in history as follows:
- Do not reject old forks if they are manually allowed or the
hard-coded assumevalid block is not specified for the network
- Automatically choose an ancestor that is two weeks worth of blocks
prior to the hard-coded assumevalid block (clamped to the genesis
block if necessary)
- Replaces --nocheckpoints CLI option with --allowoldforks
- Updates doc.go to match the changes to the CLI options
This adds a new field to the blockchain instance to store a cached
version of the number of expected blocks in two weeks to avoid repeated
calculation.
This retroactively fixes a bug that resulted in the fee limit not being
properly enforced for revocation transactions. The exploitation risk of
this was that in a split transaction, one party could intentionally
increase the fee paid to miners for another party.
It is no longer possible to exploit this on mainnet since the automatic
revocations agenda has activated, which enforces that the fee must be
zero for revocation transactions.
The fee limit for revocation transactions was never violated on mainnet
so this logic can be safely corrected without impacting consensus. This
has been validated by running a full sync with checkpoints and assume
valid disabled.
Currently, the p2p and rpcserver handlers that deal with compact filters
essentially duplicate the logic for dealing with the associated header
proof and are also required to understand the structure of the proof in
the form of knowing the associated index. This is not ideal since there
is no guarantee that a given index will always be the same through
consensus changes.
With those points in mind, this reworks the header proof logic slightly
to consolidate it by introducing a new HeaderProof struct to the
blockchain that houses a header commitment inclusion proof and
associated proof index and updating the FilterByBlockHash method to
return the header proof along with the filter and updates the p2p and
rpcserver handlers and associated interfaces and tests accordingly.
The result is that the aforementioned p2p and rpcserver handlers for
obtaining compact filters no longer need to understand anything about
the proofs. It is also useful for any future header commitments too
since the same logic will hold true for those instances as well.
This removes the following errors that are no longer used now that there
has been a new major module version bump:
- ErrCheckpointTimeTooOld
- ErrTooManyTransactions
- ErrInvalidTxOutputs
- ErrSSRtxPayees
This adds an exported method to the block index to retrieve the best
header node under the block index mutex and updates the various call
sites that do it manually to use the newly exported function instead.
This calls out the concurrency semantics for some exported query
functions to ensure callers are aware they are safe for concurrent
access to be more consistent with other exported methods in the package.
