This commit adds a test for checking known good block scripts in a block
are valid. As a part of this, it adds the infastructure needed to load a
saved transaction store from a file which contains all of the input
transactions needed.
It also contains some changes from running goimports as well as some other
cleanup.
This commit extends the same logic in the previous commit to the
comparison of offsets returned from the median time source in the tests.
In particular it modifies the tests to allow for the offsets to differ by
a second due to a boundary condition to prevent false positives.
The new median time tests perform a comparsion of the adjusted time
returned from the median time source to the expected value. However,
since time is always moving, it is possible the current time between the
call to the adjusted time function and the current time taken in the tests
for comparison just after the call differ by a second due to a boundary
condition. So, this commit modifies the tests to allow for this
condition.
This commit changes the internal testing mechanism from returning the
unexported timeSorter type directly to insted returning sort.Interface.
This has been done because the latest version of golint complains about
return unexported types.
This commit provides a new interface, MedianTimeSource, along with a
concrete implementation which allows improved accuracy of time by making
use of the median network time as calculated from multiple time samples.
The time samples are to be provided by callers and are intended to come
from remote clients.
The calculations performed in this implementation exactly mirror those in
Bitcoin Core because time calculations are part of the consensus rules and
hence need to match exactly.
This commit splits the two rule validation errors related to the timestamp
being too old into two distince errors rather than grouping them under the
same one. Thus there is now a new ErrCheckpointTimeTooNew in addition to
the existing ErrTimeTooNew error.
This allows the caller to detect the when a block is rejected due to a
time-related checkpoint failure whereas before the combined error did not.
This commit moves the ProcessBlock example to a test file so it integrates
nicely with Go's example tooling.
This allows the example output to be tested as a part of running the
normal Go tests to help ensure it doesn't get out of date with the code.
It is also nice to have the example in one place rather than repeating it
in doc.go and README.md.
Links and information about the example have been incldued in doc.go and
README.md in place of the example.
Since the underlying database driver can now return an error when looking
up if blocks and transactions exist, the HaveBlock function now includes
an error return to allow any underlying errors to be exposed.
This commit creates and exports a new constant, MaxTimeOffsetSeconds,
which is the maximum number of seconds a block timestamp is allowed to be
ahead of the current time.
Previously this value was hard coded into the consensus rule path, however
it is useful better to have it defined as a constant and exported so other
callers can access it.
No consensus rules have been changed with this commit.
This commit adds a new behavior flag, BFDryRun which allows the caller
to indicate all checks should be performed against the block as normal
except it will not modify any state. This is useful to test that a block
is valid without actually modifying the current chain or memory state.
This commit also adds a few additional checks which were elided before
since they are implicitly handled by btcwire. However, with the ability
to propose blocks which didn't necessarily come through the btcwire path,
these checks need to be enforced in the chain code as well.
As a part of adding the checks, three new error codes named
ErrBlockTooBig, ErrTooManyTransactions, and ErrTxTooBig have been
introduced.
Closes#5.
This commit modifies the error return type for errors during script
validation to use the RuleError so they are consistent with the rest of
the errors. This also helps the calling code differentiate blocks
rejected due to script parsing and validation errors as opposed to
internal issues such as inability to read from the disk.
To accomplish this, two new two new RuleErrors, ErrScriptMalformed and
ErrScriptValidation, have been added.
Also, the errors for script parsing issues and script validation errors
have been improved to include both transaction hashes and indexes involved
in the validation effort. Previously script parsing issues had almost no
additional information as to which transaction input/outputs the failing
script came from.
This commit adds a new behavior flag, BFNoPoWCheck which allows the caller
to indicate the check which ensures a block hashes to a value less than
required target should not be performed.
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 way that orphan blocks are identified by adding a
new boolean return value on ProcessBlock and removing the notification for
NTOrphanBlock.
This allows the calling code to identify orphan blocks immediately instead
of having to setup a seperate callback handler and implementing some type
of state tracking. This, in turn, allows cleaner code for handling them.
In addition, the tests have been updated for the new function signature
and also now check that each block is or is not an orphan as expected
which makes the tests more robust.
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
