This commit modifies all of the commands and notifications to work
properly with the latest btcjson.RawCmd Params field changes.
This new approach is superior to the old method of using a []interface{}
because it means that each parameter is now unmarshalled into the expected
concrete type directly instead of whatever it happens to be in the JSON.
Since it is now preferred to use full blown structs for individual
parameters, the RescanCmd type has been changed to use a new OutPoint
that can be used directly for marshalling and unmarshalling instead of a
*btcwire.OutPoint.
Also, all of the MarshalJSON functions now make use of the new
btcjson.NewRawCmd function rather than repeating the same common field
over and over and all of the MarshalJSON, UnmarshalJSON, and parseX
functions have been made more consistent.
ok @jrick
This commit modifies the RawCmd type to use a slice of json.RawMessages so
that unmarshalling each individual parameter can be deferred to the
handler for the command.
This is superior to the old method of using a []interface{} because it
means that each parameter is now unmarshalled into the expected concrete
type directly instead of whatever it happens to be in the JSON. Due to
this, the old behavior where every number was unmarshlled as a float64 and
converted to the appropriate final type, which could lead to odd behavior
when going through marshal/unmarshal cycles, has been eliminated. This
change also means each individual parameter can now be full blown structs
(JSON objects) that marshal and unmarshal themselves which greatly
simplifies complex parameters and removes the need for additional and
error prone code.
This commit contains a lot of changes because every command needed its
MarshalJSON and UnmarshalJSON methods updated to support the new
mechanism. As a part of changing these functions, a new common creation
function for the the RawCmd struct was added to avoid the previous
duplication of the common fields. Also, rather than repeating the method
string in each MarshJSON functon, it makes use of cmd.Method().
Finally, some of the error messages were incorrect and have been corrected
as well as made consistent.
ok @jcvernaleo, @jrick, @owainga
This commit addes a couple of tests to ensure performing math operations
on a 5-byte integer, even if the result is a 4-byte integer, is considered
invalid.
- 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.
