This breaks the dependency on chaincfg.SigHashOptimization which is no
longer available in v2 of the chaincfg module. The constant is set to
false to ensure the same semantics are kept and an additional comment
has been added regarding the status.
This serves as the final release of version 1 of the txscript 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/txscript@v1.1.0
It also removes the txscript 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 betters CalcBlockSubsidy by allowing it to
calculate the requested block subsidy from a cached
subsidy entry regardless of its proximity to the
requested one.
Currently, block templates that provide work to PoW miners are generated
in response to them calling the getwork RPC. However, unlike in a pure
PoW system, in Decred, when a new block is connected, a new block
template extending that block can't be generated until the minimum
number of required votes for it has been received. This poses a
challenge for PoW miners because they are typically unaware of when
votes are received. Consequently, miners poll getwork waiting until
they see a new template generated when a new block is connected.
Since only a minimum of 3 votes is required to build a template and new
templates are only generated in response to the miners calling getwork,
as just described, miners often, unfortunately, end up receiving a
template that only has 3 votes and begin working on it. Worse, since
many new miners are not well versed in the intricacies of Decred voting,
they often aren't aware they really need to continue polling for new
votes and immediately switch over to the new template with more votes in
it in order to avoid receiving a reduced subsidy. This often results in
new miners producing blocks with 3 votes.
Moreover, blocks with less than all 5 votes are not only undesirable for
the PoW miners because they receive reduced subsidy, they're also
undesirable for PoS stakers since it means the votes that were not
included don't receive the reward despite having voted simply due to a
propagation delay.
Another issue with the existing approach is that since it takes a bit of
time to generate and validate templates, particularly as the number of
transactions they include rises, miners periodically requesting updated
work to include the latest transactions have to wait for the template to
be built when they call getwork once the existing cached template is
expired. This can result in undesirable delays for them.
In order to address the need to wait for templates to be built in that
case, there was recently some preliminary work that implemented a
background template generator which asynchronously generates templates
in response to events with the intention of allowing access to the
latest one without said random delays in the future.
However, that preliminary work did not address the issues around vote
propagation such as the tendency for miners to end up with the first
block template only containing the 3 fastest-propagating votes, nor did
it have robust handling for all potential corner cases and error
conditions.
Consequently, this overhauls the background block template generator to
add support for intelligent vote propagation handling, handle chain
reorganization to alternative blocks in the case the current tip is
unable to obtain enough votes, provide a subscription for a stream of
template updates, handle template generation errors, consider the
synchronization state as a part of determining if the chain is current,
track the reason for template updates, block current template retrieval
during operations that are in the process of making it stale, and
correct several corner cases.
It should be noted that this only implements the infrastructure and does
not switch getwork or the CPU miner over to use the background templates
yet. This will be done in future commits.
The following is a high-level overview of the semantics this implements:
- Generate new templates immediately when prior to stake validation
height since no votes are required
- Do not generate templates for intermediate blocks during a chain
reorganization
- Do not generate templates before the chain is considered synchronized
- Prefer to create templates with maximum votes through the use of a
timeout once the minimum votes have been received to provide the votes
an opportunity to propagate with a fallback for immediate generation
as soon as all votes are received
- In the case the timeout expires and a template is created with less
than the maximum number of votes, generate a new template
immediately upon receiving more votes for the block it extends
- In the event there are competing blocks at the current tip, prefer to
build a template on the first seen block so long as it receives the
minimum number of required votes within a few seconds
- Generate new templates immediately when a block is disconnected to
support future planned chain invalidation capabilities
- Generate new templates periodically when there are new regular transactions
to include
- Schedule retries in the rare event template generation fails
- Allow clients to subscribe for updates every time a new template is
successfully generated along with a reason why it was generated
- Provide direct access to the most-recently generated template
- Block while generating new templates that will make the current template
stale (e.g. new parent or new votes)
The following is a high-level overview of the changes:
- Initialize PRNG once instead of at every invocation
- Implement an asynchronous queue for all events to ensure normal chain
and vote processing is not blocked
- Provide ability to subscribe for all template updates over a single
channel to ensure none can indadvertently be missed as is possible with
the current design
- Always deliver existing template upon registration
- Drop templates if the receiver falls too far behind in the same way
tickers work
- Introduce tracking the reason for template updates so that it can
ultimately be presented to miners to allow them to make better
decisions about when to force their workers to switch
- Consider the current network sync state when checking if the chain is
current
- Introduce a regen handler state such as timeouts, blocks to monitor
for votes, and the block the next template should extend
- Add logic for selectively reacting to votes on the block the current
template is extending, the current tip, and alternate competing blocks
at the current tip using the aforementioned semantics
- Perform all template generation in separate goroutines with a
cancellable context
- Cancel any in progress templates that are being generated whenever
generating a new one
- Introduce blocking current template retrieval when a new template that
would cause the existing one to become stale is being generated
- Modify periodic regen handling to use a resettable timer for better
efficiency and more fine grained control
- Remove template pool as that is something that should be handled by
the code that is actually handing the templates out
- Rename and export the event notification funcs to make it clear
they're not internal functions and also make it easier to eventually
move the code into the mining package
- Expand and improve comments
- Store and return template generation errors
- Schedule retry in the case of failure
- Correct several cases that were not being handled correctly and some
undesirable behaviors such as block disconnects (as opposed to
reorgs), reorganization to side chains, and notifying with stale
templates
This updates the blockchain/stake dependencies and serves as a base for
blockchain/stake/v1.2.0.
The updated direct dependencies in this commit are as follows:
- github.com/decred/dcrd/database@v1.1.0
- github.com/decred/dcrd/dcrutil@v1.3.0
- github.com/decred/dcrd/txscript v1.1.0
The full list of updated direct dependencies since the previous
blockchain/stake/v1.1.0 release are as follows:
- github.com/decred/dcrd/chaincfg@v1.5.1
- github.com/decred/dcrd/database@v1.1.0
- github.com/decred/dcrd/dcrec@v1.0.0
- github.com/decred/dcrd/dcrec/edwards@v1.0.0
- github.com/decred/dcrd/dcrutil@v1.3.0
- github.com/decred/dcrd/txscript v1.1.0
This updates the txscript dependencies and serves as a base for
txscript/v1.1.0.
The updated direct dependencies in this commit are as follows:
- github.com/decred/dcrd/dcrec/secp256k1@v1.0.2
- github.com/decred/dcrd/dcrutil@v1.3.0
- golang.org/x/crypto@v0.0.0-20190611184440-5c40567a22f8
The full list of updated direct dependencies since the previous
txscripti/v1.0.2 release 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
- github.com/decred/dcrd/dcrec/secp256k1@v1.0.2
- github.com/decred/dcrd/dcrutil@v1.3.0
- golang.org/x/crypto@v0.0.0-20190611184440-5c40567a22f8
This updates the database module to use v2 of the chaincfg module and
bumps the root module to require dcrutil@v1.3.0 accordingly.
Since v2 of the chaincfg module is only used in the tests and standalone
utility, a major version bump of the database module is not required.
This refactors the consensus code which extracts the null data from the
coinbase from txscript.ExtractCoinbaseNullData so that it is performed
directly in the validation code where it more properly belongs.
The only reason the extraction was previously done in txscript is
because it was not possible to parse scripts outside of it, but that is
no longer the case now that txscript offers an exported tokenizer for
that purpose.
The extraction code is ever so slightly more efficient now that it no
longer needs to be as generic since it now has direct knowledge of the
conditions that need to be handled.
Great care was taken to ensure the semantics are not changed while
refactoring the code and no additional tests are added in this commit
because all of the conditions and code paths are covered by the tests
recently added to the full block tests.
While here, also perform some related code cleanup in the function and
improve the error messages .
Since the txscript.ExtractCoinbaseNullData is no longer necessary, this
deprecates the function and releated error code and constant so they can
be removed in the next major version of txscript.
Finally, since this relies on the script tokenizer which is not yet in a
released version of the txscript module, bump the requirement to include
an as yet unreleased version of txscript to ensure the next time the
blockchain module is released, it will require a newer version of
txscript to be released first.
This implements a mock address params struct that implements the new
interface and modifies the test code to make use of the mock params
instead of chaincfg. This completely decouples the tests, with the
exception of the example code, from chaincfg and therefore any updates
to it such as introducing new test networks will not require changes to
the tests.
This introduces a new interface named AddressParams and updates the
functions that currently take a pointer to a chaincfg.Params struct to
accept the interface instead.
This removes the tight coupling between the two packages at the API
boundary and allows callers to easily provide custom values without
having to create and register and entire chaincfg network as previously
required.
It also updates the tests to make use of the interface.
This modifies NewWIF to accept the required network magic bytes directly
versus a chaincfg.Params struct in order to remove the tight coupling
between the two packages at the API boundary and allows callers to
easily provide custom values without having to create and register and
entire chaincfg network as previously required.
It also removes the now unused error return and updates the tests
accordingly.
This modifies DecodeWIF to accept the required network parameters for
the provided encoded WIF string and introduces a new error to indicate
the provided WIF string is for the wrong network.
This means that DecodeWIF will now return ErrWrongWIFNetwork if the WIF
string being decoded is not for the provided network. This differs from
the previous behavior that would accept arbirtary network bytes and
relied on globally-registered networks in chaincfg to determine which
network the string was for followed by requiring the caller to check if
the WIF was for the specific network it desired upon return.
Finally, it removes the no longer necessary IsForNet method and updates
the documentation accordingly.
This modifies the concrete address implementations to only store the
necessary individual parameters instead of the entire params struct to
further decouple from chaincfg.
This removes the DSA method from the Address interface in favor of only
defining it on the specific concrete address implementations to which it
applies. It also modifies the remaining instances to remove the network
parameters since they are already available on the type.
Finnaly, it updates the example code accordingly.
This removes the no longer necessary IsForNet method from the Address
interface and all concrete address implementations.
It also updates the tests accordingly.
This modifies DecodeAddress to accept the required network parameters
for the provided encoded address and return an error when the provided
address is for the wrong network.
This means that DecodeAddress will now return ErrUnknownAddressType if
the address being decoded is not for the provided network. This differs
from the previous behavior relied on globally-registered networks in
chaincfg to determine which network the encoded address was for followed
by requiring the caller to check if the address was for the specific
network it desired upon return.
It also updates the tests and example accordingly.
This adds a tested example for address decoding and removes the previous
non-functioning version of it from the pacakge documentation. The
previous example appers to have been missed when porting the code and
was no longer correct for Decred.
This serves as the final release of version 1 of the dcrutil 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/dcrutil@v1.3.0
It also removes the dcrutil 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 two new consensus tests to the full block tests for the
coinbase nulldata height commitment. The first new test ensures
coinbase transactions with the wrong script version are rejected and the
second test ensures data pushes that exceed the maximum allowed number
of bytes for the coinbase nulldata push are rejected.
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.
