This adds infrastructure to track missed votes and automatically
generate revocations for them along with a new assertion helper named
AssertTipNumRevocations which, as it name suggests, allows the caller to
assert the header commits to the specified number of revocations.
This will be useful for porting the rest of the block validation tests
to the fullblocktests framework.
Currently, the stake difficulty estimation function for algorithm
defined in DCP0001 only works with mainnet due to a limitation of only
working when the interval size is less than or equal to the ticket
maturity.
This generalizes the function to work with all values of interval size
and ticket maturity and adds a full suite of tests using the testnet
parameters to ensure proper functionality.
Of particular note is the case when the current height is before the
ticket maturity floor since that means some of the tickets being
estimated will mature during the interval and that there can be no
non-estimated immature tickets.
This also implies that, unlike when the ticket maturity is greater than
or equal to the interval size, the estimate may not exactly match the
real final value when given the exact same number of tickets to estimate
as real purchased tickets in the remainder of the interval depending on
whether or not the current height is before the ticket maturity floor.
This is the case because the number of real tickets that end up being
purchased before the maturity floor may not match the estimated
assumption of max tickets per block.
This implements the getchaintips JSON-RPC and updates the associated
JSON-RPC API documentation accordingly.
It should be noted that until the entire block index is loaded into
memory, the chain tips tracking currently only works with tips that have
been seen since the daemon was started.
This modifies the startup logic to cache the tip and parent blocks in
the main chain block cache at initialization time which is desirable
because all of the transactions which come in to the mempool need access
to the these blocks to construct their utxo views due to the potential
for invalidation of the outputs in the previous block through voting.
Without caching them, the blocks end up being loaded from the database
again every time a new transaction enters the mempool until the blocks
eventually get cached when a new block is connected which is majorly
inefficient.
This PR moves the following block validation rule tests to
fullblocktests.
- `ErrBlockOneOutputs`
- Create a premine block with one premine output removed.
- Create a premine block with a bad spend script.
- Create a premine block with an incorrect pay to amount.
- `ErrVotesMismatch`
- Create block with a header that commits to more votes than the block
actually contains.
- `ErrIncongruentVotebit`
- Attempt to add block with incorrect votebits set.
- 4x Voters, 2x Nay 2x Yea, but block header says Yea
- 3x Voters, 2x Nay 1x Yea, but block header says Yea
- 3x Voters, 1x Nay 2x Yea, but block header says Nay
- `ErrSStxCommitment`
- Attempt to add block with a bad ticket purchase commitment.
- `ErrSSGenPayeeOuts`
- Attempt to add a block with a bad vote payee output.
- Attempt to add a block with an incorrect vote payee output amount.
- `ErrBadCoinbaseFraudProof`
- Create block with an invalid coinbase transaction.
- `ErrFraudBlockIndex`
- Create block with an invalid transaction block height.
- `ErrFraudAmountIn`
- Create block with an invalid transaction amount.
- `ErrExpiredTx`
- Create block with an expired transaction.
- `ErrBadBlockHeight`
- Create block with an invalid block height.
- `ErrPoolSize`
- Create block with an invalid ticket pool size.
- `ErrInvalidFinalState`
- Create block with an invalid final state.
- `ErrScriptMalformed`
- Create block with a malformed spend script.
This simplifies the recently added chain tip tracking by allowing the
block index to handle it when a node is added to it.
This is possible since the block index does not support nodes that do
not connect to an existing node (with the exception of the genesis
block), and thus all new nodes are either extending an existing chain or
are on a side chain, but in either case, are a new chain tip. In the
case the node is extending a chain, the parent is no longer a tip so it
can be removed.
This removes the unused threshold state serialization code and
associated tests that appear to be left over from initial development
but were never needed due to other caches used.
This simplifies, optimizes, and improves the robustness of the voter
version calculation as follows:
- Modifies calcVoterVersion to make use of the AncestorNode function to directly
iterate back to the end of the prevoius stake version interval instead
of manually adjusting and calling findStakeVersionPriorNode.
- Adds an optimization to skip any attempts to count votes before stake
validation height since there can't possibly be any votes prior to
that point.
- Modifies calcVoterVersionInterval to explicitly assert the assumptions
at the beginning of the function to prevent invalid behavior instead
of only commenting them and then indirectly asserting it via the total
number of found votes.
This modifies the TipGeneration function to use the new chain tip
functionality in order to determine the entire generation of blocks
stemming from the current tip as opposed to the children.
This adds logic to keep track of all known chain tips. Currently, this
will only work with chain tips that have been seen since the daemon was
loaded, however, when moving to the full block index in memory, it will
pick end up tracking all chain tips in the block index.
Also, note that nothing makes use of the functionality as of this commit
yet. It will be useful in the future to allow things such as removal of
the more expensive per-node children tracking, mining code improvements,
and enhanced fork-related interrogation ability.
This replaces the GetGeneration function which allowed getting the
entire generation (all children stemming from the same parent) of an
arbitrary bock with TipGeneration which only returns the same
information for the tip block.
This is being done because the function is only used for mining purposes
to get the generation of the current tip. The code is simplified by
reducing its scope to its actual purpose as an initial benefit. It also
provides much better optimization opportunities later.
This adds a new exported function named IsSolved which allows consumers
of chaingen to easily check if a block is solved according to the target
difficulty specified by the bits in its header.
This improves the test which checks for votes on the wrong block by
creating a new commitment script and testing 3 different scenarios:
- Ticket that commits to the parent of the correct block to ensure that
the code under test is not just failing due to a hash that doesn't
exist
- Ticket that commits to the correct block hash and wrong block height
- Ticket the commits to the correct block height and wrong block hash
Putting the test code in the same package makes it easier for forks
since they don't have to change the import paths as much and it also
gets rid of the need for internal_test.go to bridge.
This copies the minor bits of code referenced by chaingen from
blockchain to break the dependency on the blockchain package.
The intent of chaingen is that it is totally separate code from
the blockchain package so that accidental consensus changes are much
more difficult to slip through.
This modifies the chaingen test harness to error when a duplicate block
name is provided to NextBlock to help prevent misuse.
It also orrects a couple of comment typos.
This removes the calcStakeVersionByNode in favor of just using
calcStakeVersion directly since the latter already takes the node and
the former is a simple pass through with no additional handling.
This switches block template proposal checks over to use
CheckConnectBlock now that all of the core checks needed for block
templates is included there, and, more importantly, removes the the
BFDryRun flag since it was only used to test block template proposals
and it is much simpler to allow the main chain processing paths to run
without the complication of selectively processing code for dry run
behavior.
This replaces and improves the tests for the ForceHeadReorganization
function with new tests based on the dynamic chaingen infrastructure
versus uses static test data that gets out of date as data structures
change and is much more difficult to update.
It also removes the now unused static reorgto180.bz2 test data.
This removes a couple of the reorganization tests that rely on static
test data since that logic is much better handled by the dynamic full
block tests and thus is no longer needed.
This modifies the newly added block index serialization code to use a
separate structure as opposed to working with block nodes directly.
This approach is more desirable because it provides better separation
and more robust code against changes to the block node structure itself
and it avoids complications dealing with non-serialized fields such as
parent and child pointers.
This modifies the forceHeadReorganization function to lookup the child
node directly from the index instead of looping through all of the
children looking for it.
This adds code to migrate the existing block index in ffldb to the new
format managed by the blockchain package and updates the code to use the
new infrastructure.
This adds a new field to the block node struct named status that
consists of bit flags for keeping tracking of the validation state of
each block. The status is only stored in memory as of this commit, but
it will be stored as a part of the block index in the upcoming block
index migration code.
Since the field will be updated after node creation, this also
introduces some new functions for interacting with the status field in a
concurrent-safe fashion.
This is largely based on upstream commits 2492af0 and fb0d13c; however,
it does not include some of the logic in the reorganization paths those
commits include as that approach doesn't match the intended direction
this package is moving towards.
This adds infrastructure necessary for blockchain to independently
manage and persist a full block index in a bucket. Note that the
new infrastructure is not used yet as it will be integrated in future
commits after migrating existing databases has been done.
The purpose of this infrastructure is to significantly speed up startup
time which currently has to load a bunch of the most recent blocks in
order to rebuild the stake state and also to pave the way towards being
able to have the full block index in memory allows for a lot of
optimizations and greatly simplified code.
This also includes a full suite of tests to ensure proper serialization
and deserialization functionality.
This simplifies and consolidates the logic for adding and removing nodes
to and from the block index by moving the initial add into
maybeAcceptBlock just after the node is created, adding the child
connection logic to the AddNode function, and introducing a RemoveNode
function that is called in dry run mode which undoes the aforementioned
changes.
In addition to being simpler logic to follow, it helps make it clear
that all blocks which are written to the database end up with a block
index entry, even if they ultimately fail to connect.
This adds missing error entries to the tests and also adds an additional
check to ensure that all possibilities are tested to prevent drift in the
future.
This provides a function to calculate the lottery initialization vector
for a node on demand versus calculating it at node creation time and
storing the result.
This is being done because it saves an additional 32 bytes in the block
node structure and the ultimate goal is to move towards having all block
nodes in memory to greatly simplify and optimize the code. Since there
will be a lot of nodes in memory, these extra bytes can add up to
significant savings.
This replaces the ErrDoubleSpend and ErrMissingTx error codes with a
single error code named ErrMissingTxOut and updates the relevant errors
and expected test results accordingly.
Once upon a time, the code relied on a transaction index, so it was able
to definitively differentiate between a transaction output that
legitimately did not exist and one that had already been spent.
However, since the code now uses a pruned utxoset, it is no longer
possible to reliably differentiate since once all outputs of a
transaction are spent, it is removed from the utxoset completely.
Consequently, a missing transaction could be either because the
transaction never existed or because it is fully spent.
Also, while here, consistently use the LookupEntry function on the
UtxoView instead of directly accessing the internal map as intended.
This modifies the newBlockNode function to accept the parent as an
argument to automatically connect the newly created node. When it is
not nil, the work sum will automatically be summed and the parent of the
new node will be set accordingly.
This simplifies the block node construction a bit and allows some
redundant code to be removed. It also paves the way for easier simpler
full block index construction in the future.
This separates the logic for populating the stake information in a block
node from the construction of the node in order to better delineate the
difference between the two and to pave the way for that information to
be stored separately in the database versus needing to load full blocks
to retrieve it.
This modifies the code in maybeAcceptBlock to return an error if there
is no previous entry in the block index for a given block indicating it
is either an orphan or the genesis block.
The function should never be called in either circumstance since the
genesis block is valid by definition and orphans are handled prior to
calling the function.
This removes the legacy version details from the database to ensure that
loading older versions of the software after the database has been
upgraded fails as desired.
This is important because otherwise, the database could actually be
using a new version that has been upgraded via the new scheme, but old
software would still see this old information and believe the database
was still on that older version.
This propagates the interrupt channel through to blockchain and the
indexers so that it is possible to interrupt long-running operations
such as catching up indexes.
This modifies the database upgrade logic to avoid needing the chain and
moves it earlier in the initialization process just after the initial
database creation (if needed), but prior the final struct instance
population from the database.
It is much simpler logic to have an already upgraded database prior to
populating the initial chain state so all of the initial setup happens
in one place.
This modifies the database versioning to use separate keys within the
version bucket for each component in order to simplify upgrade logic.
Having a single key for the various versions of the database components
makes it difficult to use because the version isn't known until the data
is read, however, modifying the format necessarily means the version is
needed before that point to know which format to read.
While here, it uses a uint64 to store the date instead of a uint32 so
the timestamp continues to work past 2106.
Also, it removes the upgrade started logic since it should be possible
to stop in the middle of an upgrade and resume later. Forcing a
completely new database to be created because an upgrade was stopped in
the middle is not ideal.
