- Coalesce the new bytes into the max message size constant to stay
consistent
- Correct optional relay tx field handling
- Rename the relay transactions field to DisableRelayTx so the zero value
of false has the correct default behavior
- Add tests for new bool fast paths in read/writeElement
- Stay consistent with version order in tests
- Add a single entry to TestVersionWire to test the new functionality
instead of adding a whole new TextVersionRelayTx function.
- Use BIP0037 in tests instead of hard coding 70001
- Nuke XXX that 70001 is different since this is handled now
- Fix and cleanup some comments
- Update test coverage report
Since fields of a version message after the AddrMe field are optional,
this commit adds a series of tests which ensure parsing version messages
which omit each of the optional fields works properly.
This commit modifies the MsgVersion.BtcDecode function to match the
behavior where fields after the first address field (AddrYou) are optional
and only read if the buffer contains remaining bytes.
Unfortunately this means the reader for MsgVersion.BtcDecode must be a
*bytes.Buffer or an error is returned. This is not an issue for the vast
majority of cases since all of the message reading code which is the main
way messages are read is already using a *bytes.Buffer, however, this
change might affect external callers if they are doing something special
with custom readers.
Fixes#14.
This commit modifies peers to use a max protocol version that is specified
as a constant in the peer code as opposed to the btcwire.ProtocolVersion
constant.
This allows btcwire to be updated to support new protocol versions without
causing peers to claim they support a protocol version which they actually
don't.
This commit corrects the debug log print to use the hash of referenced
coinbase transaction instead of the hash of the current transation when a
coinbase maturity is not met.
This change periodically (about every 10 seconds) notifies the
connected websocket client of the height of the last processed block
as part of the rescan. This enables clients to listen for the
notification and keep track of how much progress a rescan has made
even without any results being found. If the websocket connection is
lost during the rescan, on reconnect, clients may safely start over at
the last notified height.
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.
