This commit cleans up and moves a couple of comments in the recent pull
request which implements a rebroadcast handler (#114) in order to avoid
discussing internal state in the exported function comment.
How a function actually accomplishes the stated functionality is not
something that a caller is concerned with. The details about the internal
state are better handled with comments inside the function body.
This commit implements a rebroadcast handler which deals with
rebroadcasting inventory at a random time interval between 0 and 30
minutes. It then uses the new rebroadcast logic to ensure transactions
which were submitted via the sendrawtransaction RPC are rebroadcast until
they make it into a block.
Closes#99.
Rather than using the deprecated TxShas function on a btcutil.Block,
convert handleGetBlock to use the newer preferred method of ranging over
the Transactions to obtain the cached hash of each transaction.
This is a little more efficient since it can avoid creating and caching an
extra slice to keep the hashes in addition to having the hash cached with
each transaction.
Rather than using the deprecated TxShas function on a btcutil.Block,
convert the checkBIP0030 to use the newer preferred method of ranging over
the Transactions to obtain the cached hash of each transaction.
This is also a little more efficient since it can avoid creating and
caching an extra slice to keep the hashes in addition to having the hash
cached with each transaction.
This commit adds a new function named NewBlockTemplate along with
supporting infrastructure which is part of the core functionality needed
to support mining.
In particular the function creates a new block template which contains a
fully populated block with a zero nonce that is ready to be solved as well
as additional information regarding the fees and number of signature
operations for each transaction included in the block. The specific
transaction selection logic mirrors the reference implementation.
Various cleanup, optimizations, and comment suggestions provided by
@owainga. Also contains some naming suggestions and comment fixes from
@flammit.
This change adds select statements to each channel write that may
occur from a non-RPCS goroutine to unblock once the server has begun
shutting down. This prevents issues in clean shutdown where non-RPCS
goroutines may block indefinitely on message sends to the RPC server.
This change adds rescan fast paths for all current implementations of
the btcutil.Address interface. Rather than encoding a payment address
string from a txout script, the minimum number of bytes (which depends
on the address type) are copied into a stack array and used as a
lookup key to a map exclusive for that address type. This performs
better than the previous implementation due to avoiding the base58
encoding and generating less garbage (so each GC cycle completes
faster).
If the address type switch falls into the default (unhandled) case,
the encoded payment address is used as a fallback. This keeps the
intended rescan behavior even when new implementations of
btcutil.Address are added without a rescan fast path.
Benchmarks indicate that when a fast path is followed, for 20 byte
RIPEMD-160 hashes (such as P2PKH and P2SH), skipping the payment
address encoding (and thus bypassing the base58 encoding code) can
result in map lookups up to 60x faster.
Rather than returning an error when creating the RPC server an it can't
listen on any of the specified interfaces, only error when it can't listen
on all of the specified interfaces.
Change FetchBlockByHeight to do the database lookup itself instead of
calling getBlkByHeight. This saves an allocation of the entire block,
which it wasn't using.
In OpenDB, use fetchBlockShaByHeight instead of getBlkByHeight since it
only needs the sha. This saves memory on startup.
ok drahn@
Rather than updating the new chain state with the hash and height of the
block that was just processed, query the database for the best block.
This is needed because the block that was just processed might be a side
chain block or have caused a reorg.
serialization buffer in MsgTx's TxSha().
Benchmarking shows this is slightly faster due to avoiding the extra
garbage collection in addition to less peak memory usage.
Before: BenchmarkTxShaOld 500000 5626 ns/op
After: BenchmarkTxShaNew 500000 5457 ns/op
This commit introduces a chain state that is updated as blocks are
processed into the block chain instance associated with the block manager.
This has been done because btcchain is currently not safe for concurrent
access and the block manager is typically quite busy processing block and
inventory. This approach allows fast access to most chain information in
a concurrent safe fashion.
Rather than doing a lot of if/else in the configuration load for btcctl,
set the default for the RPC server to localhost and the RPC cert to the
btcd cert, then override them as needed depending on the --wallet and
--testnet flags.
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
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
