The PR #1594 introduced a change that made the order of parameters
relevant, if one of them is nil. This makes it harder to be backward
compatible with the same JSON message if an existing parameter in
bitcoind was re-purposed to have a different meaning.
Adds interface for issuing a signrawtransactionwithwallet command.
Note that this does not add functionality for the btcd rpc server
itself, it simply assumes that the RPC client has this ability and gives
an API for interacting with the RPC client.
rpc: add signrawtransactionwithwallet interface
* GetBlockTemplate RPC client implementation
* Txid added to the getblocktemplate result
* Omitempty for TxID and improved comment for GetBlockTemplate 'rules' field
Updated the rpcserver handler for validateaddress JSON-RPC command to
have parity with the bitcoind 0.20.0 interface.
The new fields included are - isscript, iswitness, witness_version, and
witness_program. The scriptPubKey field has been left out since it
requires wallet access.
This update has no impact on the rpcclient.ValidateAddress method,
which uses the btcjson.ValidateAddressWalletResult type for modelling
the response from bitcoind.
This change makes btcd's getblock command match bitcoind's. Previously
the default verbosity was 0, which caused errors when using the
rpcclient library to connect to a bitcoind node - getblock would
unmarshall incorrectly since it didn't expect a verbosity=1 result when
it did not specify verbosity.
Refactor GetBlockVerboseResult into two separate types: one type for getblock "hash" verbosity=1,
and a second type for getblock "hash" verbosity=2. This is necessary due to how getblock returns
a block's transaction data based on the provided verbosity parameter.
If verbosity=1, then getblock.Tx is an array of a block's transaction ids (txids) as strings.
If verbosity=2, then getblock.Tx is an array of raw transaction data.
Due to differences in how getblock returns data based on the provided verbosity parameter, it's necessary
to have two separate return types based on verbosity. This necessitates a separate unmarshalling function
(represented throughout rpcclient/chain.go as Result.Receive()) to ensure that data is correctly unmarshalled
and returned to the user.
Due to differences in how getblock returns data based on the provided verbosity parameter, it's necessary
to have two separate return types based on verbosity. This necessitates a separate unmarshalling function
(represented throughout rpcclient/chain.go as Result.Receive()) to ensure that data is correctly unmarshalled
and returned to the user.
and a second type for getblock "hash" verbosity=2. This is necessary due to how getblock returns
a block's transaction data based on the provided verbosity parameter.
If verbosity=1, then getblock.Tx is an array of a block's transaction ids (txids) as strings.
If verbosity=2, then getblock.Tx is an array of raw transaction data.
