Now that the ProcessBlock function returns whether or not the block was an
orphan, the code which requests the parent blocks from the peer that sent
them has been moved to directly after the call to it.
This makes the handling more obvious and has allowed removal of the
blockPeer map which was kept so the notification handler could identify
which peer to request the blocks from.
ok @jrick
The code was not resetting the counters when logging a message, so the
stats kept increasing rather than showing the number of items processed
since the last log message.
This has been resolved by copying the log function directly from btcd and
modifying it slightly to work with the importer.
blockImporter now has these new properties:
txProcessed - number of transactions processed by the importer
lastHeight - height of the last imported block
lastBlockTime - block time of the last imported block
lastLogTime - last timestamp of when a progress message was shown
the p/progress option in addblocks now indicates how often you want the progress message to appear
The addblock utility was originally written as a quick debug tool during
initial development to populate blocks into the database. However, now
that it has been designated as the standard way to import bootstrap.dat
(and indeed block data files in general), it was lacking a few features
such as properly checking against the chain rules and known good
checkpoints.
This commit reworks and improves the utility in several ways:
- Imported blocks are now checked against the chain rules including
checkpoints to ensure they match the known good chain
- The utility now properly shuts down after processing all blocks
- Attempting to import orphan blocks (blocks which build off a block you
don't yet have in the database) returns an error
- Blocks that are already known are now skipped instead of causing an
error which means you can stop and restart the import mid-way through
without issues or start it after you've already downloaded a
portion of the chain
- The block height is no longer assumed to start at 0 which means input
files that start later in the chain will work properly so long as you
already have the chain at least up to the point of the block just before
the first one in the input file
- Improved error handling and reporting
- How often the progress display is shown is now configurable
- Statistics about how many blocks were processed, imported, and already
known are now displayed after the input file has been fully processed
This resolves comments made in #60.
