This modifies the adaptor that the RPC server uses for transaction
submission to process the transaction directly instead of piping through
the netsync package. There is no longer any reason to incur the extra
overhead since the mempool is concurrent safe the initial reasons for
piping it through netsync no longer apply. This can be seen by noting
that the net sync manager doesn't do anything except call the mempool
method.
This updates the wire error types to leverage go 1.13 errors.Is/As
functionality as well as confirm to the error infrastructure best
practices outlined in #2181.
This adds new functions for generating and verifying inclusion proofs
along with associated tests.
The functions are direct ports of the functions of the same names from
blockchain/standalone.
It also updates the documentation.
This implements functions to calculate a Merkle tree root for a given
set of leaves along with associated tests.
The functions are direct ports of the functions of the same names from
blockchain/standalone.
Note that this does not include the other functions in
blockchain/standalone related to merkle root calculations from
transaction trees since the primitives package does not yet implement
a transaction type. Those will be implemented later after a transaction
type is introduced.
The following is a comparison between the existing implementation in the
blockchain/standalone module with big integers (old) and the new
implementation (new) averaging 10 runs each:
name old time/op new time/op delta
-----------------------------------------------------------------------------
CheckProofOfWork 314ns ± 1% 43ns ± 0% -86.42% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
------------------------------------------------------------------------------
CheckProofOfWork 5.00 ± 0% 0.00 -100.00% (p=0.000 n=10+10)
This implements functions to verify a block hash is less than the target
difficulty represented by given difficulty bits and that said difficulty
is in min/max range per a proof-of-work limit along with associated
tests.
It also introduces error infrastructure consistent with the rest of the
code.
The functions are the semantic equivalent of the functions of the same
names from blockchain/standalone updated to use and accept the new
uint256 type instead of stdlib big integers.
The following is a comparison between the existing implementation in the
blockchain/standalone module with big integers (old) and the new
implementation (new) averaging 10 runs each:
name old time/op new time/op delta
--------------------------------------------------------------------------
HashToUint256 127ns ± 3% 3ns ± 1% -97.68% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
---------------------------------------------------------------------------
HashToUint256 2.00 ± 0% 0.00 -100.00% (p=0.000 n=10+10)
This implements a function to convert a hash to the new uint256 type
along with associated tests.
The function is the semantic equivalent of HashToBig from
blockchain/standalone updated to use and return the new uint256 type
instead of stdlib big integers.
The following is a comparison between the existing implementation in the
blockchain/standalone module with big integers (old) and the new
implementation (new) averaging 10 runs each:
name old time/op new time/op delta
---------------------------------------------------------------------
CalcWork 638ns ± 1% 59ns ± 1% -90.78% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
----------------------------------------------------------------------
CalcWork 7.00 ± 0% 0.00 -100.00% (p=0.000 n=10+10)
This implements code for calculating a uint256 work value from
difficulty bits along with associated tests.
The function is the semantic equivalent of CalcWork from
blockchain/standalone updated to use and return the new uint256 type
instead of stdlib big integers.
Note that the original calculation involves a dividend of 2^256 which is
not directly representable by a uint256, so this implementation retains
the same semantics by transforming the calculation as described in
detail by the comments.
The following is a comparison between the existing implementations in
the blockchain/standalone module with big integers (old) and the new
implementations (new) averaging 10 runs each:
name old time/op new time/op delta
------------------------------------------------------------------------------
DiffBitsToUint256 158ns ± 1% 4ns ± 1% -97.35% (p=0.000 n=10+10)
Uint256ToDiffBits 151ns ± 2% 8ns ± 4% -94.82% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
-------------------------------------------------------------------------------
DiffBitsToUint256 3.00 ± 0% 0.00 -100.00% (p=0.000 n=10+10)
Uint256ToDiffBits 2.00 ± 0% 0.00 -100.00% (p=0.000 n=10+10)
This implements code for converting between difficulty bits and the new
uint256 type along with associated tests.
The functions are the semantic equivalents of CompactToBig and
BigToCompact from blockchain/standalone updated to use the new uint256
type instead of stdlib big integers and renamed to DiffBitsToUint256 and
Uint256ToDiffBits, respectively.
The primary motivation for renaming the functions to specifically call
out difficulty bits instead of the shorter "Compact" is to prevent
future ambiguity with Satoshi-style variable length compact integers
that will ultimately also be available from the package.
Note that for legacy reasons, even though the difficulty bits encoding
is only used in Decred to encode unsigned 256-bit integers which
represent difficulty targets, the encoding is capable of representing
negative numbers as well as numbers much larger than the maximum value
of an unsigned 256-bit integer. Therefore, in order to enable proper
error detection and stay consistent with legacy code, DiffBitsToUint256
returns additional flags to indicate the aforementioned conditions.
This adds additional logic to the CPU miner's discrete mining process to
detect when the block that it most recently submitted is no longer valid
to prevent a hang in that case while still providing the desired
behavior that waits for updated templates when invoked in rapid
succession.
Currently, the next blocks that need to be downloaded are determined in
blockchain and returned via a new slice by using a lookahead method
along with allowing the caller to specify a map of blocks to exclude for
the blocks that have already been requested.
While this method works fine for a single peer, it does not lend itself
well to parallel block downloads. Further, the lookahead mechanism
imposes an artificial limit on the number of outstanding requests which
is not something that it should be concerned with and it also is not
particularly efficient since it results in new allocations every time it
is queried.
Consequently, this reworks the logic such that the function in
blockchain accepts a backing array from the caller that is populated via
an allocation-free windowing mechanism and the sync manager now
maintains that array along with additional logic to detect when to
update it. Not only is the new approach quite a bit more efficient, it
removes the artificial limits on outstanding requests so they can be
tuned as needed by the sync manager.
This modifies the internal messaging for initial state requests to use
slices of contiguous block hashes instead of slices of pointers.
Contiguous slices produce much less heap objects that the GC needs to
scan and are better for cache locality.
This modifies the header progress logging function to be concurrent safe
and modifies some comments to call out that the various functions are
concurrent safe.
This isn't strictly necessary with the current code because the function
is only ever called from a single goroutine in the network sync manager,
but the logger is intended to be concurrent safe and future code will
likely make use of it from multiple goroutines.
This updates the latest block version for the upcoming hard fork vote
for DCP0007, DCP0008, and DCP0009 in order to reject old block versions
once a super majority of the network has upgraded.
This updates the gcs module dependencies, the copyright year in the
files modified since the previous release, and serves as a base for
gcs/v3.0.0.
The updated direct dependencies in this commit are as follows:
- github.com/decred/dcrd/blockchain/stake/v4@v4.0.0
The full list of updated direct dependencies since the previous
gcs/v2.1.0 release are as follows:
- github.com/dchest/siphash@v1.2.2
- github.com/decred/dcrd/blockchain/stake/v4@v4.0.0
- github.com/decred/dcrd/chaincfg/chainhash@v1.0.3
- github.com/decred/dcrd/txscript/v4@v4.0.0
- github.com/decred/dcrd/wire@v1.5.0
Finally, all modules in the repository that depend on the module 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/v4.0.0.
The updated direct dependencies in this commit are as follows:
- github.com/decred/dcrd/database/v3@v3.0.0
- github.com/decred/dcrd/dcrutil/v4@v4.0.0
The full list of updated direct dependencies since the previous
blockchain/stake/v3.0.0 release are as follows:
- github.com/decred/dcrd/chaincfg/chainhash@v1.0.3
- github.com/decred/dcrd/chaincfg/v3@v3.1.0
- github.com/decred/dcrd/database/v3@v3.0.0
- github.com/decred/dcrd/dcrec/secp256k1/v4 v4.0.1
- github.com/decred/dcrd/dcrutil/v4@v4.0.0
- github.com/decred/dcrd/txscript/v4@v4.0.0
- github.com/decred/dcrd/wire@v1.5.0
- github.com/decred/slog@v1.2.0
The following direct dependencies are no longer required as compared to
the previous release:
- github.com/decred/dcrd/dcrec
Finally, all modules in the repository that depend on the module are
tidied to ensure they are updated to use the latest versions hoisted
forward as a result.
This renames IsStakeSubmissionTxOut to IsStakeCommitmentTxOut to help
avoid ambiguity with the actual "stakesubmission" output which is only
the 0th output of a stake submission transaction.
This updates the database module dependencies, the copyright year in the
files modified since the previous release, and serves as a base for
database/v3.0.0.
The updated direct dependencies in this commit are as follows:
- github.com/decred/dcrd/dcrutil/v4@v4.0.0
- github.com/syndtr/goleveldb@v1.0.1-0.20210819022825-2ae1ddf74ef7
The full list of updated direct dependencies since the previous
database/v2.0.2 release are as follows:
- github.com/decred/dcrd/chaincfg/chainhash@v1.0.3
- github.com/decred/dcrd/chaincfg/v3@v3.1.0
- github.com/decred/dcrd/dcrutil/v4@v4.0.0
- github.com/decred/dcrd/wire@v1.5.0
- github.com/decred/slog@v1.2.0
- github.com/syndtr/goleveldb@v1.0.1-0.20210819022825-2ae1ddf74ef7
Finally, all modules in the repository that depend on the module are
tidied to ensure they are updated to use the latest versions hoisted
forward as a result.
This updates the peer module dependencies, the copyright year in the
files modified since the previous release, and serves as a base for
peer/v3.0.0.
The updated direct dependencies in this commit are as follows:
- github.com/decred/dcrd/txscript/v4@v4.0.0
The full list of updated direct dependencies since the previous
peer/v2.2.0 release are as follows:
- github.com/decred/dcrd/chaincfg/chainhash@v1.0.3
- github.com/decred/dcrd/txscript/v4@v4.0.0
- github.com/decred/dcrd/wire@v1.5.0
- github.com/decred/slog@v1.2.0
Finally, all modules in the repository that depend on the module are
tidied to ensure they are updated to use the latest versions hoisted
forward as a result.
This adds an example of calculating the result of dividing a max
unsigned 256-bit integer by a max unsigned 128-bit integer and
outputting that result in hex with leading zeros.
This is part of a series of commits to fully implement the uint256
package.
The following shows the typical performance of converting a standard
library big integer that has already been reduced modulo 2^256 to a
uint256:
Uint256SetBig 26944130 44.45 ns/op 0 B/op 0 allocs/op
This is part of a series of commits to fully implement the uint256
package.
This adds a convenience method for converting a standard library big
integer to a uint256 (modulo 2^256) along with associated tests to
ensure proper functionality.
This is part of a series of commits to fully implement the uint256
package.
The following shows the typical performance of converting a uint256 to a
standard library big integer using one that already exists:
Uint256PutBig 43651442 27.29 ns/op 0 B/op 0 allocs/op
This is part of a series of commits to fully implement the uint256
package.
This adds convenience methods for converting a uint256 to a standard
library big integer along with associated tests to ensure proper
functionality.
It includes a method that allows an existing big integer to be reused
thereby potentially saving allocations as well as a method that returns
a new big integer. The latter is often more convenient to use, but is
also virtually guaranteed to cause an allocation.
This is part of a series of commits to fully implement the uint256
package.
This adds full support for formatting a uint256 along with associated
tests to ensure proper functionality.
It includes a fmt.Formatter that supports the full suite of the fmt
package format flags for integral types, a fmt.Stringer, and a separate
Text method that accepts an output base directly and produces the
relevant output with fewer allocations than using the standard fmt
methods.
This is part of a series of commits to fully implement the uint256
package.
The following is a comparison between stdlib big integers (old) and the
specialized type (new) averaging 10 runs each:
name old time/op new time/op delta
---------------------------------------------------------------------
bits_64 2.24ns ± 1% 1.94ns ± 3% -13.04% (p=0.000 n=10+10)
bits_128 2.25ns ± 2% 1.96ns ± 2% -13.17% (p=0.000 n=10+10)
bits_192 2.25ns ± 1% 1.60ns ± 1% -28.65% (p=0.000 n=10+10)
bits_255 2.26ns ± 2% 1.61ns ± 1% -29.04% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
------------------------------------------------------------
bits_64 0.00 0.00 ~ (all equal)
bits_128 0.00 0.00 ~ (all equal)
bits_192 0.00 0.00 ~ (all equal)
bits_255 0.00 0.00 ~ (all equal)
This is part of a series of commits to fully implement the uint256
package.
This adds support for determining the minimum number of bits required to
represent the current value of a uint256 along with associated tests to
ensure proper functionality.
This is part of a series of commits to fully implement the uint256
package.
The following is a comparison between stdlib big integers (old) and the
specialized type (new) averaging 10 runs each:
name old time/op new time/op delta
-----------------------------------------------------------------
Xor 17.9ns ± 5% 3.4ns ± 6% -80.91% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
--------------------------------------------------------
Xor 0.00 0.00 ~ (all equal)
This is part of a series of commits to fully implement the uint256
package.
This adds support to compute the bitwise xor of two uint256s along with
associated tests to ensure proper functionality.
This is part of a series of commits to fully implement the uint256
package.
The following is a comparison between stdlib big integers (old) and the
specialized type (new) averaging 10 runs each:
name old time/op new time/op delta
-----------------------------------------------------------------
And 16.7ns ± 5% 3.4ns ± 6% -79.93% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
--------------------------------------------------------
And 0.00 0.00 ~ (all equal)
This is part of a series of commits to fully implement the uint256
package.
This adds support to compute the bitwise and of two uint256s along with
associated tests to ensure proper functionality.
This is part of a series of commits to fully implement the uint256
package.
The following is a comparison between stdlib big integers (old) and the
specialized type (new) averaging 10 runs each:
name old time/op new time/op delta
-----------------------------------------------------------------
Or 17.9ns ± 5% 3.4ns ± 6% -80.94% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
--------------------------------------------------------
Or 0.00 0.00 ~ (all equal)
This is part of a series of commits to fully implement the uint256
package.
This adds support to compute the bitwise or of two uint256s along with
associated tests to ensure proper functionality.
This is part of a series of commits to fully implement the uint256
package.
