This commit change the ProcessBlock function to accept a new type named
BehaviorFlags in place of the current fastAdd parameter.
This has been done to pave the way for adding more control over the checks
that are performed such as avoiding the proof of work checks which will be
in an upcoming commit. A bitmask was chosen because it will allow the
ProcessBlock API to remain a little more stable since new flag additions
that change the behavior are only likely to be used by new code because
adding flags does not change the existing behavior.
ok @jrick
This commit changes the RuleError type to a struct which consists of an
error code and human-readable description.
From a usage perspective, existing code should not break since type
asserting an error to a RuleError still works in the same manner. The
difference is the caller can now take that type asserted RuleError and
access the .ErrorCode field on it to programmatically identify the
specific rule that was violated.
ok @jrick
This commit refactors the code to make use of the btcnet package for
network-specific parameters instead of switching on the specific network.
For example, the percentage of the network that needs to run version 2
blocks is different between testnet and mainnet. Previously the code was
using a switch to choose these values. With this refactor, those
parameters are part of the network parameters provided when creating a new
chain instance.
Another example is checkpoints, which have been moved to btcnet so they
can be specified by the caller instead of hard coded into this package.
As a result, the checkpoints for the standard networks are now specified
in the btcnet package.
This makes it easier to add new networks such as a testnet4 should it
become needed. It also allows callers to define their own custom network
parameters without having to modify the code of the package to add new
switch cases for the custom network.
This commit exports a new variant of the existing internal
calcNextRequiredDifficulty function which calculates and returns the next
required difficulty for a block after the end of the current best chain
based on the difficulty retarget rules.
In order to support the exported function the internal one was slightly
modified to accept the block timestamp instead of an entire block since
the timestamp is all that is needed and the caller of the exported
function might next have a full block yet.
The name findLatestKnownCheckpoint is confusing and doesn't really convey
the fact the purpose of the function is to the find the checkpoint prior
to the current known block.
Therefore, rename the function to findPreviousCheckpoint for clarity.
Also, update some comments to follow suit.
This commit adds an additional check to the block acceptance rules which
prevents new blocks that fork the main chain before the previous known
good checkpoint. This prevents storage of new, otherwise valid, blocks
from building off of old blocks which are likely at a much easier
difficulty and therefore could be used to waste cache and disk space.
Note this is slightly different than the other existing check which
prevents blocks with a timestamp before the timestamp of the latest known
good checkpoint since that check effectively prevents old side chain
blocks that already existed (per the claimed timestamp).
ok drahn@
The recent addition of the fast add path to support headers first was not
running the block node index pruning code which removes unneeded block
nodes from memory. This resulted in higher memory usage than needed in
fast add mode.
This commit changes the node index creation to use block headers instead
of full blocks. This speeds up the initial node index generation since it
doesn't require loading a bunch of full blocks at startup.
This commit modifies local variables that are used for more convenient
access to a block's header to use pointers. This avoids copying the
header multiple times.
It is not necessary to do all of the transaction validation on
blocks if they have been confirmed to be in the block chain leading
up to the final checkpoint in a given blockschain.
This algorithm fetches block headers from the peer, then once it has
established the full blockchain connection, it requests blocks.
Any blocks before the final checkpoint pass true for fastAdd on
btcchain operation, which causes it to do less valiation on the block.
This commit implements pruning for the block nodes that form the memory
chain which are no longer needed. The validation of a block only requires
information from a set number of previous nodes. The initial code did not
prune old nodes as they were no longer needed, but the vast majority of
the infrastructure to support it was already in place as that was always
the goal. This commit finishes implementing the missing bits to make it
a reality.
Even though the code currently makes heavy use of nodes which will have
the appropriate height, blocks which did not come from the database will
not have a height set. As a result, this could possibly result in a
height of 0 being used when unintended. By setting the block height in
the block as soon as its known (regardless of the source), we can future
proof against bugs that would likely be hard to track down.
In addition to returning errors to the caller, log the error with a prefix
in a few key places that helps identify the origin for errors. In some
cases, the underlying error comes from a different subsystem such as the
SQL database driver and the error messages can be fairly generic.
This commit modifies the code to use params based on the active network
which paves the way for supporting the special rules and different genesis
blocks used by the test networks.
