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
Both the script tests (positive and negative) and tx texts (ditto) are
present. Some of the tx tests in the negative section have been
replaced by a comment line explaining why that test is elided, to add in
diffing. The reasons were always that they test things handled by other
parts of the btcd stack (normally chain). For example MAX_MONEY, number
of outputs, coinbase sizes etc.
Much of the inital test logic from @dajohi using hand transcribed tables
for selected tests. The json parsers, script format parser and a lot of
cleaning up/bugfixing from your truly. @davecgh had some input too.
This commit corrects the number of expected inputs for a multi-sig script
to include the additional item that is popped from the stack due to the
OP_CHECKMULTISIG consensus bug (which is required and properly performed).
Note this issue did NOT affect the consensus critical code and hence would
not cause a chain fork. It did however, cause standard p2sh multisig txns
to be rejected from the mempool as nonstandard.
The tx rejected as non-standard which prompted this was spotted by
@mbelshe on IRC.
ok @owainga
This commit removes the word "only" from the non-standard transaction
error message when the number of items on the stack does not match the
number of expected items.
This was suggested by @mbelshe.
This commit updates the install command under the Installation section in
README.md to include all subdirectories thereby including the utilities
such as addblock and btcctl.
This commit makes a slight variant of the existing calcPastMedianTime
function available to external callers. The new exported version
calculates the past median time from the end of the current main chain
versus an arbitrary block node.
Found by tests dhill is working on. We checked that ifs were closed at the end
of execution but not at script switching time, we now move this to just after
finishing a single script.
Rather than having a separate query channel for the block manager, use the
same channel so the block handler acts as a pure FIFO queue. This
prevents possible starvation of query related messages.
ok @owainga
This commit makes a slight variant of the existing checkConnectBlock
function available to external callers. The new exported version checks
if the passed block will connect to the end of the current main chain.
In order to support this, a few other small modifications have been made
to the initial index generation and the existing checkConnectBlock since
it previously made some assumptions about the state of genesis block which
can no longer be assumed due accepting blocks from callers directly.
Also, add a quick test to ensure the new function fails when checking if
the genesis block will connect again when it's already inserted.
This change modifies the RPC server's notifiation manager from a
struct with requests, protected by a mutux, to two goroutines. The
first maintains a queue of all notifications and control requests
(registering/unregistering notifications), while the second reads from
the queue and processes notifications and requests one at a time.
Previously, to prevent slowing down block and mempool processing, each
notification would be handled by spawning a new goroutine. This lead
to cases where notifications would end up being sent to clients in a
different order than they were created. Adding a queue keeps the
order of notifications originating from the same goroutine, while also
not slowing down processing while waiting for notifications to be
processed and sent.
ok @davecgh
