The benchmarks are still only compiled when running 'go test' so this has
no effect on regular usage. This is being done because benchmarks often
need access to internal state.
Normal tests are kept in a separate package since they also serve to
exercise the public API, and by intentionally making it more difficult to
reach into the internals, it helps ensure the public API is sanely usable.
Since the benchmarks can now access the internals directly, this commit
also removes the functions which exposed the internals to the test package
from internal_test.go which were only used by the benchmarks.
The hash is not displayed big endian, but rather as a byte-reversed
hash as a hexidecimal string, so document it as such.
While here, speed up the function. Some benchmarks:
BenchmarkShaHashString 2000000 996 ns/op
BenchmarkShaHashStringOld 100000 22701 ns/op
Now that Go 1.4 has been released, this commit reverts the recent changes
which dealt with allowing TravisCI to work with go tip in between the Go
1.3 and Go 1.4 release cycle and updates the .travis.yml to invoke test
coverage tool from the new path in Go 1.4.
This commit modifies the .travis.yml to invoke a new script which has also
been added that gets the test coverage tool from the new path needed by go
tip.
This commit modifies the RandomUint64 function so that rather than
returning an io.ErrShortBuffer when the system does not have enough
entropy available, it now blocks until it does have enough. This means
that RandomUint64 will now always eventually succeed unless the entropy
source is closed (which only really ever happens when the operating system
is shutting down).
The tests have also been updated for the change in semantics to maintain
100% coverage.
Closes#23.
Add the word 'string' to the error string so if this is printed, it
will be clearer that it was a hash string decode that failed (as
opposed to other errors creating a ShaHash from a byte slice) and
change 'chars' to 'bytes', since the string length is measured in
bytes, not UTF-8 code points.
ok @davecgh
The go vet command complains about untagged struct initializers when
defining a ShaHash directly. This seems to be a limitation where go vet
does not exclude the warning for types which are a constant size byte array
like it does for normal constant size byte array definition.
This commit simply modifies the tests to use a constant definition cast to a
ShaHash to overcome the limitation of go vet.
Although it is possible to get the command name for each msg type by
creating an instances of the type and calling the Command method against
it, it's slightly more efficient to simply allows callers to have direct
access to the exported constants.
This is currently really useful for the reject message since callers need
to be able to examine the command type to determine whether or not the
hash field needs to be included.
This commit adds a new function named SerializeSize to the public API for
MsgBlock which can be used to determine how many bytes the serialized data would
take without having to actually serialize it. In addition, it makes the
exported BlockVersion an untyped constant as well as changes the block and
tx versions to a signed integer to more closely match the protocol.
Finally, this commit also adds tests for the new function.
The following benchmark shows the difference between using the new
function to get the serialize size for a typical block and serializing
into a temporary buffer and taking the length of it:
Bufffer: BenchmarkBlockSerializeSizeBuffer 200000 27050 ns/op
New: BenchmarkBlockSerializeSizeNew 100000000 34 ns/op
Closes#19.
Rather than using bytes.NewBuffer, which is a read/write entity
(io.ReadWriter), use bytes.NewReader which is only a read entitiy
(io.Reader) in all cases where it is possible. Benchmarking shows it's
slightly faster and it's also technically more accurate since it ensures
the data is read-only.
There are a few cases where bytes.NewBuffer must still be used since a
buffer with a known length is required for those instances.
This commit updates doc.go to include the new simulation test network
magic constant as well as remove the information about BIP0037 not being
supported since that is no longer true.
The default network ports are not really part of the wire protocol rather
they are part of a network parameters. Thus, this commit moves them to
the btcnet package.
The genesis blocks are not really part of the wire protocol rather they
are part of a network parameters. Thus, this commit moves the all of the
gensis blocks and tests to the btcnet package.
Also, create variables in the test package for the mainnet genesis hash,
merkle root, and coinbase transaction for use throughout the tests since
they the exported values are no longer available.
This commit adds a full suite tests for the new reject message added in
protocol version 70002 to bring the overall test coverage of btcwire back
up to 100%.
Closes#9.
This commit adds the new reject protocol message added to recent versions
of the reference implementation. This message is intended to be used in
response to messages from a remote peer when it is rejected for some
reason such as blocks being rejected due to not conforming to the chain
rules, transactions double spending inputs, and version messages sent
after they're already sent.
This is work toward issue #9.
- Correct MsgFilterLoad max payload
- Enforce max flag bytes per merkle block
- Improve and finish tests to include testing all error paths
- Add fast paths for BloomUpdateType
- Convert all byte fields to use read/writeVarBytes
- Style and consistency updates
- README.md and doc.go updates
Closes#12.
- Group the new read/writeVarBytes functions together to be consistent
with the existing code
- Modify the comments on the new read/writeVarBytes to be a little more
descriptive and consistent with existing code
- Use "test payload" for field name in the tests for the
read/writeVarBytes functions which is more accurate
- Remove reserved param from NewAlert since there is no point is having
the caller deal with a reserved param
- Various comment tweaks for clarity and consistency
- Use camel case for fuction params for consistency
- Move the NewAlert and NewAlertFromPayload functions after the receiver
definitions for code layout consistency
Closes#11.
* Introduced common methods readVarBytes, writeVarBytes.
* Added type Alert which knows how to deserialize
the serialized payload and also serialize itself back.
* Updated MsgAlert BtcEncode/BtcDecode methods to handle the
new Alert.
* Sane limits are placed on variable length fields like SetCancel
and SetSubVer
The code was updated to automatically handle the transaction count in the
block header without having the additional field some time ago. This
comment was outdated.
the new function AddUserAgent adds the user agent to the stack
and formats it as per BIP 0014
e.g: "/btcwire:0.1.4/myclient:1.2.3(optional; comments)/"
the validation on UserAgent has been moved to a new function
validateUserAgent
- 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.
