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.
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
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 changes all cases which generate default timestamps to
time.Now to limit the timestamp to one second precision. The code which
serializes and deserializes timestamps already does this, but it is useful
to make sure defaults don't exceed the precision of the protocol either.
With this change there is less chance that developers using defaults will
end up with structures that have a higher time precision than what will
ultimately be sent across the wire.
