Since a chain verification can take a long time depending on the
parameters, this commit adds a debug print to the RPC server at the info
level for how many blocks are being verified and at what level.
The logic was also slightly modified so the number of blocks being checked
can easily be calculated and shown.
This commit extends the RegisterCustomCmd function to also accept a reply
parser which will be invoked for replies to the custom command via
ReadResultCmd. This allows replies to custom commands to be returned a
concrete structs instead of map[string]interface{}.
ok @jcvernaleo, @jrick
This commit moves all of the structs which deal with command results and
related functions to a new file named jsonresults.go.
This is in preparation of allowing custom results to be registered.
ok @jcvernaleo
This commit marks the CreateMessage and CreateMessageWithId functions as
deprecated as they are no longer maintained due to the new concrete
command approach.
It also updates the package documentation to show the new preferred method
as well as add details about btcd.
ok @jcvernaleo
The existing RpcCommand and TlsRpcCommand were build with
CreateMessage(WithID) in mind since they return an already marshalled
command. The approach was changed to use concrete commands created via
the New<command>Cmd family of functions. However, this means the caller
had to manually marshal the command before calling (Tls)RpcCommand which
was not very user friendly.
This commit adds two new functions named RpcSend and TlsRpcSend which
directly accepts a btcjson.Cmd and handles the marshalling itself.
ok @jcvernaleo
The NewTxNtfn notification was previously using a map[string]interface.
This commit modifies it to use the new concrete type
btcjson.ListTransactionsResult instead which allows nicer marshalling and
unmarshalling.
ok @jrick
This is no longer required since the RawCmd params now consist of a slice
of raw JSON messages which the registered parser can directly unmarshal.
ok @jcvernaleo
This commit modifies the AllVerboseTxNtfn command to use a parser along
with the standard btcjson.RegisterCustomCmd instead of the now removed
RegisterCustomCmdGenerator function. This is possible due to the recent
changes that defers the unmarshalling of the parameters of a RawCmd to the
parser.
The unmarshaller for the GetAddressBalanceCmd was calling the wrong parse
function. It wasn't caught by the tests because the error on
UnmarshalJSON was being ignored, so this commit also updates the tests to check the
error.
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.
