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 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
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 modifies the transaction lookup code to use a set instead of a
slice (list). This allows the lookup to automatically prevent duplicate
requests to the database.
Previously, the code simply added every referenced transaction to a list
without checking for duplicates, which led to multiple requests against
the database for the same transaction. It also meant the request list
could grow quite large with all of the duplicates using far more memory
than required.
While the end result was accurate, operating that way is not as efficient
as only requesting unique transactions.
