This commit adds both positive and negative tests for the new Tx and
Transactions Block API functions.
This is part of the ongoing transaction hash optimization effort noted in
conformal/btcd#25.
This commit adds two new functions to the Block API for working with the
recently added Tx type from the Block.
These new functions are named Tx and Transactions. Tx returns a
transactions for the specified index as a Tx and also memoizes it so
subsequent calls are more efficient. Transactions returns a slice of all
transactions in the Block wrapped in a Tx.
This is part of the ongoing transaction hash optimization effort
noted in conformal/btcd#25.
This commit adds both positive and negative tests for the new Tx type to
bring its coverage to 100%.
This is part of the ongoing transaction hash optimization effort noted
in conformal/btcd#25.
Currently, transaction hash caching is provided via Block directly, but a
transaction is not always part of a block and there are several cases
where only the transaction needs to be dealt with without wanting to pass
the entire block and transaction index around to be able to get at the
cached hash.
So, this commit adds a new type named Tx which is a wrapper that provides
easier and more efficient manipulation of raw wire protocol transactions.
It memoizes the hash for the transaction on its first access so subsequent
accesses don't have to repeat the relatively expensive hashing operations.
The idea is the callers can pass around pointers to these Tx types instead
of raw btcwire.MsgTx pointers.
For now, the Block API has not been changed, but the plan is to change it
to provide access to these wrapped transactions rather than having it do
the transaction hash caching directly.
This is only the first part of a series of changes working towards
optimizations noted in conformal/btcd#25.
This commit unfortunately changes the public API of Block which I
ordinarily don't like to do, but in this case, I felt it was necessary.
The blocks used throughout the database and elsewhere should be indepedent
of the protocol version which is used to encode the block to wire format.
Each block has its own Version field which should be the deciding factor
for the serialization and deserialization of blocks. In practice, they
are currently the same encoding, but that may not always be the case, and
it's important the blocks are stable depending on their own version
regardless of the protocol version.
This makes use of the new Serialize and Deserialize functions on MsgBlock
which are intended for long-term storage as opposed to wire encoding.
